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
cpu "wait" vermeiden
-
- Posts: 88
- Joined: 2006-06-10 14:17
Re: cpu "wait" vermeiden
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?
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?
-
- Posts: 57
- Joined: 2006-08-01 22:33
- Location: Berlin
Re: cpu "wait" vermeiden
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:
zu den aufgaben des servers: hochfrequentierte communityseite mit php und mysql.
my.conf:
was empfiehlst du mir zu ändern :)
lg
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
my.conf:
Code: Select all
key_buffer = 32M
table_cache = 256
max_allowed_packet = 16M
thread_stack = 128K
lg
-
- Posts: 88
- Joined: 2006-06-10 14:17
Re: cpu "wait" vermeiden
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.
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.
-
- Posts: 57
- Joined: 2006-08-01 22:33
- Location: Berlin
Re: cpu "wait" vermeiden
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:
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
-
- Posts: 561
- Joined: 2003-02-01 13:14
- Location: Fuldatal
Re: cpu "wait" vermeiden
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>
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>
-
- Posts: 57
- Joined: 2006-08-01 22:33
- Location: Berlin
Re: cpu "wait" vermeiden
ja so ein mysql check prozess sehe ich wenn ich "top" aufhabe
-
- Posts: 88
- Joined: 2006-06-10 14:17
Re: cpu "wait" vermeiden
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.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.
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.