Ich habe CPU-E / A-Wartezeiten von ungefähr 50%, aber wenn ich sie ausführe iostat 1, zeigt sie nur geringe bis gar keine Festplattenaktivität.

Welche Ursachen warten ohne iops?

HINWEIS: Hier sind keine NFS- oder FUSE-Dateisysteme vorhanden, es wird jedoch Xen-Virtualisierung verwendet.

NFS kann dies, und es würde mich nicht wundern, wenn andere Netzwerk-Dateisysteme (und sogar FUSE-basierte Geräte) ähnliche Auswirkungen hätten.

Besteht die Möglichkeit, dass andere VMs auf dem Server die Festplatte beschädigen?

Ich weiß mit Virtualisierung, dass Sie einige seltsame Ergebnisse erhalten können, wenn der Host-Knoten überlastet ist.

Wenn dies die Amazon EC2 Xen-Umgebung ist, die instanzbasierten Speicher verwendet, bitten Sie Amazon, den Zustand des Hosts zu überprüfen, der dieses Image enthält.

Wenn es sich um eine Xen-Umgebung handelt, in der Sie auf den Hypervisor zugreifen können, überprüfen Sie IOwait von außen auf das für die xvda- und xvdb-Geräte verwendete Festplatten-Image (Datei, Netzwerk, LVM-Slice usw.). Sie sollten auch das E / A-System im Allgemeinen auf den Hypervisor überprüfen, da andere Plattengeräte möglicherweise die Systemressourcen monopolisieren.

iostat -txk 5

ist in der Regel ein gutes Start-Diagnosewerkzeug. Für ALLE verfügbaren Geräte sind 5-Sekunden-Zusammenfassungen der E / A erforderlich. Dies ist sowohl beim Ein- als auch beim Ausblenden des VM-Images hilfreich.

Überprüfen Sie die verfügbaren Dateideskriptoren / Inodes. Wenn Sie das Limit erreichen, tauschen sie und imitieren iowait

Bearbeiten

Ich habe gesehen, dass Sie Xen verwenden. Sehen Sie sich Ihre aktuellen Interrupts an. Möglicherweise ist blkif höher als normal.

Jetzt etwas zu spät, aber Munin installiert und es wird wirklich helfen, zukünftiges Debuggen.

sudo sysctl vm.block_dump=1

Überprüfen Sie dann dmesg, um zu sehen, was das Lesen / Schreiben von Blöcken oder das Verschmutzen von Inodes bewirkt.

Überprüfen Sie auch die Dateibeschränkung in der Datei limits.conf. Möglicherweise fordert ein Prozess mehr Dateien an, als er öffnen darf.

WARNUNG: HDPARM IST GEFÄHRLICH, LESEN SIE IMMER DEN BEFEHL, DEN SIE VERWENDEN WERDEN!

Wenn keine anderen virtuellen Maschinen die Festplatte (n) belasten, tun Sie dies

hdparm -f

auf den zugrunde liegenden physischen Datenträgern. Möglicherweise funktioniert der Festplatten-Cache nicht richtig. Dadurch werden die im Cache gespeicherten Daten geleert, und Sie können die E / A ständig überwachen, ob sie nach dem Leeren wieder ansteigen. Wenn ja, liegt ein Cache-Problem vor.

Bei durchschnittlicher Auslastung sind blockierte Netzwerkvorgänge (dh lange Anrufe an einen externen DB-Server) häufiger geworden. Ich weiß es nicht genau, aber ich vermute, dass Netzwerk-E / A dazu führen kann, dass die CPU wartet, bis sie hochfährt. Kann das jemand bestätigen?

Könnten Loopback-Geräte sein, die selbst über das Netzwerk gemountet werden.

Auf meinen Maschinen ist NFS der größte IO-WAIT "Produzent". Ich habe eine SSD in meinem Laptop, die verdammt schnell ist, also ist "echtes IO" nicht das Problem. Trotzdem habe ich wegen meiner gemounteten NFS-Shares manchmal eine Menge IO-Wartezeit.

SCP scheint manchmal auch zu IO Wait zu führen, jedoch in weit geringerem Maße.

Das kann alles sein. Es bedeutet nur, dass etwas auf das Ende des E / A-Vorgangs wartet. Sie können über ps herausfinden, um welchen Prozess es sich handelt, dann gdb anhängen und die Rückverfolgung überprüfen, um festzustellen, welcher Anruf hängt (normalerweise sind dies netzwerkbezogene Dinge oder plötzlich getrennte Festplatten). Für fd info check out / proc.

Ich habe auch ein ähnliches Problem erfahren, kurz bevor eine Festplatte in einem RAID ausfiel und einige SATA-Kabel mit engen Biegungen ausfielen .

Die CPU-Auslastung lag bei nahezu 0%, aber 1 oder mehr CPUs auf einem 4-Core-System verbrachten 100% ihrer Zeit über längere Zeiträume in IOwait (über topMulti-Line-CPU-Anzeige ermittelt) mit sehr geringen IOps und Bandbreite (ermittelt) via iostat), aber stoßweise hohe Interruptaktivität. Die interaktive Verwendung der Befehlszeile war bei jedem Datenträgerzugriff schmerzhaft (dh beim automatischen Speichern aus einer emacsSitzung einer anderen Person ), aber ansonsten tolerierbar, sobald die Zeiträume von IOwait verstrichen sind (und vermutlich waren die Vorgänge nach vielen Wiederholungsversuchen erfolgreich).