Extremely High Load
I am getting loads upward of 20 with low CPU utilization and low bandwidth utilization.
--
MySQL 4.1.12-log (latest available from Red Hat Network)
Hardware: Dual Xeon, 2gig RAM
OS: Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
--
top - 13:38:28 up 1:56, 2 users, load average: 6.16, 10.01, 11.58
Tasks: 86 total, 1 running, 85 sleeping, 0 stopped, 0 zombie
Cpu(s): 20.1% us, 12.6% sy, 0.0% ni, 64.6% id, 2.7% wa, 0.0% hi, 0.0% si
Mem: 2074884k total, 1511492k used, 563392k free, 83232k buffers
Swap: 4096496k total, 0k used, 4096496k free, 1216768k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2354 mysql 15 0 559m 129m 3908 S 99.9 6.4 159:33.48 mysqld
--
Runtime Information
This MySQL server has been running for 0 days, 2 hours, 2 minutes and 44 seconds. It started up on Nov 18, 2005 at 11:43 AM.
* Server traffic: These tables show the network traffic statistics of this MySQL server since its startup.
Traffic ø per hour
Received 79,335 KB 38,784 KB
Sent 2,284 MB 1,117 MB
Total 2,362 MB 1,155 MB
Connections ø per hour %
Failed attempts 1 0.49 0.01 %
Aborted 30 14.67 0.28 %
Total 10,715 5,238.19 100.00 %
* Query statistics: Since its startup, 916,600 queries have been sent to the server.
Total ø per hour ø per minute ø per second
916,600 448,093.43 7,468.22 124.47
--
I have a hard-wired gigE connection to the server running MySQL.
--
The table that is in question is MyISAM.
Row Statistics:
Statements Value
Format dynamic
Collation latin1_swedish_ci
Rows 75,650
Row length ø 298
Row size ø 570 Bytes
Next Autoindex 103,725
Each time a person hits a page, there are two statements that get executed. One is a mildly complex SELECT that possibly hits every record. The other is an UPDATE that adds 1 to a counter in one of the records (identified by an auto-index primary key).
I have set low-priority-updates to ON.
It seems that the db cycles from doing a lot of SELECTs, then a lot of these UPDATEs to the counters, back and forth. I have tuned every db parameter I think that I should (derived from the huge model). The SELECTs have been tuned as much as I know how.
Any path to high-performance here?
Thanks.