Mysql load erg hoog

[maartenvdv737]

Ik zit hier met een webserver van circa 40-50 duizend unieke bezoekers per dag, 1.7M pageviews per dag.

Ik ben al de hele dag bezig met proberen de mysqld load omlaag te krijgen
ik heb telkens 1-4 mysqld processen die al mijn cpu opvreten.

Wat heb ik gedaan:

- verschillende my.conf geprobeerd, met sommige wou mysql niet meer starten, maar geen van alle gaf echt verbetering
- Mytop gekeken naar het aantal queries, maar zag niet veel bijzonders.
- Max_connections veranderd.
- hdparm toegepast op de hd om de snelheid van de hd te vergroten.

Het probleem is opgetreden toen er een website bij kwam waarin wel redelijk wat sql-queries zitten, maar de databases maken goed gebruik van indexen en is volgens het 3/4-tier ontwikkeld. Mytop geef een key-efficiency van 99.88%

Met sommige instellingen van my.cnf is ook het ram een probleem, maar meestal hou ik nog 500mb over.

Het systeem:

IDE hd 40Gb 7200RPM
CPU 2.0Ghz
900mb RAM (zit meer in, maar kernell staat op LOWMEM)
Kernell: 2.4.19

Overzichtjes:

mytop:

MySQL on localhost (3.23.54-log) up 0+02:03:47 [23:01:10]
Queries Total: 272,215 Avg/Sec: 36.65 Now/Sec: 39.33 Slow: 1,052
Threads Total: 3 Active: 1 Cached: 0
Key Efficiency: 99.89% Bytes in: 34,476,181 Bytes out: 384,876,756

Id User Host/IP DB Time Cmd Query or State
-- ---- ------- -- ---- --- ----------
49903 root localhost kindertent 0 Query show full processlist
24 DELAYED localhost ads 1 Delaye phpads_adviews
140 DELAYED localhost ads 68 Delaye phpads_adclicks

De queries veranderen natuurlijk de hele tijd

top:

11:13pm up 2:21, 1 user, load average: 1.55, 2.35, 4.84
308 processes: 302 sleeping, 5 running, 1 zombie, 0 stopped
CPU states: 47.7% user, 27.7% system, 0.0% nice, 24.5% idle
Mem: 905364K av, 425136K used, 480228K free, 0K shrd, 55140K buff
Swap: 522104K av, 0K used, 522104K free 184472K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
29431 mysql 19 0 18120 17M 1944 R 35.6 2.0 0:01 mysqld
29456 mysql 20 0 18120 17M 1944 R 13.6 2.0 0:00 mysqld
26273 root 9 0 1204 1204 836 R 0.9 0.1 0:02 top
29436 www 10 0 3468 3468 3296 S 0.9 0.3 0:00 httpd
28982 www 9 0 3652 3652 3384 S 0.5 0.4 0:00 httpd
29064 www 9 0 3896 3896 3496 S 0.5 0.4 0:00 httpd
3979 mysql 9 0 18120 17M 1944 S 0.3 2.0 0:05 mysqld
26792 www 9 0 4216 4216 3588 S 0.3 0.4 0:00 httpd
28779 www 9 0 3900 3900 3496 S 0.3 0.4 0:00 httpd


Dit is net een screenshot van een moment dat de cpu niet 100% is, maar zie de bovenste twee mysqld processen.

my.cnf:

[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
set-variable = max_connections=2048
set-variable = key_buffer=512M
set-variable = max_allowed_packet=1M
set-variable = table_cache=64
set-variable = sort_buffer=512K
set-variable = net_buffer_length=8K
set-variable = myisam_sort_buffer_size=8M
log-bin
server-id = 1


Ik heb erg veel newsposts gelezen, fora afgestruind en documentatie gelezen, maar ik kom er niet uit.....

Heeft iemand nog een idee?

[Kees]

Je hebt erg veel System CPU gebruik, dat wijst op een trage disk en te weinig geheugen.

MySQL zal door een enkele configwijziging niet veel sneller worden, maar voor een behoorlijk optimale config (met maar 1G geheugen): zie my.cnf-huge ergens een sample-config.

Overigens is 272 q/s weinigzeggend. Probeer er eens achter te komen welke queries er het langste over doen (hint: mysql-slow logging) en ga dan die verbeteren/opslplitsen etc. Je scripts / queries kan je vaak meer verbeteren dan de mysql config.

Ook zou ik je hardware bekijken; 1G geheugen is behoorlijk weinig voor zo'n belaste server, 2G is het minimum, 4G al een stuk beter. Ook kan het zijn dat je bak het simpel niet trekt, wat voor HW config is het? En last but not least, SCSI (raid) configs willen ook nogal eens voor versnelling zorgen, omdat eze lagere seektijden hebben dan de IDE.

offtopic:
Welke website is dat? 'maar' 50k unieke bezoekers en dan 1.7M pageviews? hier bij t.net halen we de 100k unieke bezoekers / 1.4M pageviews op een dag, hoe houden jullie je bezoekers zo lang vast?

[Wilke]

Als een trage disk de processen blockt zou je dit volgens mij moeten kunnen zien door 'vmstat 1' te runnen en te kijken of er in de 2e kolom (blocked) regelmatig getallen >0 voorkomen. Meestal zijn processen geblockt omdat ze op I/O wachten (in dit geval dus vrijwel zeker de harddisk).


Edit: Dan weet je natuurlijk nog steeds niet welk proces nou moet wachten, maar het is iig een indicatie dat het waarschijnlijk bij de harddisk ligt.

[ Voor 22% gewijzigd door Wilke op 28-12-2002 23:56 ]

[maartenvdv737]

Dit is niet het geval, alle getallen in de tweede kollom zijn 0

[active2]

Ik weet niet of je php gebruikt maar er is in php ook nog een akelige optie die je uit moet zetten: mysql.allow_persistent. Deze optie zorgt er voor dat er in php een pconnect gebruikt mag worden maar als deze pconnect langer duurt dan de executie time van apache (30 seconden ongeveer) dan blijft de pconnect leven en houdt dus een db connectie open.

En da's niet de bedoeling dacht ik zo. Maar daar kan je weleens een hoge load door krijgen.

[maartenvdv737]

Het probleem lijkt opgelost, er waren 2 tabellen waar de ID geen INDEX was

[Wilke]

Argh...ja, dat verklaart een hoop

Dan worden zelfs simpele select/natural join queries al een aanslag op je CPU.