mySQL- CPU Überlastungs-Rätsel (P4HT 3Ghz)

[theselha]

Hi,

Habe auf einem LAMP (SuSe, PHP 4.3, Apache 1.3.26, MySQL 3.23.55) einen ganz normalen Webshop mit Typo3 zusammen am laufen. Wir haben ca. 5000 Besucher am Tag. Ein max_connections von 500 in der my.cnf reicht aus, also kann sooooviel eigentlich los sein, dass eine 3Ghz HT CPU am Rande der Auslastung steht. Zumindest nicht für mein Verständnis. Der müsste sich eigentlich langweilen. Habe vor 2 Wochen schon die Hardware verdoppelt, wegen des Problems (von 1GB Ram auf 4GB und von P4 1.6 Ghz auf P4 3Ghz HT) Nach einem "/etc/init.d/mysql restart" ist er auch wieder extrem fix.

Es laufen 2 Datenbanken mit insgesamt ca. 150 Tabellen. Sind aber alle eher klein. Wir reden hier über ein Datenvolumen von maximal 50-60 MB.
"left outer join" wird nicht gerade selten benutzt.

Hier mal ein top von solchen Hoch-Last Momenten:

------------------
top - 15:26:38 up 8 days, 4:52, 2 users, load average: 5.46, 5.22, 5.18
Tasks: 654 total, 5 running, 648 sleeping, 0 stopped, 1 zombie
Cpu0 : 74.5% user, 25.5% system, 0.0% nice, 0.0% idle
Cpu1 : 59.9% user, 40.1% system, 0.0% nice, 0.0% idle
Mem: 3711324k total, 3458712k used, 252612k free, 531196k buffers
Swap: 795176k total, 4k used, 795172k free, 1648580k cached
 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA Command
638 mysql 25 0 77228 75m 2400 R 70.5 2.1 16:17.59 4 1356 66m mysqld
3249 mysql 25 0 77228 75m 2400 R 41.7 2.1 14:45.46 4 1356 66m mysqld
1063 mysql 25 0 77228 75m 2400 R 31.2 2.1 15:15.64 4 1356 66m mysqld
610 mysql 25 0 77228 75m 2400 R 28.2 2.1 15:32.03 4 1356 66m mysqld
5379 root 22 0 1252 1252 708 R 27.6 0.0 0:06.47 0 72 1180 top
1 root 15 0 248 248 212 S 0.0 0.0 0:07.22 0 224 24 init
------------------

Habe vermutet, dass es einfach nur eine Einstellungssache in der my.cnf ist, aber ich spiele nun schon seit mehreren Wochen mit diversen Parametern rum und nix wird besser. Also nochmal. Das Problem bestand schon auf einer etwas schwächeren Maschine, habe dann die Hardware ausgetauscht und es besteht immernoch. Vielleicht sollte ich noch erwähnen dass auf der Kiste auch Java-Prozesse laufen für SonicMQ-JMS Messaging. Ich weiss, dass Java sehr Resourcen-hungrig ist, aber die stellen kein Problem dar.

Füge hier auch mal unsere aktuelle my.cnf ein.

------------------

[client]
port = 3306
socket = /tmp/mysql.sock
 
[ mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
set-variable = key_buffer=256M
set-variable = max_allowed_packet=4M
set-variable = table_cache=256
set-variable = sort_buffer=4M
set-variable = record_buffer=4M
set-variable = myisam_sort_buffer_size=64M
set-variable = thread_cache=8
 
# TH+
set-variable = max_connections=500
set-variable = thread_cache_size=512
# TH-
 
# Try number of CPU's*2 for thread_concurrency
set-variable = thread_concurrency=4
log-bin
server-id = 1
 
[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log
 
[mysqldump]
quick
set-variable = max_allowed_packet=16M
 
[ mysql]
no-auto-rehash
 
[isamchk]
set-variable = key_buffer=64M
set-variable = sort_buffer=64M
set-variable = read_buffer=2M
set-variable = write_buffer=2M
 
[myisamchk]
set-variable = key_buffer=64M
set-variable = sort_buffer=64M
set-variable = read_buffer=2M
set-variable = write_buffer=2M
 
[mysqlhotcopy]
interactive-timeout
------------------

Wenn mir irgendwer einen Tipp geben kann, wäre ich extrem dankbar !
Die schlimmste Variante wäre natürlich, dass ich alle queries optimieren muss, wenn ich da

theselha

 

[theselha]

Hallo,

Habe das Problem gelöst, bisher zwar nur mit Hilfe eines workarrounds, aber es ersteinmal.

Und zwar scheint der eingekaufte Webshop echt schlechte SQL-Statements zu bauen mit häufig auftretenden full_joins. Hätte eigentlich auch schon früher drauf kommen können, aber naja.

Bis ich nun die Zeit finde um die Statements zu optimieren, habe ich die full_join_buffer in der my.cnf gesetzt und jetzt es. Ist nicht der Königsweg, aber eine vorübergehende Lösung !

Gruß,
Thomas