Was verursacht den ungewöhnlich hohen Lastdurchschnitt?

Ich bemerkte am Dienstagabend der letzten Woche, dass der Lastdurchschnitt stark anstieg und es ungewöhnlich schien, da der Verkehr klein ist. Normalerweise liegen die durchschnittlichen Zahlen bei 0,40 oder weniger und meine Server-Inhalte (MySQL, PHP und Apache) sind optimiert. Mir ist aufgefallen, dass das IOWait ungewöhnlich hoch ist, obwohl die Prozesse kaum CPU verbrauchen.

top - 01:44:39 up 1 Tag, 21:13, 1 Benutzer, Lastdurchschnitt: 1,41, 1,09, 0,86
Aufgaben: 60 insgesamt, 1 rennen, 59 schlafen, 0 gestoppt, 0 Zombie
Cpu0: 0,0% us, 0,0% sy, 0,0% ni, 100,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu1: 0,0% us, 0,0% sy, 0,0% ni, 100,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu2: 0,0% us, 0,3% sy, 0,0% ni, 99,7% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu3: 0,0% us, 0,0% sy, 0,0% ni, 100,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu4: 0,0% us, 0,0% sy, 0,0% ni, 100,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu5: 0,0% us, 0,0% sy, 0,0% ni, 100,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu6: 0,0% us, 0,0% sy, 0,0% ni, 100,0% id, 0,0% wa, 0,0% hi, 0,0% si, 0,0% st
Cpu7: 0,0% us, 0,0% sy, 0,0% ni, 91,5% id, 8,5% wa, 0,0% hi, 0,0% si, 0,0% st
Mem: 1048576k insgesamt, 331944k verwendet, 716632k frei, 0k Puffer
Swap: 0k insgesamt, 0k verwendet, 0k frei, 0k zwischengespeichert

  PID BENUTZER PR NI VIRT RES SHR S% CPU% MEM ZEIT + BEFEHL           
    1 Wurzel 15 0 2468 1376 1140 S 0 0,1 0: 00,92 init               
 1656 root 15 0 13652 5212 664 S 0 0,5 0: 00,00 apache2            
 9323 root 18 0 13652 5212 664 S 0 0,5 0: 00,00 apache2            
10079 root 18 0 3972 1248 972 S 0 0.1 0: 00.00 su                 
10080 root 15 0 4612 1956 1448 S 0 0,2 0: 00,01 bash               
11298 root 15 0 13652 5212 664 S 0 0,5 0: 00,00 apache2            
11778 chikorit 15 0 2344 1092 884 S 0 0.1 0: 00.05 oben                
15384 root 18 0 17544 13m 1568 S 0 1,3 0: 02,28 miniserv.pl        
15585 root 15 0 8280 2736 2168 S 0 0,3 0: 00,02 sshd               
15608 chikorit 15 0 8280 1436 860 S 0 0.1 0: 00.02 sshd      

Hier ist das VMStat

procs ----------- memory ---------- --- swap-- ----- io ---- -system-- ---- cpu-- - -
 rb swpd free buff cache si so bi bo in cs us sy id wa
 1 0 0 768644 0 0 0 0 14 23 0 10 1 0 99 0

IOStat - Nichts Ungewöhnliches

Total DISK READ: 67,13 K / s | Total DISK WRITE: 0,00 B / s
  TID PRIO USER DISK READ DISK WRITE SWAPIN IO> BEFEHL          
19496 be / 4 chikorit 11,85 K / s 0,00 B / s 0,00% 0,00% Apache2-k Start
19501 be / 4 mysql 3,95 K / s 0,00 B / s 0,00% 0,00% mysqld
19568 be / 4 chikorit 11,85 K / s 0,00 B / s 0,00% 0,00% Apache2-k Start
19569 be / 4 chikorit 11,85 K / s 0,00 B / s 0,00% 0,00% Apache2-k Start
19570 be / 4 chikorit 11,85 K / s 0,00 B / s 0,00% 0,00% Apache2-k Start
19571 be / 4 chikorit 7,90 K / s 0,00 B / s 0,00% 0,00% Apache2-k Start
19573 be / 4 chikorit 7,90 K / s 0,00 B / s 0,00% 0,00% Apache2-k Start
    1 be / 4 root 0,00 B / s 0,00 B / s 0,00% 0,00% init
11778 be / 4 chikorit 0,00 B / s 0,00 B / s 0,00% 0,00% oben
19470 be / 4 mysql 0,00 B / s 0,00 B / s 0,00% 0,00% mysqld

Durchschnittliches Diagramm laden - http://i.stack.imgur.com/kYsD0.png

Ich möchte sichergehen, ob dies kein MySQL-Problem ist, bevor ich mich vergewissere. Dies ist auch ein Ubuntu 10.04 LTS-Server unter OpenVZ.

Bearbeiten: Dies wird wahrscheinlich ein gutes Bild auf dem IO Wait geben

top - 22:12:22 up 17:41, 1 Benutzer, Lastdurchschnitt: 1,10, 1,09, 0,93
Aufgaben: 33 insgesamt, 1 rennen, 32 schlafen, 0 gestoppt, 0 Zombie
CPU (s): 0,6% us, 0,2% sy, 0,0% ni, 89,0% id, 10,1% wa, 0,0% hi, 0,0% si, 0,0% st
Mem: 1048576k gesamt, 260708k gebraucht, 787868k frei, 0k Puffer
Swap: 0k insgesamt, 0k verwendet, 0k frei, 0k zwischengespeichert

PID BENUTZER PR NI VIRT RES SHR S% CPU% MEM ZEIT + BEFEHL 
1 Wurzel 15 0 2468 1376 1140 S 0 0,1 0: 00,88 init 
5849 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
8063 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
9732 root 16 0 8280 2728 2168 S 0 0,3 0: 00,02 sshd 
9746 chikorit 18 0 8412 1444 864 S 0 0,1 0: 01,10 sshd 
9747 chikorit 18 0 4576 1960 1488 S 0 0,2 0: 00,24 bash 
13706 chikorit 15 0 2344 1088 884 R 0 0.1 0: 00.03 oben 
15745 chikorit 15 0 12968 5108 1280 S 0 0,5 0: 00,00 apache2 
15751 chikorit 15 0 72184 25 m 18 m S 0 2,5 0: 00,37 php5-fpm 
15790 chikorit 18 0 12472 4640 1192 S 0 0,4 0: 00,00 apache2 
15797 chikorit 15 0 72888 23 m 16 m S 0 2,3 0: 00,06 php5-fpm 
16038 root 15 0 67772 2848 592 D 0 0,3 0: 00,00 php5-fpm 
16309 syslog 18 0 24084 1316 992 S 0 0.1 0: 00.07 rsyslogd 
16316 root 15 0 5472 908 500 S 0 0.1 0: 00.00 sshd 
16326 root 15 0 2304 908 712 S 0 0.1 0: 00.02 cron 
17464 root 15 0 10252 7560 856 D 0 0,7 0: 01,88 psad 
17466 root 18 0 1684 276 208 S 0 0.0 0: 00.31 psadwatchd 
17559 root 18 0 11444 2020 732 S 0 0,2 0: 00,47 sendmail-mta 
17688 root 15 0 10252 5388 1136 S 0 0,5 0: 03,81 Python 
17752 teamspea 19 0 44648 7308 4676 S 0 0,7 1: 09,70 ts3server_linux 
18098 root 15 0 12336 6380 3032 S 0 0,6 0: 00,47 apache2 
18099 chikorit 18 0 10368 2536 464 S 0 0,2 0: 00,00 apache2 
18120 ntp 15 0 4336 1316 984 S 0 0,1 0: 00,87 ntpd 
18379 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
18387 mysql 15 0 62796 36m 5864 S 0 3,6 1: 43,26 mysqld 
19584 root 15 0 12336 4028 668 S 0 0,4 0: 00,02 apache2 
22498 root 16 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
24260 root 15 0 67772 3612 1356 S 0 0,3 0: 00,22 php5-fpm 
27712 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
27730 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
30343 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 
30366 root 15 0 12336 4028 668 S 0 0,4 0: 00,00 apache2 

Dies ist der freie Widder von heute.

             Insgesamt verwendete kostenlose gemeinsam genutzte Puffer zwischengespeichert
Mem: 1024 302 721 0 0 0
- / + Puffer / Cache: 302 721
Swap: 0 0 0

Update: Sehen Sie sich die Protokolle an, insbesondere das PHP5-FPM, das die CPU-Spitze verursacht. Ich fand, dass sein Segment aus irgendeinem offensichtlichen Grund fehlerhaft war.

[03-Jun-2012 06:11:20] HINWEIS: [Pool www] Kind 14132 gestartet
[03-Jun-2012 06:11:25] WARNUNG: [pool www] Kind 13664 wurde auf Signal 11 (SIGSEGV) nach 53.686322 Sekunden nach dem Start beendet
[03-Jun-2012 06:11:25] HINWEIS: [Pool www] Kind 14328 gestartet
[03-Jun-2012 06:11:25] WARNUNG: [pool www] Kind 14132 wurde auf Signal 11 (SIGSEGV) nach 4,708681 Sekunden nach dem Start beendet
[03-Jun-2012 06:11:25] HINWEIS: [pool www] Kind 14329 wurde gestartet
[03-Jun-2012 06:11:58] WARNUNG: [Pool www] Kind 14328 wurde auf Signal 11 (SIGSEGV) nach 32.981228 Sekunden vom Start beendet
[03-Jun-2012 06:11:58] HINWEIS: [Pool www] Kind 15745 gestartet
[03-Jun-2012 06:12:25] WARNUNG: [pool www] Kind 15745 wurde nach 27.442864 Sekunden nach dem Start auf Signal 11 (SIGSEGV) beendet
[03-Jun-2012 06:12:25] HINWEIS: [Pool www] Kind 17446 gestartet
[03-Jun-2012 06:12:25] WARNUNG: [pool www] Kind 14329 wurde auf Signal 11 (SIGSEGV) nach 60,411278 Sekunden nach dem Start beendet
[03-Jun-2012 06:12:25] HINWEIS: [Pool www] Kind 17447 gestartet
[03-Jun-2012 06:13:02] WARNUNG: [Pool www] Kind 17446 wurde auf Signal 11 (SIGSEGV) nach 36.746793 Sekunden vom Start beendet
[03-Jun-2012 06:13:02] HINWEIS: [Pool www] Kind 18133 gestartet
[03-Jun-2012 06:13:48] WARNUNG: [pool www] Kind 17447 wurde auf Signal 11 (SIGSEGV) nach 82.710107 Sekunden nach dem Start beendet

Ich denke, dass dies das Problem verursachen könnte. Wenn dies die Ursache ist, kann das Problem durch Ausschalten auf fastcgi / fcgid möglicherweise behoben werden. Trotzdem möchte ich sehen, ob dies möglicherweise durch etwas anderes verursacht wird.

Ich würde erwarten, dass der Server Speicherprobleme hat. Dies führt dazu, dass der Container warten muss, bis Daten von der Festplatte und nicht von Puffern stammen. Wenn Sie Zugriff auf den Server haben, versuchen vmstatSie , ihn auszuführen , anstatt ihn im Container auszuführen. Die Speicherverwaltung für virtuelle Server hängt vom Hostserver ab. Das erste, was mir auffällt, ist, dass Ihre Daten nicht gepuffert, zwischengespeichert oder ausgetauscht werden. Dies alles ist wichtig für die Leistung.

Um zu sehen, welcher Prozess hohe E / A verursacht, können Sie dstatoder verwenden iotop.

Um zu sehen, warum PHP abstürzt, stellen Sie beim Starten von Apache sicher, dass Sie ausgeführt werden ulimit -c unlimited. Wenn PHP das nächste Mal abstürzt, haben Sie einen Core Dump. Verwenden Sie den btBefehl inside gdb, um eine Stapelverfolgung des Absturzes zu erhalten. Z.B

gdb /usr/bin/httpd core
(gdb) bt

Siehe: http://www.network-theory.co.uk/articles/gccdebug.html

Aus der Sicht der Dinge wurde die hohe CPU-Auslastung wahrscheinlich durch ein Wordpress-Plugin, den Google XML Sitemap-Generator, verursacht. Nach dem Deaktivieren gingen die CPU-Durchschnittswerte meistens zurück. Überprüfen Sie dennoch die Plugins, um alle zu entfernen, die möglicherweise zu viel CPU verbrauchen.

Überprüfen Sie auch, ob es keine tatsächlichen Probleme mit den Subsystemen der physischen Festplatte gibt - ein Wiederherstellungs-Raid, eine ausgefallene BBU, eine angeschlagene einzelne Festplatte ... können ebenfalls ähnliche Symptome verursachen