Frage wa (Warten auf I / O) vom Top-Befehl ist groß


Ich habe ein Forum mit vielen Besuchern, an manchen Tagen steigt die Auslastung auf 40 ohne Erhöhung der Anzahl der Besucher. Wie Sie aus der folgenden Ausgabe sehen können, ist die Wartezeit hoch (57%). Wie finde ich den Grund dafür?
Die Serversoftware ist Apache, MySQL und 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


Ursprung


Ist das ein physischer Server (dediziert) oder ein VPS oder Shared Hosting Server? Dies macht einen großen Unterschied. - Tom O'Connor
Das ist gewidmet. Dieses Problem ist gelöst. Der Server hatte eine große Leseanforderung für Bilder. - usef_ksa


Antworten:


Hier sind ein paar Werkzeuge, um Festplattenaktivität zu finden:

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

Im ps auxf Sie sehen auch, welche Prozesse sich im nicht interpretierbaren Disk-Schlaf befinden (D) weil sie auf I / O warten.

An manchen Tagen steigt die Last auf 40, ohne dass die Anzahl der Besucher steigt.

Sie können auch eine Sicherungskopie erstellen und prüfen, ob die Festplatte langsam versagt. Eine Festplatte beginnt im Allgemeinen zu verlangsamen, bevor sie abstürzt. Dies könnte auch die hohe Belastung erklären.


29
2018-06-29 12:00



DIESE Dokument ist fantastisch zu erklären, Engpässe mit den oben genannten Tools zu erkennen. Offiziell geht es um NIC-Tuning, aber die vorgestellten Techniken und Tools haben eine viel breitere Anwendung als nur das. - Marcin
@marcin 404 Fehler - satch_boogie
web.archive.org/web/20111114212033/http://www.redhat.com/promo/... @satch_boogie - 2upmedia


Die Ausgabe von oben deutet darauf hin, dass das DBMS die meisten E / A-Wartezeiten durchläuft. Daher sind Probleme bei der Datenbankoptimierung ein offensichtlicher Kandidat für die Untersuchung.

E / A, die auf einem Datenbankserver warten - insbesondere bei Lastspitzen - ist ein Hinweis darauf, dass Ihr DBMS entweder fest an der Festplatte gebunden ist (d. H. Sie benötigen ein schnelleres Festplattensubsystem) oder dass es ein Optimierungsproblem gibt. Sie sollten wahrscheinlich auch in die Profilerstellung Ihres Datenbankservers schauen - also eine Übersicht darüber bekommen, was er macht und welche Abfragen sich die Zeit nehmen.

Einige Startpunkte für die Diagnose von Problemen bei der Datenbankoptimierung: -

  • Suchen Sie die Abfragen, die die meiste Zeit beanspruchen, und sehen Sie sich die Abfragepläne an. Sehen Sie, ob irgendwelche ungeraden Abfragepläne wie eine Tabellensuche haben, wo es nicht sein sollte. Vielleicht benötigt die Datenbank einen Index hinzugefügt.

  • Lange Wartezeiten für Ressourcen können bedeuten, dass einige wichtige Ressourcenpools erweitert werden müssen.

  • Lange I / O-Wartezeiten können bedeuten, dass Sie ein schnelleres Festplatten-Subsystem benötigen.

  • Sind Ihre Protokoll- und Datenvolumes auf separaten Laufwerken? Datenbankprotokolle haben viele kleine sequentielle Schreibvorgänge (im Wesentlichen verhalten sie sich wie ein Ringpuffer). Wenn Sie einen ausgelasteten Direktzugriff haben, der dieselben Laufwerke wie Ihre Protokolle nutzt, wirkt sich dies ungünstig auf den Durchsatz der Protokollierung aus. Damit eine Datenbanktransaktion festgeschrieben werden kann, müssen die Protokolleinträge auf die Festplatte geschrieben werden, wodurch ein Flaschenhals für das gesamte System entsteht.

    Beachten Sie, dass einige MySQL-Speicher-Engines keine Protokolle verwenden, was in Ihrem Fall kein Problem darstellt.

Fußnote: Warteschlangensysteme

Warteschlangensysteme (ein statistisches Modell für den Durchsatz) werden hyperbolisch langsamer, wenn sich das System der Sättigung nähert. Für eine Annäherung auf hoher Ebene hat ein System, das 50% gesättigt ist, eine durchschnittliche Warteschlangenlänge von 2. Ein System, das 90% gesättigt ist, hat eine Warteschlangenlänge von 10, ein System, das zu 99% gesättigt ist, hat eine Warteschlangenlänge von 100.

Auf einem System, das nahe an der Sättigung ist, können daher kleine Änderungen in der Last zu großen Änderungen der Wartezeiten führen, die sich in diesem Fall als die Zeit zeigen, die auf I / O gewartet wird. Wenn die E / A-Kapazität Ihres Festplattensubsystems nahezu gesättigt ist, können kleine Laständerungen zu erheblichen Änderungen der Antwortzeiten führen.


4
2018-06-30 09:15





Lauf iotop, oder atop -dD, um zu sehen, welche Prozesse io tun. Benutzen strace wenn Sie genauer hinsehen wollen.


2
2018-06-29 11:51





In beiden Bildschirmen sieht es nach "mysqld" aus.

Sie müssen sehen, was dieser Daemon macht ... welche Abfragen ausgeführt werden.


0
2018-06-29 13:23





Wie Flip sagt, sieht es so aus, als ob das Problem in der Umgebung von mysql liegt.

Etwa die Hälfte Ihres physischen Speichers wird derzeit für das I / O-Caching verwendet - Forensoftware generiert normalerweise viele schnelle Abfragen, die eine kleine Anzahl von Zeilen mit stark schiefen, heißen Bereichen der Festplatte zurückgeben - also ist etwas definitiv kompliziert, wenn das System Geld verbraucht so viel Wartezeit.

Ich sehe immer nur die CPU / Festplatten-Nutzung, wenn Abfragen laufen, die Millionen von Zeilen aktualisieren.

Der hohe Lastdurchschnitt ist eine direkte Folge der E / A.

Heben Sie Ihre mysql-Protokollierung auf, um zu sehen, ob sich dort schlechter Code befindet / das Ändern von Indizes würde helfen. Das Analysieren Ihrer Tabellen kann helfen (aber wahrscheinlich nicht viel).

C.


0
2018-06-30 08:54





An manchen Tagen steigt die Last auf 40, ohne die Anzahl zu erhöhen   Besucher.

Was die Benutzer tun, könnte genauso wichtig sein wie die Anzahl, die tatsächlich da ist. Vorgänge wie das Durchsuchen des Forums sind schwieriger als das Laden und Anzeigen einzelner Threads oder Listen von Threads.

Außerdem: Laufen Sie auf einem dedizierten Server oder einem VPS? Wenn sich Ihr Dienst nicht auf einem dedizierten Server befindet, wirken sich die Aktionen von Apps auf demselben Host aus, da die VMs, mit denen Ihre VM einen Host gemeinsam nutzt, um eine Freigabe der E / A-Ressource konkurrieren.

Wie andere hingewiesen haben, Werkzeuge wie iotop hilft Ihnen, tiefer in die Aufgaben zu schauen, die auf E / A-Antworten warten und auf welche Dateien sie gerade zugreifen.


0
2018-06-29 13:13



Es ist dedizierter Server. Ich beschließe, MySQL auf einem separaten Server laufen zu lassen. Die Serverlast ist jetzt in Ordnung, ich werde die Tools wie iotop verwenden, um das Problem in der Zukunft zu erkennen. Vielen Dank für euch alle. - usef_ksa