By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,866 Members | 1,704 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,866 IT Pros & Developers. It's quick & easy.

MySQL 4.0.18 on Dual AMD64 Opteron causing thread zombie even when timeout is set to 60 seconds

P: n/a
Hi guys,
We have a problem with Dual AMD64 Opteron/MySQL 4.0.18/Mandrake 10
for a very high volume site. We are evaluating the performance on our
new server AMD64 and it seems it's slow compared to Dual Xeon/MySQL
4.0.15/RedHat8 and Dual Xeon/MySQL 4.0.18/Mandrake 10.

And it seems there are zombie threads. 570 threads in 1 hour and we
didn't even use JDBC connection pooling at all. These threads are
supposed to be gone within 60 seconds, since we set that option in
mysqld. Note that we run many SELECT queries (can be up to 150
queries/seconds), but the system does not indicate any slow query:
it's 0!

Our configuration is Apache 2.0.48 + Tomcat 5.0.27 + MySQL 4.0.18 with
MySQL connector/J 3.0.14 (latest stable). The Redhat 8 runs on Apache
2 + Tomcat 4.0 + MySQL 4.0.15. The old Redhat 8 on Xeon was fine. We
have another machine running Mandrake 10 on Xeon and they were fine
under the same load.
I have set the wait_timeout to 60 seconds, and it appears to be fine
within 10 minutes, all the threads that are in "sleep" mode
disappeared after 60 seconds. After a few minutes though, it's back
like it was before.

Is this Mandrake problem? MySQL problem? I read in here than Mandrake
win hands down on AMD64 compared to FreeBSD.

http://news.gw.com/freebsd.amd64/1030

What do you think cause this problem on MySQL/AMD64? Is there such
problem in v4.0.18?

Thanks,
Prana

Here's the info:
===========================================
This MySQL server has been running for 0 days, 1 hours, 20 minutes and
48 seconds. It started up on Aug 26, 2004 at 11:24 PM.
===========================================
Query statistics: Since its startup, 261,670 queries have been sent to
the server.
Total per hour per minute per second
261,670 194,309.41 3,238.49 53.97
===========================================
Uptime: 5559 Threads: 569 Questions: 261705 Slow queries: 0 Opens:
74 Flush tables: 1 Open tables: 68 Queries per second avg: 47.078
===========================================
Mandrake Packages:
MySQL-common-4.0.18-1.1.100mdk
lib64mysql12-4.0.18-1.1.100mdk
perl-Mysql-1.22_19-9mdk
MySQL-4.0.18-1.1.100mdk
MySQL-client-4.0.18-1.1.100mdk
php-mysql-4.3.4-1mdk
====================================
[root@hello root]# mysql -e 'show variables like "%time%"'
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| connect_timeout | 5 |
| delayed_insert_timeout | 300 |
| flush_time | 0 |
| innodb_lock_wait_timeout | 50 |
| interactive_timeout | 60 |
| long_query_time | 10 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| slow_launch_time | 2 |
| timezone | SGT |
| wait_timeout | 30 |
+--------------------------+-------+
============[my.cnf]======================
[client]
port = 3306
socket = /var/lib/mysql/mysql.sock

[mysqld]
wait_timeout=30
interactive_timeout=60
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
log-slow-queries
key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 128
query_cache_size = 32M
max_connections=1200
thread_concurrency = 4
connect_timeout = 5

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout
==========================
Plymouth Acclaim
Jul 20 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.