Seit einigen Tagen habe ich seltsame I/O-Spitzen in einer virtuellen Maschine.
Es ist 2.6.32-504.el6.x86_64 #1 SMP Dienstag, 16. September 2014, 01:56:35 EDT x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server Version 6.6 (Santiago)
Etwa 50 GB Speicher und 24 CPUs führen den Elasticsearch-Datenknoten aus.
Wir haben Timeouts bei Anfragen an diesen Elasticsearch-Knoten festgestellt und konnten nach der Überprüfung der VM nur feststellen, dass die Festplatten-E/A sporadisch hängen bleibt. Ich habe IOping auf einer der Festplatten in der virtuellen Maschine verwendet.
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=1 Zeit=3,76 ms (Aufwärmphase)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=2 Zeit=1,17 s
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=3 Zeit=131,7 us
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=4 Zeit=282,8 us
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=5 Zeit=999,4 ms
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=6 Zeit=632,7 ms
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=7 Zeit=2,15 s (langsam)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=8 Zeit=400,2 ms
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=9 Zeit=20,0 s (langsam)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=10 Zeit=1,10 ms (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=11 Zeit=1,30 ms (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=12 Zeit=2,20 ms (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=13 Zeit=2,61 ms (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=14 Zeit=203,6 us (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=15 Zeit=1,09 ms (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=16 Zeit=319,3 us (schnell)
4 KiB <<< /dev/sdf1 (Blockgerät 100,0 GiB): Anfrage=17 Zeit=249,8 us (schnell)
Wie Sie sehen, gab es einen 20-Sekunden-Spitzenwert auf einmal. Die virtuelle Maschine befindet sich auf VMware ESXi Blade. Der Datenspeicher wird von drei weiteren virtuellen Maschinen verwendet, aber keine davon zeigt diese Art von Latenzproblemen. Ich habe fsck und tune2fs ausprobiert und beide zeigten keine Probleme mit dem Dateisystem.
Als dies auftrat, gab es keine Updates auf der virtuellen Maschine. Jeder Hinweis zur Fehlerbehebung dieses Problems ist willkommen.
edit: hier sind die atop -d-Informationen. Es scheint, als ob lv zu 100 % ausgelastet ist und Java (Elasticsearch liest in diesem Moment)
LVM | vg00-lv_data | beschäftigt 100 % | | lesen 8904 | schreiben 4 | | KiB/r 11 | KiB/w 4 |
| MBr/s 10,03 | MBw/s 0,00 | | avq 21,41 | avio 1,12 ms |PID TID
RDDSK WRDSK
WCANCL DSK
CMD 1/12629 -
100,3 Mio. 12.000 0.000 100 %
Java
Antwort1
Letztendlich scheint alles durch die Elasticsearch verursacht worden zu sein. Wir haben den Knoten aus dem Cluster ausgeschlossen und ihn dann wieder hinzugefügt, wodurch Shards von der Maschine und dann wieder zurück auf die Maschine verschoben wurden. Aus irgendeinem seltsamen Grund hat das das Problem behoben.