cpu "wait" vermeiden

Apache, Lighttpd, nginx, Cherokee
mr_vista
Posts: 57
Joined: 2006-08-01 22:33
Location: Berlin

cpu "wait" vermeiden

Post by mr_vista »

hallo!

wenn ich bei meinem webserver in der konsole "top" ausführe zeigt er oft wa-werte im bereich von 30% bis 80% an.

soweit ich herausfinden konnte heisst das, die cpu wartet auf sachen die andere komponenten (festplatte etc.) noch zu erledigen haben bevor sie weitermachen kann.

wie kann ich den "wa" wert möglichst gering halten? am swappen liegts jedenfalls nicht, da der swap speicher laut top nicht genutzt wird. der server hat 2 GB RAM und einen ATHLON XP 64 als CPU sowie 1x 160GB HDD. bin für jede idee dankbar.

lg
r. u. serious
Posts: 88
Joined: 2006-06-10 14:17

Re: cpu "wait" vermeiden

Post by r. u. serious »

Das hängt davon ab was auf der Machine passiert/passieren soll. Es kann sein, dass die Platte einfach zu langsam ist, für das was du damit machen möchtest (oder dass DMA ausgeschaltet ist).

Ansonsten mußt du halt schauen was die vielen schreib/lese Aktionen auf der Platte auslöst und schauen ob es vermeidbar ist. Bspw. kann es sein, dass ein schlecht konfigurierter mysql-server ständig temporäre Tables auf die Platte schreiben muß, oder ständig die Indizies von Festplatte lesen muß - dann würde ein einfaches erhöhen der entsprechenden Caches/Buffers in der config, diese Plattenzugriffe erheblich reduzieren. Oder vielleicht kommen unmassen an Spammails rein, und du kanst schauen ob du die schon abblocken kannst, bevor sie durch dein System wandern (z.B. greylisting).

Du kanst mit iostat schauen ob es überwiegend lese oder überwiegend schreibzugriffe sind. Dann kannst du kurz testweise einzelne prozesse die du im Verdacht hast stoppen und schauen wie sich das auf die Schreib/Lese aktivitäten auswirkt.

Was sagen denn die ausgaben von "vmstat 1 5" und "iostat -x 1 5"? Und was sind die Aufgaben des Servers?
mr_vista
Posts: 57
Joined: 2006-08-01 22:33
Location: Berlin

Re: cpu "wait" vermeiden

Post by mr_vista »

hallo, danke schon mal.

das mit dem mysql server könnte durchaus stimmen. der server ist sehr stark frequentiert und die my.conf wurde nicht großartig verändert... bzw. wahrscheinlich nicht großzügig genug.

den befehl iostat gibt es bei mir nicht, aber hier die ausgabe vom vmstat 1 5:

Code: Select all

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 5  1      0  69528  30776 1248696    0    0   118   504  773   786 23 10 48 19
 2  0      0  70924  30776 1248708    0    0     0    60  939  4451 49 22 28  2
 4  1      0  72312  30776 1248728    0    0     0   704 1010  4804 62 29  9  0
 0  2      0  69004  30776 1248732    0    0     0   856  721  1925 20  5  0 75
 0  2      0  64224  30776 1248748    0    0    16   444  731  2260 28 13  0 59
zu den aufgaben des servers: hochfrequentierte communityseite mit php und mysql.

my.conf:

Code: Select all

key_buffer = 32M
table_cache = 256
max_allowed_packet = 16M
thread_stack = 128K
was empfiehlst du mir zu ändern :)


lg
r. u. serious
Posts: 88
Joined: 2006-06-10 14:17

Re: cpu "wait" vermeiden

Post by r. u. serious »

iostat gehört zu sysstat, gibts bei debian fertige Pakete (bei den anderen sicher auch). Ansonsten: http://perso.orange.fr/sebastien.godard/index.html

Ansonsten ist die Ausgabe vom vmstat schon recht aufschlußreich. Der größte Teil deines Speichers liegt mehr oder weniger ungenutzt rum (cache), d.h. du kannst unbesorgt deine caches/buffers in bspw. mysql hochsetzen.

key_buffers kannst du wie folgt einstellen:
Geh in /var/lib/mysql/mein_db_name/ (oder wo deine dbs gespeichert werden) und gib ein:
du -ch *.MYI

Das zeigt dir in der letzten Zeile die Gesamtgröße aller Indizes in der Datenbank an (bei mehreren Datenbanken in den anderen Verzeichnissen wiederholen). Wenn du ausreichend Platz hast (dnach sieht es ja aus), kannst du den key_buffer auf die gleiche Größe stellen, dann werden die Indizes nur ein einziges mal gelesen (noch größer ist dann nur Verschwendung). Bei z.B. einem phpBB Forum mit ein paar hundertausend Beiträgen kann das schonmal 200M und mehr sein.

Ansonsten willst du vermutlich auch tmp_table_size auf 16MB oder mehr setzen.

Falls du keinerlei innodb Tabellen benutzt und keine Replikation benutzt, kannst du ggf. auch das bin-log ausschalten, da wirst du dann IMHO eh keinen Nutzen von haben, und da wird andernfalls jede Aktion die Daten verändert reingeschrieben.

Weitere Lektüre:
http://dev.mysql.com/books/hpmysql-excerpts/ch06.html
und wenn du ein aktuelles phpmyadmin hast, kannst du auch einfach mal auf das Anzeigen der "Laufzeitinformationen" gehen. Da werden viele Diagnose-Infos angezeigt, zusammen mit Erläuterungen was worauf hindeuten kann, und wie man die Situation verbessern könnte.
mr_vista
Posts: 57
Joined: 2006-08-01 22:33
Location: Berlin

Re: cpu "wait" vermeiden

Post by mr_vista »

danke für die ausführliche antwort. habe mittlerweile auch schon etwas an der my.conf rumgetestet doch der "wa" wert wurde oft sogar nur größer. das ganze ist sehr eigenartig da bis vor kurzem der server noch deutlich besser lief.

mir ist aber noch etwas aufgefallen und zwar die sache mit dem key_buffer ... in meiner community hat jeder user ein gästebuch und damals als php anfänger hab ichs so programmiert, dass für jeden user eine eigene tabelle angelegt wird pro gästebuch... jetzt existieren also über 20000 gästebuchtabellen in einer datenbank, das heisst auch dass der benötigte key_buffer und table_cache sehr groß sein müsste gel?

wäre es besser das so zu programmieren, dass sämtliche gästebucheinträge in einer großen tabelle gespeichert sind, auch wenn diese dann etwa 22 Millionen zeilen hätte? (aktueller stand)


hier noch mal die laufzeitangaben von phpmyadmin:

Code: Select all

Variable   	 Wert für diese Sitzung   	 Globaler Wert 

back log 	50 	50
basedir 	/usr/ 	/usr/
bdb cache size 	8388600 	8388600
bdb log buffer size 	0 	0
bdb home 		
bdb max lock 	10000 	10000
bdb logdir 		
bdb shared data 	OFF 	OFF
bdb tmpdir 		
bdb version 	Sleepycat Software: Berkeley DB 3.2.9a: (March 5, 2005) 	Sleepycat Software: Berkeley DB 3.2.9a: (March 5, 2005)
binlog cache size 	32768 	32768
bulk insert buffer size 	8388608 	8388608
character set 	latin1 	latin1
character sets 	latin1 big5 cp1251 cp1257 croat czech danish dec8 dos estonia euc_kr gb2312 gbk german1 greek hebrew hp8 hungarian koi8_ru koi8_ukr latin1_de latin2 latin5 sjis swe7 tis620 ujis usa7 win1250 win1251ukr win1251 	latin1 big5 cp1251 cp1257 croat czech danish dec8 dos estonia euc_kr gb2312 gbk german1 greek hebrew hp8 hungarian koi8_ru koi8_ukr latin1_de latin2 latin5 sjis swe7 tis620 ujis usa7 win1250 win1251ukr win1251
concurrent insert 	ON 	ON
connect timeout 	5 	5
convert character set 		
datadir 	/var/lib/mysql/ 	/var/lib/mysql/
default week format 	0 	0
delay key write 	ON 	ON
delayed insert limit 	100 	100
delayed insert timeout 	300 	300
delayed queue size 	1000 	1000
flush 	OFF 	OFF
flush time 	0 	0
ft boolean syntax 	+ -><()~*:""&| 	+ -><()~*:""&|
ft min word len 	4 	4
ft max word len 	254 	254
ft max word len for sort 	20 	20
ft stopword file 	(built-in) 	(built-in)
have bdb 	DISABLED 	DISABLED
have crypt 	YES 	YES
have innodb 	YES 	YES
have isam 	YES 	YES
have raid 	YES 	YES
have symlink 	YES 	YES
have openssl 	NO 	NO
have query cache 	YES 	YES
init file 		
innodb additional mem pool size 	1048576 	1048576
innodb autoextend increment 	8 	8
innodb buffer pool size 	8388608 	8388608
innodb data file path 	ibdata1:10M:autoextend 	ibdata1:10M:autoextend
innodb data home dir 		
innodb file io threads 	4 	4
innodb force recovery 	0 	0
innodb thread concurrency 	8 	8
innodb flush log at trx commit 	1 	1
innodb fast shutdown 	ON 	ON
innodb flush method 		
innodb lock wait timeout 	50 	50
innodb log arch dir 	./ 	./
innodb log archive 	OFF 	OFF
innodb log buffer size 	1048576 	1048576
innodb log file size 	5242880 	5242880
innodb log files in group 	2 	2
innodb log group home dir 	./ 	./
innodb mirrored log groups 	1 	1
innodb max dirty pages pct 	90 	90
innodb max purge lag 	0 	0
innodb table locks 	ON 	ON
interactive timeout 	28800 	28800
join buffer size 	131072 	131072
key buffer size 	33554432 	33554432
language 	/usr/share/mysql/english/ 	/usr/share/mysql/english/
large files support 	ON 	ON
license 	GPL 	GPL
local infile 	ON 	ON
locked in memory 	OFF 	OFF
log 	OFF 	OFF
log update 	OFF 	OFF
log bin 	OFF 	OFF
log slave updates 	OFF 	OFF
log slow queries 	OFF 	OFF
log warnings 	1 	1
long query time 	10 	10
low priority updates 	OFF 	OFF
lower case file system 	OFF 	OFF
lower case table names 	0 	0
max allowed packet 	16776192 	16776192
max binlog cache size 	4294967295 	4294967295
max binlog size 	104857600 	104857600
max connections 	3500 	3500
max connect errors 	10 	10
max delayed threads 	20 	20
max insert delayed threads 	20 	20
max heap table size 	16777216 	16777216
max join size 	18446744073709551615 	18446744073709551615
max relay log size 	0 	0
max seeks for key 	4294967295 	4294967295
max sort length 	1024 	1024
max user connections 	0 	0
max tmp tables 	32 	32
max write lock count 	4294967295 	4294967295
myisam max extra sort file size 	268435456 	268435456
myisam max sort file size 	9223372036854775807 	9223372036854775807
myisam repair threads 	1 	1
myisam recover options 	OFF 	OFF
myisam sort buffer size 	8388608 	8388608
net buffer length 	16384 	16384
net read timeout 	30 	30
net retry count 	10 	10
net write timeout 	60 	60
new 	OFF 	OFF
open files limit 	17510 	17510
pid file 	/var/run/mysqld/mysqld.pid 	/var/run/mysqld/mysqld.pid
log error 		
port 	3306 	3306
protocol version 	10 	10
query alloc block size 	8192 	8192
query cache limit 	1048576 	1048576
query cache size 	16777216 	16777216
query cache type 	ON 	ON
query cache wlock invalidate 	OFF 	OFF
query prealloc size 	8192 	8192
range alloc block size 	2048 	2048
read buffer size 	131072 	131072
read only 	OFF 	OFF
read rnd buffer size 	262144 	262144
rpl recovery rank 	0 	0
server id 	0 	0
slave net timeout 	3600 	3600
skip external locking 	ON 	ON
skip networking 	OFF 	OFF
skip show database 	OFF 	OFF
slow launch time 	2 	2
socket 	/var/run/mysqld/mysqld.sock 	/var/run/mysqld/mysqld.sock
sort buffer size 	2097144 	2097144
sql mode 	0 	0
table cache 	256 	256
table type 	MYISAM 	MYISAM
thread cache size 	0 	0
thread stack 	131072 	131072
tx isolation 	REPEATABLE-READ 	REPEATABLE-READ
timezone 	CEST 	CEST
tmp table size 	33554432 	33554432
tmpdir 	/tmp/ 	/tmp/
transaction alloc block size 	8192 	8192
transaction prealloc size 	4096 	4096
version 	4.0.24_Debian-10sarge1 	4.0.24_Debian-10sarge1
version comment 	Source distribution 	Source distribution
version compile os 	pc-linux-gnu 	pc-linux-gnu
wait timeout 	28800 	28800
thorsten
Posts: 561
Joined: 2003-02-01 13:14
Location: Fuldatal

Re: cpu "wait" vermeiden

Post by thorsten »

Läßt du ab und wann mal sowas laufen?
mysqlcheck --analyze --check --auto-repair --extend --optimize --all-databases -uroot -p

Ich hatte vor einiger Zeit eine Communitysite, die 2-3 Sekunden pro Anfrage brauchte, nach der o.g. Optimierung liefs wieder wie geschmiert.

hth

BTW:
@R. U. Serious - sehr nette Erklärung :) =D>
mr_vista
Posts: 57
Joined: 2006-08-01 22:33
Location: Berlin

Re: cpu "wait" vermeiden

Post by mr_vista »

ja so ein mysql check prozess sehe ich wenn ich "top" aufhabe
r. u. serious
Posts: 88
Joined: 2006-06-10 14:17

Re: cpu "wait" vermeiden

Post by r. u. serious »

Mr_Vista wrote:danke für die ausführliche antwort. habe mittlerweile auch schon etwas an der my.conf rumgetestet doch der "wa" wert wurde oft sogar nur größer. das ganze ist sehr eigenartig da bis vor kurzem der server noch deutlich besser lief.
In einem laufenden System ist es völlig normal, dass die Werte ordentlich schwanken. Genauere Aussagen wird man meist erst nach mittelfristigem beobachten sagen können.


Ansonsten versuchst du gerade ins dunkkle hinein zu optimieren. Daher wiederhole ich meine Tipps:
R. U. Serious wrote:Du kanst mit iostat schauen ob es überwiegend lese oder überwiegend schreibzugriffe sind. Dann kannst du kurz testweise einzelne prozesse die du im Verdacht hast stoppen und schauen wie sich das auf die Schreib/Lese aktivitäten auswirkt.
[...]
iostat gehört zu sysstat, gibts bei debian fertige Pakete (bei den anderen sicher auch). Ansonsten: http://perso.orange.fr/sebastien.godard/index.html
[...]
Falls du keinerlei innodb Tabellen benutzt und keine Replikation benutzt, kannst du ggf. auch das bin-log ausschalten, da wirst du dann IMHO eh keinen Nutzen von haben, und da wird andernfalls jede Aktion die Daten verändert reingeschrieben.

Weitere Lektüre:
http://dev.mysql.com/books/hpmysql-excerpts/ch06.html
und wenn du ein aktuelles phpmyadmin hast, kannst du auch einfach mal auf das Anzeigen der "Laufzeitinformationen" gehen. Da werden viele Diagnose-Infos angezeigt, zusammen mit Erläuterungen was worauf hindeuten kann, und wie man die Situation verbessern könnte.