Onderwerp: MySQL hoge load en cpu gebruik

Ik heb een server draaien,

- Pentium4 930
- 2GB harddisk
- Schijven in riad(mirror)

OS: FreeBSD 6.1
Mysql 5.0.22

De site die erop draait heeft gemiddeld tussen de 5000 en 8000 unieke bezoekers per dag. Nu is telkens de load en het CPU gebruik zeer hoog?

kan iemand mij advies geven voor een goed config... iendien meer info gewenst is zal ik dit plaatsen.

Hij is alsvolgt geconfigureerd.

httpd.conf

TimeOut 300
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 15
StartServers 8
MaxClients 150
MaxRequestsPerChild 1000


<IfModule prefork.c>
StartServers 50
MinSpareServers 10
MaxSpareServers 50
MaxClients 150
MaxRequestsPerChild 5
</IfModule>

<IfModule worker.c>
StartServers 50
MaxClients 150
MinSpareThreads 10
MaxSpareThreads 50
ThreadsPerChild 10
MaxRequestsPerChild 5
</IfModule>

<IfModule perchild.c>
NumServers 5
StartThreads 5
MinSpareThreads 10
MaxSpareThreads 50
MaxThreadsPerChild 10
MaxRequestsPerChild 5
</IfModule>





my.cnf

skip-locking
skip-name-resolve
key_buffer = 256M
max_allowed_packet = 16M
table_cache = 1500
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 32M
thread_concurrency = 2
set-variable=local-infile=1

[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 = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

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

[mysqlhotcopy]
interactive-timeout


Mvg Ron

Hoi Easy2host,

ik neem aan dat je bedoeld dat er 2 gb geheugen in de server zit. Er zijn verschillende zaken die voor de hoge load kunnen zorgen, weet je zeker dat het mysql is die de load veroorzaakt (top commando kan je kijken welke processen veel cpu tijd gebruiken).

Met het top commando kan je ook kijken hoeveel geheugen er gebruikt wordt, wanneer er nog veel geheugen vrij is zou je het aantal apache threads kunnen verhogen en de mysql query cache kunnen vergroten.

Wanneer het om een php applicatie gaat kan je ook nog denken aan een zogenaamde opcode cache zoals bijvoorbeeld apc of eAccelerator.

Het is sowieso wel verstandig om de timeout en de keepalivetimeout te verlagen, deze waardes staan standaard erg hoog en kunnen ervoor zorgen dat het lang duurt voordat een thread wordt vrijgemaakt en weer een nieuwe request kan uitvoeren.

Onderstaande httpd.conf van een soortgelijke server.

Timeout 10
KeepAlive On
MaxKeepAliveRequests 128
KeepAliveTimeout 4
StartServers 16
MinSpareServers 32
MaxSpareServers 64
MaxClients 256
MaxRequestsPerChild 4096

en een my.cnf van een soortgelijke server (let er wel op dat je voldoende geheugen vrij hebt!)

set-variable = key_buffer_size=256M
set-variable = join_buffer_size=4M
set-variable = max_allowed_packet=24M
set-variable = table_cache=1024
set-variable = sort_buffer_size=16M
set-variable = read_buffer_size=16M
set-variable = myisam_sort_buffer_size=32M
set-variable = max_connections=512
set-variable = wait_timeout=300
set-variable = thread_cache=64
set-variable = thread_concurrency=2
set-variable = ft_min_word_len=2
set-variable = max_connect_errors=100
set-variable = tmp_table_size=64M
set-variable = query_cache_limit=1M
set-variable = query_cache_size=64M
set-variable = max_heap_table_size=16M

Load is nu laag, maar loopt soms op naar 30 / 50




last pid: 7688; load averages: 2.71, 1.57, 2.91 up 12+05:02:09 14:09:04
57 processes: 6 running, 48 sleeping, 3 stopped
CPU states: 38.7% user, 0.0% nice, 60.9% system, 0.4% interrupt, 0.0% idle
Mem: 106M Active, 1064M Inact, 218M Wired, 69M Cache, 112M Buf, 529M Free
Swap: 1990M Total, 1990M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
5178 mysql 15 20 0 346M 74096K kserel 1 11:34 128.37% mysqld
308 root 1 96 0 1304K 868K select 0 1:25 0.00% syslogd
497 root 1 96 0 3436K 2624K select 1 0:19 0.00% sendmail
491 root 1 96 0 3356K 1984K select 1 0:18 0.00% sshd
393 root 1 96 0 2260K 1728K select 1 0:17 0.00% proftpd
3801 root 1 8 0 18628K 13084K nanslp 1 0:07 0.00% httpd
507 root 1 8 0 1328K 932K nanslp 0 0:06 0.00% cron
55899 root 1 96 0 3132K 2068K select 0 0:05 0.00% proftpd
56308 root 1 96 0 3068K 2144K select 0 0:04 0.00% proftpd
5196 root 1 96 0 2452K 1720K CPU0 1 0:02 0.00% top
1290 xander 1 96 0 6080K 3024K select 1 0:01 0.00% sshd
501 smmsp 1 20 0 3300K 2368K pause 0 0:00 0.00% sendmail
7616 www 1 97 0 26212K 20968K select 0 0:00 0.00% httpd
4315 root 1 6 0 1340K 944K STOP 0 0:00 0.00% iostat
1306 root 1 20 0 5972K 4068K pause 0 0:00 0.00% csh
7513 www 1 96 0 18752K 13220K select 1 0:00 0.00% httpd
7675 www 1 4 0 19272K 13936K sbwait 0 0:00 0.00% httpd
1286 root 1 4 0 6104K 2996K sbwait 0 0:00 0.00% sshd
7677 www 1 4 0 19296K 13920K sbwait 0 0:00 0.00% httpd
7680 www 1 4 0 19292K 13916K sbwait 1 0:00 0.00% httpd
7674 www 1 4 0 19304K 13924K sbwait 1 0:00 0.00% httpd
7683 www 1 4 0 19128K 13760K sbwait 0 0:00 0.00% httpd
5157 root 1 8 0 1652K 1340K wait 1 0:00 0.00% sh
1295 xander 1 8 0 1604K 1308K wait 0 0:00 0.00% su
1291 xander 1 8 0 1680K 1360K wait 0 0:00 0.00% sh
7684 www 1 4 0 18712K 13176K accept 1 0:00 0.00% httpd
554 root 1 5 0 1268K 784K ttyin 1 0:00 0.00% getty
4279 root 1 8 0 1340K 944K STOP 0 0:00 0.00% iostat
560 root 1 5 0 1268K 784K ttyin 1 0:00 0.00% getty
556 root 1 5 0 1268K 784K ttyin 1 0:00 0.00% getty
559 root 1 5 0 1268K 784K ttyin 0 0:00 0.00% getty
558 root 1 5 0 1268K 784K ttyin 0 0:00 0.00% getty
557 root 1 5 0 1268K 784K ttyin 0 0:00 0.00% getty

ik heb dat probleem vroeger ook vaak voorgehad en dat kwam omdat mijn httpd een berg childs spawnde waardoor zelfs de server volledig vast kwam te zitten ...

uit analyse van de data bleek dat het echter te wijten was aan een bug in één bepaald php script. mensen hadden dit echter gevonden en bestookten ons met requests naar dit ene script toe ... ik denk echter niet dat dit jou geval gaat zijn maar ik zou toch eens de logs van de httpd duchtig nakijken

mvg,

Bekijk je database maar eerst... liggen er indexen, liggen die op de goede velden? 95% kans dat dat je probleem is... en dat los je niet op met wat instellingen in configfiles.

Kan zoals al eerder gezegd aan meerdere dingen liggen.
- Indexes
- pconnect, dit is iets wat verboden zou moeten worden in php branche
- Fragmentatie van de data, maak wel eerst een backup
- Of teveel (onodige querys)
- Iets wat wat minimaal alleen bij MySQL5 op kan treden, triggers die die in een endes loop raken.

Is de installatie zelf gecompileerde versie van MySQL of een door MySQL Ab gemaakt? Ik heb slechte ervaring me versies van MySQL die ik zelf had gemaakt.

je kan pconnect toch disablen

gewoon eventjes safe_mode aangooien
en dan in php.ini :

disable_functions mysql_pconnect

Waarom zou je daar safe_mode voor nodig hebben?
Bij PHP6 is die er gewoon (eindelijk) uitgehaald!

Daar komt bij, volgens mij is disable_functions niet PHP_INI_ALL maar PHP_INI_SYSTEM en dus alleen in te stellen bij php.ini en Virtualhost.

Oorspronkelijk geplaatst door Rollerscapes

Is de installatie zelf gecompileerde versie van MySQL of een door MySQL Ab gemaakt? Ik heb slechte ervaring me versies van MySQL die ik zelf had gemaakt.

Wij ook, slow_query_log aanzetten kan je ook inzicht verschaffen. Op zwaar belaste db-systemen is de disk ook vaak een bottleneck. Raid 1 draagt daar alleen maar aan bij.

Harde schijf 2GB.... zou dat het geheugen kunnen zijn? Voor een vaste schijf lijkt het mij ietwat klein alhoewel.. ik heb nog een computer met een 32MB schijf.. afijn..

Ik ga in deze met Wonko mee.

Start mysql met:
--log=geef_het_een_naam
en in de var directory komt een logbestand. Voer een aantal van deze queries aan mysql (shell) en zet er explain voor.

Je krijg dan iets als:
explain select * from weet_ik_veel_wat;
zeker met joins is heel erg veel te winnen als je een database van de juiste indexen voorzie.

Je mag er nog zoveel explain voorzetten als je wil, je zal eerst wat moeten bijlezen over databases, indexes en hoe het intern werkt (of een externe er even naar laten kijken).

Verder kan je ook best even kijken als je query-cache aanstaat, en goede waarden bevat.