Hohe iowait mit java-Prozesse auf linux
Habe ich ein Auger-system mit vielen Maschinen/Knoten beteiligt. Jede Maschine mehrere JVMs zu tun verschiedene Dinge. Es ist eine "geschichtete" - Architektur, wobei jede Schicht besteht aus vielen JVM läuft über die Maschinen. Grundsätzlich ist die oberste Schicht JVM erhält input von außen über Dateien, analysiert die Eingabe und sendet es so viele kleine Einträge für "Speicher" in der Schicht-zwei. Schicht-zwei eigentlich nicht bestehen, die Daten selbst aber eigentlich besteht es in der Schicht-drei (HBase und Solr) und HBase, die tatsächlich nicht bestehen und Sie selbst, da schickt er es an Schicht-vier (HDFS) für die Persistenz.
Großteil der Kommunikation unter den Schichten ist synchronisiert, so natürlich es endet in einer Menge von threads wartet auf unteren Ebenen zu vervollständigen. Aber ich würde erwarten, dass die wartenden threads "frei" zu sein wrt CPU-Auslastung.
Sehe ich ein sehr hohes iowait (%wa in top -) obwohl - so etwas wie 80-90% iowait und nur 10-20% sys/usr CPU-Auslastung. Das system scheint erschöpft - langsam-login via ssh und langsam zu reagieren, um Befehle etc.
Meine Frage ist, ob all diese JVM-threads warten auf unteren Ebenen zu vervollständigen, die das verursachen kann? Ist es eigentlich nicht "frei" warten auf Antworten (sockets). Macht es einen Unterschied diesbezüglich, ob die verschiedenen Schichten verwendet blockieren oder nicht-blockierend (NIO) io? Genau, in welche Situationen wird Linux zählen etwas wie iowait (%wa in top -)? Wenn alle threads in allen JVMs auf die Maschinen sind in einer situation, wo es darauf wartet (zählen, denn es gibt keinen anderen thread laufen, um etwas sinnvolles tun in der Zwischenzeit)? Oder macht die threads warten auch Anzahl in %wa obwohl es andere Prozesse bereit, um die CPU verwenden für die Echtzeit-Verarbeitung?
Ich würde wirklich wollen, um eine ausführliche Erklärung, wie es funktioniert und wie diese zu interpretieren hoch %wa. Am Anfang habe ich gedacht, dass es gezählt, %wa, wenn alle threads, wo warten, aber, dass dort, wo eigentlich genügend Platz für mehr zu tun, also habe ich versucht, erhöhen Sie die Anzahl der threads erwartet man mehr Durchsatz, aber das passiert nicht. So ist es ein echtes problem, nicht nur ein "optisches" problem bei der Suche an der Spitze.
Die folgende Ausgabe stammt von einer Maschine, wo nur HBase und HDFS ausgeführt wird. Es ist auf Maschinen mit HBase und/oder HDFS, dass ich das problem zeigt (am deutlichsten)
--- jps ---
19498 DataNode
19690 HRegionServer
19327 SecondaryNameNode
---- typical top -------
top - 11:13:21 up 14 days, 18:20, 1 user, load average: 4.83, 4.50, 4.25
Tasks: 99 total, 1 running, 98 sleeping, 0 stopped, 0 zombie
Cpu(s): 14.1%us, 4.3%sy, 0.0%ni, 5.4%id, 74.8%wa, 0.0%hi, 1.3%si, 0.0%st
Mem: 7133800k total, 7099632k used, 34168k free, 55540k buffers
Swap: 487416k total, 248k used, 487168k free, 2076804k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
19690 hbase 20 0 4629m 4.2g 9244 S 51 61.7 194:08.84 java
19498 hdfs 20 0 1030m 116m 9076 S 16 1.7 75:29.26 java
---- iostat -kd 1 ----
root@edrxen1-2:~# iostat -kd 1
Linux 2.6.32-29-server (edrxen1-2) 02/22/2012 _x86_64_ (2 CPU)
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 3.53 3.36 15.66 4279502 19973226
dm-0 319.44 6959.14 422.37 8876213913 538720280
dm-1 0.00 0.00 0.00 912 624
xvdb 229.03 6955.81 406.71 8871957888 518747772
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 0.00 0.00 0.00 0 0
dm-0 122.00 3852.00 0.00 3852 0
dm-1 0.00 0.00 0.00 0 0
xvdb 105.00 3252.00 0.00 3252 0
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 0.00 0.00 0.00 0 0
dm-0 57.00 1712.00 0.00 1712 0
dm-1 0.00 0.00 0.00 0 0
xvdb 78.00 2428.00 0.00 2428 0
--- iostat -x ---
Linux 2.6.32-29-server (edrxen1-2) 02/22/2012 _x86_64_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
8.06 0.00 3.29 65.14 0.08 23.43
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.74 0.35 3.18 6.72 31.32 10.78 0.11 30.28 6.24 2.20
dm-0 0.00 0.00 213.15 106.59 13866.95 852.73 46.04 1.29 14.41 2.83 90.58
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 5.78 1.12 0.00
xvdb 0.07 86.97 212.73 15.69 13860.27 821.42 64.27 2.44 25.21 3.96 90.47
--- free -o ----
total used free shared buffers cached
Mem: 7133800 7099452 34348 0 55612 2082364
Swap: 487416 248 487168- Ich sehe eine Vielzahl von ähnliche Frage hier und da, aber diese auf ServerFault hat einige Dinge zu versuchen wrt hardware-Fehler: serverfault.com/questions/83778/... Hier ist ein weiteres auf der gleichen Linie, das ist, vielleicht gibt es einen Fehler, einige andere debugging-rund um das Thema: articledashboard.com/Article/Linux-and-High-I-O-Wait/959842
- Die Weiterführung dieser Gedanken...Fehlerzustände sind nicht Ihr Problem hier, unter der Annahme, dass Sie sehen, wie dieser auf mehreren physischen Maschinen, sondern Werkzeuge, die in diesen Diskussionen geben könnten einige zusätzliche Details über die Wartezeiten. Having said, die, ich interessiere mich sehr für jemanden zu reagieren, um die "Gründliche Erklärung, wie es funktioniert" - Teil deiner Frage.
- Gibt es eine Spalte Status in der Spitze. Was bedeutet es zeigen, wenn Sie die Fäden auf einer box? Können Sie ein
topAusgang? Die Ergebnisse deriostat -kd 1? Die Ergebnisse derfree -o? - Gut, man könnte sehen, viele Fragen, aber ich sehe alle, aber einer als Vertiefung, Fragen und "vorgeschlagene Teil-Antworten" 🙂 DIE Frage ist, welche Bedingungen in vielen JVMs auf einem linux-Computer wird das OS zählen iowait (%wa oben)
Du musst angemeldet sein, um einen Kommentar abzugeben.
IO warten auf Linux zeigt, dass die Prozesse blockiert sind unterbrechungsfreien I/O. In der Praxis bedeutet dies normalerweise, dass der Prozess der Durchführung Zugriff auf die Festplatte-in diesem Fall würde ich sagen eines der folgenden:
iostat -xhelfen kann, wie es zeige ein extra "%util" - Spalte, die angibt, welcher Prozentsatz der Zeit, die Festplatte ist "besetzt".)