Re: Problems with x86_64 mysql-standard-4.1.12
Pete Harlan wrote: In addition to failing the tests, I deployed the server on Machine 1 for a while and it failed quickly, with a simple insert hanging up and kill threadID being unable to kill it. (The thread's state was Killed, but it didn't go away and continued to block other threads from accessing the (MyISAM) table.) Any help would be appreciated, and please let me know if I can provide further information. See the Opteron HOWTO: http://hashmysql.org/index.php?title=Opteron_HOWTO Also.. are you running NPTL or Linux Threads? If you have the libc6-i686 package installed you have NPTL (not sure if the mysql binary needs support for this or not). I'd also highly recommend installing a glibc 2.3.2 which is what ships on debian. glibc-2.3.5 is in experimental and its what we're running. Kevin -- Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. See irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Problems with x86_64 mysql-standard-4.1.12
Pete Harlan wrote: Hi, and then it never comes back, presumably from the auto_increment test. If I run the auto_increment test alone (i.e., ./mysql-test-run auto_increment), it fails in this same way. When it's hung, mysqld isn't using any CPU. Also.. CPU isn't the only thing you should be watching. Run iostat -k 1 and vmstat 1 to see what type of IO you're running at. Maybe you're IO is just being really slow. Its semi normal for your mysql box to be slowed down by disk... Kevin -- Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. See irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Problems with x86_64 mysql-standard-4.1.12 [SOLVED]
On Mon, May 23, 2005 at 11:52:50PM -0700, Kevin Burton wrote: Pete Harlan wrote: In addition to failing the tests, I deployed the server on Machine 1 for a while and it failed quickly, with a simple insert hanging up and kill threadID being unable to kill it. (The thread's state was Killed, but it didn't go away and continued to block other threads from accessing the (MyISAM) table.) Any help would be appreciated, and please let me know if I can provide further information. See the Opteron HOWTO: http://hashmysql.org/index.php?title=Opteron_HOWTO Also.. are you running NPTL or Linux Threads? If you have the libc6-i686 package installed you have NPTL (not sure if the mysql binary needs support for this or not). I'd also highly recommend installing a glibc 2.3.2 which is what ships on debian. glibc-2.3.5 is in experimental and its what we're running. What a difference a library makes...that was it, thank you! I had read the Opteron HOWTO, and tried that library with another problem I was having and it hadn't made a difference, so I reverted to 2.3.2 and forgot to try it here. [To answer your other questions: NPTL, I don't think libc6-i686 is for 64-bit, and there was no disk i/o either.] Thanks again! --Pete Kevin -- Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com. See irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 -- 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]
Problems with x86_64 mysql-standard-4.1.12
Hi, MySQL is not getting very far through make test on 64-bit Debian, MySQL 4.1.12. I've tried precompiled and self-compiled, and on two different machines, both of which have been in use for a long time and both of which run MySQL 4.0 (and its tests) without a problem. On one machine: ~/mysql-standard-4.1.12-unknown-linux-gnu-x86_64-glibc23/mysql-test: ./mysql-test-run Installing Test Databases Removing Stale Files Installing Master Databases running ../bin/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=.. --datadir=mysql-test/var/master-data --skip-innodb --skip-ndbcluster --skip-bdb Installing Slave Databases running ../bin/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=.. --datadir=mysql-test/var/slave-data --skip-innodb --skip-ndbcluster --skip-bdb Manager disabled, skipping manager start. Loading Standard Test Databases Starting Tests TESTRESULT --- alias [ pass ] alter_table[ pass ] analyse[ pass ] ansi [ pass ] archive[ pass ] and then it never comes back, presumably from the auto_increment test. If I run the auto_increment test alone (i.e., ./mysql-test-run auto_increment), it fails in this same way. When it's hung, mysqld isn't using any CPU. If I manually run the commands that constitute the auto_increment test on a running 4.1.12 server they complete, and the output appears normal to me. On another machine, make test gets as far as the delete test before hanging. The first machine doesn't successfully complete the delete test either, if run directly (i.e., ./mysql-test-run delete). The machines are running Debian amd64 (the standard archive), and are: Machine 1: Debian Sid, Athlon 3500+, 1GB ram. Kernel 2.6.12-rc4. Machine 2: Debian Sarge, Dual Opteron 248, 6GB ram. Production 4.0.x server, in use for six months. Kernel 2.6.11-ac7. In addition to failing the tests, I deployed the server on Machine 1 for a while and it failed quickly, with a simple insert hanging up and kill threadID being unable to kill it. (The thread's state was Killed, but it didn't go away and continued to block other threads from accessing the (MyISAM) table.) Any help would be appreciated, and please let me know if I can provide further information. Thanks, -- Pete Harlan [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
