>>>>> "Timothy" == Timothy Chi <tchi@stripped> writes:
Timothy> Hi Sinisia,
>> Please check a size of your partition where database files are.
Timothy> 17 Gig, about 9% used
>> Second, do you use any table locks ??
Timothy> No, we don't use any table locks.
Timothy> Interestingly enough, we've been on the phone with Sun and they gave us a
Timothy> few commands to run to track the processor utilization. The mpstat command
Timothy> gave us an abnormally high value for the "smtx" column (which basically
Timothy> represents cross-processor locking). Sun said that this number, at its
Timothy> highest should be around 200, and our system is reporting values up towards
Timothy> 13,000. Sun said that most of the threads are user threads causing this, so
Timothy> that this is an application related issue.
Timothy> Here's the snip from Sun Tech Support:
>> The data you sent appears to verify that there is a lock contention
>> issue caused by MySQL itself. This article describes how to
>> interpret the
>> data, and how to collect more data about the application itself:
>> http://www.sunworld.com/swol-08-1998/swol-08-perf.html I'll leave
>> this open until you've looked at that, and checked the resources for
This could be bug similar to the one we resently found in the FreeBSD
You can test this by removing from handler.cc all rows that includes:
(MySQL 3.23.5 will include much better version of the above fix, but
the above should be ok for you).
Any change you can send us the output from '/usr/proc/bin/pstack' on
the mysqld process and 'mysqladmin proc' when you get problems.
In the worst case, this could be a problem with the key cache mutex.
You can test this by running without any key cache!
mysqld -O key_buffer=0
Does any of the above suggestions help ?