Vraag wa (wachten op I / O) van het bovenste commando is groot


Ik heb een forum met veel bezoekers, op sommige dagen neemt de belasting toe tot 40 zonder toename van de aantal bezoekers. Zoals u aan de onderstaande uitvoer kunt zien, is de wachttijd hoog (57%). hoe vind ik de reden daarvoor?
De serversoftware is Apache, MySQL en PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

24
2018-06-29 11:46


oorsprong


Is dit een fysieke server (dedicated) of een VPS- of shared hosting-server? Dit maakt een enorm verschil. - Tom O'Connor
dit is opgedragen. dit probleem is opgelost. de server had veel leesverzoeken voor afbeeldingen. - usef_ksa


antwoorden:


Hier zijn een paar hulpmiddelen om schijfactiviteit te vinden:

  • iotop
  • vmstat 1
  • iostat 1
  • lsof
  • strace -e trace=open <application>
  • strace -e trace=open -p <pid>

In ps auxf je zult ook zien welke processen er zijn in een niet-interpreteerbare schijf slaap (D) omdat ze wachten op I / O.

Op sommige dagen neemt de belasting toe tot 40 zonder toename van de aantal bezoekers.

U kunt ook een back-up maken en zien of de harde schijf langzaam faalt. Een harde schijf begint over het algemeen te vertragen voordat hij sterft. Dit kan ook de hoge belasting verklaren.


29
2018-06-29 12:00



DEZE document is fantastisch in het uitleggen van spotting bottlenecks met behulp van de hierboven genoemde tools. Officieel gaat het om NIC-afstemming, maar de gepresenteerde technieken en hulpmiddelen hebben echt een veel bredere toepassing dan alleen dat. - Marcin
@marcin 404-fout - satch_boogie
web.archive.org/web/20111114212033/http://www.redhat.com/promo/... @satch_boogie - 2upmedia


De uitvoer van boven suggereert dat de DBMS de meeste I / O-wachttijden ondervindt, dus problemen met het afstemmen van databases zijn een voor de hand liggende kandidaat om te onderzoeken.

I / O wachten op een databaseserver - met name bij laadpieken - is een aanwijzing dat uw DBMS mogelijk schijfgebonden is (dat wil zeggen dat u een sneller schijfsubsysteem nodig hebt) of dat er een afstemmingsprobleem is. U zou waarschijnlijk ook moeten kijken naar het profileren van uw databaseserver - dat wil zeggen een spoor krijgen van wat het doet en welke vragen de tijd vragen.

Enkele startpunten voor het diagnosticeren van afstemmingsproblemen met de database: -

  • Zoek de query's die de meeste tijd in beslag nemen en bekijk de queryplannen. Kijk of er vreemde query-plannen zijn, zoals een tafelscan waar dit niet zou moeten zijn. Misschien heeft de database een index nodig.

  • Lange wachttijden voor resources kunnen betekenen dat een belangrijke resourcepool moet worden uitgebreid.

  • Lange I / O-wachttijden kunnen betekenen dat u een sneller schijfsubsysteem nodig hebt.

  • Bevinden uw log- en datavolumes zich op verschillende schijven? Database logs hebben veel kleine sequentiële schrijfbewerkingen (in wezen gedragen ze zich als een ringbuffer). Als u een bezette workload voor willekeurige toegang hebt, dezelfde schijven deelt als uw logboeken, heeft dit een ongunstige invloed op de verwerkingscapaciteit van de logboekregistratie. Voor een databasetransactie die moet worden vastgelegd, moeten de logboekinvoeren op schijf worden geschreven, dus dit plaatst een knelpunt op het hele systeem.

    Merk op dat sommige MySQL-opslagengines geen logboeken gebruiken, dus dit is misschien geen probleem in uw geval.

Voetnoot: wachtrijsystemen

Wachtrijsystemen (een statistisch model voor doorvoer) worden hyperbolisch langzamer naarmate het systeem de verzadiging nadert. Voor een benadering op hoog niveau heeft een systeem dat voor 50% verzadigd is een gemiddelde wachtrijlengte van 2. Een systeem dat voor 90% verzadigd is, heeft een wachtrijlengte van 10, een systeem dat voor 99% verzadigd is, heeft een wachtrijgingslengte van 100.

Op een systeem dat bijna verzadigd is, kunnen kleine veranderingen in de belasting dus resulteren in grote veranderingen in wachttijden, in dit geval manifesterend als de tijd die is doorgebracht met wachten op I / O. Als de I / O-capaciteit van uw schijfsubsysteem bijna verzadigd is, kunnen kleine wijzigingen in de belasting leiden tot aanzienlijke wijzigingen in responstijden.


4
2018-06-30 09:15





Rennen iotopof atop -dD, om te zien welke processen io doen. Gebruik strace als je het van dichterbij wilt bekijken.


2
2018-06-29 11:51





In beide schermen ziet het ernaar uit dat "mysqld" verantwoordelijk is.

Je moet zien wat die daemon aan het doen is ... welke vragen worden uitgevoerd.


0
2018-06-29 13:23





Zoals Flip zegt, lijkt het erop dat het probleem rond is wat mysql aan het doen is.

Ongeveer de helft van uw fysieke geheugen wordt momenteel gebruikt voor I / O-caching - forumsoftware genereert meestal veel snelle query's die kleine aantallen rijen retourneren, met zeer scheve hete delen van de schijf - dus er is iets dat absoluut fout gaat als het systeem uitgaven doet zoveel tijd wachten.

Ik zie alleen CPU / schijfgebruik op die manier bij het uitvoeren van query's die miljoenen rijen bijwerken.

Het hoge belastingsgemiddelde is een direct gevolg van de I / O.

Draai je mysql-logboek op om te zien of er slechte code in zit / wijzigen van indexen zou helpen. Analyse van uw tabellen kan helpen (maar waarschijnlijk niet veel).

C.


0
2018-06-30 08:54





Op sommige dagen neemt de belasting toe tot 40 zonder toename van het aantal   vistors.

Wat de gebruikers doen, kan net zo belangrijk zijn als het aantal dat er daadwerkelijk is. Bewerkingen zoals zoeken op het forum zullen veeleisender zijn dan alleen het laden en bekijken van individuele threads of lijsten met threads.

Ook: loopt u op een dedicated server of een VPS? Als uw service niet op een dedicated server is geïnstalleerd, hebben de acties van apps die op dezelfde host worden uitgevoerd, invloed omdat de VM's waarmee uw VM een host deelt, zullen strijden om een ​​deel van de I / O-resource.

Zoals anderen hebben opgemerkt, tools zoals iotop helpt u om dieper in te gaan op welke taken er wordt gewacht op I / O-antwoorden en op welke bestanden ze op dat moment toegang hebben.


0
2018-06-29 13:13



Het is een dedicated server. Ik besluit om MySQL op een aparte server te laten werken. Het laden van de server is nu goed, ik zal de tools zoals iotop gebruiken om het probleem in de toekomst te detecteren. heel erg bedankt voor jullie allemaal. - usef_ksa