Hohe Last aufgrund von E / A-Wartezeiten in Ubuntu 12.04 auf der EC2-Instanz

Ich verwende den Ubuntu-Server 12.04 und habe Probleme, die Ursache für die Auslastung zu finden. Die Antwortzeit des Servers hat sich seit der letzten Woche geändert

nach dem Lesen der Linux-Fehlerbehebung, Teil I: Hohe Last

Es scheint, dass es kein Problem mit CPU und RAM gibt, und diese Last kann mit der E / A-gebundenen Last in Verbindung gebracht werden, indem der topBefehl verwendet wird, den ich nach der Ausgabe erhalten habe

Hier ist 97.6%waRAM frei und es wird kein Swap verwendet.

Es folgt eine Befehlsausgabe, iostatdie sät, dass es gibt89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

Ich habe auch verwendet, iotopwas nach dem Fixintervall 99% E / A anzeigt, Festplatte schreibt ich Beobachter als1266 KB/s

und

Ist das schlecht wenn die Reaktionszeit verringert wird. Was verursacht das?

EDITS, die von anderen gefragt werden

iftop O / P.

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

Ausgabe von iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@ Shodanshok Punkt 2

iotop -a

Optimieren Sie Ihren MySQL-Dienst, um zu vermeiden, dass Sie die Festplatte berühren und in Ihrer Postfix-Warteschlange aufpassen. Möglicherweise befinden sich viele E-Mails in einer E / A-sensiblen Warteschlange (dh verzögerte, kleine Nachrichten mit zufälligem Leseverhalten).

Ihr E-Mail-System wurde als Relais für Spammer verwendet.

Sehen Sie sich die Postfix-Dokumentation an und beschränken Sie den Relay-Zugriff auf Ihren MTA.

Bearbeitet nach zusätzlichen Informationen, die mit iostat und iotop gesammelt wurden.
Ihre Festplatte ist zu 100% geladen, da die verfügbaren IOPS ausgehen: Gemäß iostat haben Sie eine konstante IOPS von 50+ (85 w / s - 35 zusammengeführte w / s). EC2-Instanzen, insbesondere billige, haben eine starke Obergrenze für anhaltende IOPS (im Bereich von 30 bis 50 IOPS).

Gemäß der neuen iotop-Ausgabe verbrauchen sowohl MySQL als auch Bounce eine erhebliche Menge an IOPS. Die Ausgabe von iotop scheint jedoch nicht vollständig oder zumindest schlecht sortiert zu sein. Können Sie "iotop -a" erneut ausführen und einmal nach IOPS und ein anderes Mal nach Festplattenschreiben sortieren?

Ursprüngliche Antwort
Meine Wette: Der "Bounce" -Prozess gibt viele synchronisierte Schreibvorgänge aus, die das von Amazon angebotene virtuelle Festplattengerät verstopfen (übrigens, welches Profil verwenden Sie? EC2-Festplatten haben recht strenge Regeln für dauerhafte oder Burst-E / A).

Auf jeden Fall kann es manchmal etwas schwierig sein, festzustellen, welche E / A-Bandbreite brennt. Iotop ist zwar ein sehr gutes Tool, bietet Ihnen jedoch manchmal nicht die erforderlichen Informationen. Wir müssen tiefer gehen. Befolgen Sie also diese Ratschläge:

1. Zunächst müssen wir den Typ der zu verarbeitenden E / A und das betroffene Blockgerät identifizieren.
   Bitte führen Sie den folgenden Befehl aus : iostat -x -k 5 2. Bitte melden Sie beide Ergebnismengen.
2. Dann müssen wir die Prozesse identifizieren, die auf E / A warten .
   Wann kann "top" dafür verwendet werden: Starten Sie es, drücken Sie Umschalt + f (F), dann w, dann Eingabe, dann Umschalt + r (R). Die ersten Prozesse befinden sich im Status D oder D + (dh Warten auf Festplatte / Netzwerk). Bitte melden Sie die Liste zurück.
3. Verwenden Sie iotop, um die akkumulierten E / A-Werte für Prozesse anzuzeigen .
   Laufen Sie iotop -aungefähr eine Minute und fügen Sie hier die Ausgabe ein.

Ein bisschen spät, aber ich hatte das gleiche Problem auf einem ähnlichen Computer und fand heraus, dass das Problem eine Reihe von beschädigten MySQL-Tabellen war. Da einige dieser Tabellen viele Daten enthielten, wurde viel E / A-Wartezeit erzeugt.

Suchen /var/log/mysql/error.logoder verwenden Sie mysqlcheck, um beschädigte Daten zu finden und zu reparieren.

Wie oben erwähnt, ist es sehr wahrscheinlich, dass Ihre EC2-Instanz mit einer E / A-Obergrenze ausgestattet ist oder auf einem Amazon EBS Standard-Volume gesichert ist, das einfach nicht sehr viel E / A liefert. Schauen Sie sich diese Seite an - sie beschreibt die verschiedenen Volume-Typen, die Amazon anbietet.

Selbst wenn Sie ein langsames Volume haben, sollten Sie dennoch in der Lage sein, relativ schnell darauf zu schreiben. Wenn Ihre Last jedoch von Natur aus zufällig ist, wie es scheint (SQL-Zeug), möchten Sie möglicherweise das IOPS aktualisieren Kapazität, da dies normalerweise die Obergrenze für die SQL-Leistung festlegt.

Aus Ihren Zahlen geht hervor, dass Ihnen mit Standardspeicher möglicherweise die IOPS ausgehen. Der Kauf eines schnelleren Speichers ist nicht so teuer. Werfen Sie einen Blick auf diese .

Die Festplatte befindet sich möglicherweise im Nicht-DMA-Modus. Bitte überprüfen Sie den DMA-Status des Laufwerks. (Befehl hdparm)

Wenn dies nicht der Fall ist, kann etwas anderes viele Interrupts erzeugen. Erinnert sich jemand an die aus der guten alten DOS-Ära?