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 Buijsmantty.nl -- 2dehands.nl -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
INSERT queries hang on amd64
Problem: INSERT queries hang on amd64. This looks a lot like Don MacAskill's bugreport in http://bugs.mysql.com/bug.php?id=3483 I've just upgraded from 4.1.9 to 4.1.10 on a dual opteron with 8G ram, running Debian 3.1. 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 drastic. ;-) The master or standalone setup required quite a bit of poking to get it to happen in a test environment, or just a couple of short hours running as a production server. I haven't been able to narrow it down to a specific thing, but it appears to have something to do with indexes. 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 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= 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 Buijsmantty.nl -- 2dehands.nl -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: [MySQL General] INSERT queries hang on amd64
On Wed, Feb 16, 2005 at 12:41:04PM +0100, Michel Buijsman wrote: My problem: INSERT queries hang on amd64. Sorry about the multiple mails, mysql.com's mailinglist software does annoying things with the wrong adresses... -- Michel Buijsmantty.nl -- 2dehands.nl -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: INSERT queries hang on amd64
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 Buijsmantty.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]
Re: INSERT queries hang on amd64
I have 2 dual proc opterons and also have not seen this using MyISAM (4.1.9), however, I have been less than impressed with mysql on opteron (using the x86-64 binary from their site). Performance is generally less than that of our remaining old 32 bit dual proc xeon machines (all our db machines have 4 GB RAM and similar my.cnf settings giving 1.5GB to keybuffer, 768M to sort_buffer). In some cases, we are seeing queries take twices as long on the opteron machines as on the xeons, and it is rare for the opterons to ever outperform our xeon cluster. It is also much more likely for our tables to crash during big alters on the opteron machines than on the xeon, especially if the table has a full text on it (http://bugs.mysql.com/bug.php?id=7437). 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 Buijsmantty.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]
INSERT queries hang on amd64
Problem: INSERT queries hang on amd64. This looks a lot like Don MacAskill's bugreport in http://bugs.mysql.com/bug.php?id=3483 I've just upgraded from 4.1.9 to 4.1.10 on a dual opteron with 8G ram, running Debian 3.1. 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 drastic. ;-) The master or standalone setup required quite a bit of poking to get it to happen in a test environment, or just a couple of short hours running as a production server. I haven't been able to narrow it down to a specific thing, but it appears to have something to do with indexes. 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 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= 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 Buijsmantty.nl -- 2dehands.nl -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
