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]
