We are planning a full switch to innodb, and I seriously hope that makes the mysql on opteron experience a more pleasurable one.
Greg
Donny Simonton wrote:
I know this may be strange, but have you turned on innodb on the box? Even
if don't use it? I have 8 amd64 boxes and have never experienced this
problem you are talking about. They range from single proc to quad proc.
Never this problem but all of them have innodb turned on.
Turn it on and see what happens, it could be a bug inside the mysql code.
Donny
-----Original Message----- From: Michel Buijsman [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 16, 2005 5:41 AM To: mysql@lists.mysql.com Subject: INSERT queries hang on amd64
My problem: INSERT queries hang on amd64.
This looks a lot like Don MacAskill's bugreport in http://bugs.mysql.com/bug.php?id=3483 Which is listed as closed, but the bug is apparently still there so maybe it should be reopened...
I've just upgraded from 4.1.9 to 4.1.10 (binary) on a dual opteron with 8G ram, running Debian 3.1 pure64 gcc-3.4. Also tried 4.0.23 last week, but that had the same problems. Kernels I've tried are 2.6.11-rc1-mm1 and 2.6.11-rc2.
I'm running 2 boxes in a replication setup, using the amd64 as the master (or standalone) gave me pretty much what Don describes in bug 3483, insert queries start hanging after a while with no way to kill them except kill -9 from the OS, which is a bit rough. ;-)
The master or standalone setup required quite a bit of poking to get it to hang in a test environment, or just a few short hours running as a production server. I haven't been able to narrow it down to one specific thing, but it appears to have something to do with indexes, because it ran fine after dropping all of them.
I hacked up a test script that's throwing a random selection of selects and inserts at it at random intervals between 0 and 2 seconds, from 20 concurrent threads.
I could trigger it by running a "repair table" on it while the test script was running. The repair thread would wait for its turn, then lock everything else out and do its thing, and when it was done the first insert after that would hang indefinitely. (Left it hanging over the weekend, nothing.)
Adding "skip-concurrent-insert" fixes the problem, but cripples the performance so that's not really an option.
Then tried to run one of the amd64 boxes as a slave off of a xeon box: Same problem, the replication thread hangs within seconds of starting the server, and again won't budge for anything except kill -9. This is on a server without _any_ other connections except for a processlist.
I've run out of things to try, so I hope someone here can help...
my.cnf:
[mysqld] <snipped replication setup> user=mysql socket=/tmp/mysql.sock skip-locking set-variable = key_buffer=2G set-variable = table_cache=1024 set-variable = sort_buffer=16M set-variable = read_buffer=16M set-variable = max_allowed_packet=10M set-variable = thread_cache=64 set-variable = thread_stack=512K set-variable = tmp_table_size=16M set-variable = interactive_timeout=600 set-variable = wait_timeout=600 set-variable = max_connections=1024 set-variable = query_cache_type=2 set-variable = query_cache_size=100M set-variable = join_buffer_size=8M set-variable = thread_concurrency=4 set-variable = myisam_sort_buffer_size=64M skip-innodb
-- Michel Buijsman tty.nl -- 2dehands.nl
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
