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

9

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

Laden und Speichernutzung

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

Geben Sie hier die Bildbeschreibung ein

und

Geben Sie hier die Bildbeschreibung ein

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

Geben Sie hier die Bildbeschreibung ein

iotop -a

Geben Sie hier die Bildbeschreibung ein

Strohhut
quelle
1
99% IOwait mit 0 Festplatten lesen und schreiben sieht nicht gut aus. Hier wird serverfault.com/questions/426181/… erwähnt, dass E / A nicht nur mit der Festplattenaktivität zusammenhängen kann, sondern auch mit dem Netzwerk. Könnten Sie dies beispielsweise mit iftop (und anderen Tools) überprüfen?
Andrey Sapegin
@ AndreySapegin hinzugefügt iftop
Strohhut
Ich denke, das Problem war mit der Disc, auf der die AWS-Instanz bereitgestellt wurde. Ich habe AMI der aktuellen Instanz erstellt und damit eine neue Instanz gestartet. Jetzt gibt es keine zusätzliche Belastung für I / O
Straw Hat
@StrawWas bedeutet das, dass Sie glauben, dass bei Ihrer ersten Instanz etwas mit der CD nicht stimmt?
Sbrattla
@sbrattla Nein, denke ich. Nach ein paar Tagen tauchte das gleiche Problem auf
Strohhut

Antworten:

2

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.

fgbreel
quelle
Das Verschieben von MySQL in eine RDS-Instanz wird funktionieren?
Strohhut
1
Das Hauptproblem liegt in der hohen Anzahl von Itens in einer Postfix-Warteschlange, die Ihre Iops frisst, wie Sie mit dem qshape deferredBefehl sehen können.
fgbreel
postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cf
Strohhut
postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1habe diese Fehlerqshape deferred
Strohhut
1
Ich denke, Ihr Postfix kann falsch konfiguriert sein, aber schauen Sie sich für Ihr aktuelles Problem an, wie viele E-Mails Sie haben /var/lib/postfix/deferred. Stellen Sie sie zur holdweiteren Untersuchung oder Bereinigung in die Warteschlange.
fgbreel
1

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.
Shodanshok
quelle
iostat -x -k 5 2 und auch in Frage hinzugefügt
Strohhut
1

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.

ojovirtual
quelle
0

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 .

MrMajestyk
quelle
-3

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?

Überdenken
quelle
EC2 ist eine Virtualisierungsplattform und verwendet virtuelle Festplatten. DMA ist hier nicht der Schuldige. Wie auch immer, ein IRQ-Sturm belastet die CPU und nicht die Festplatte.
Shodanshok
Ja und IRQ bedeutet Interrupts.
Overmind
EC2 ist so weit wie möglich von solchen Problemen entfernt, würde ich sagen. E / A ist an den Instanztyp gebunden - und am Ende an eine wirklich teure SAN-Lösung mit viel Kapazität.
MrMajestyk