Frage Fehlerbehebung für Latenzspitzen in ESXi NFS-Datenspeichern


Ich erlebe fsync Latenzen von herum fünf Sekunden auf NFS-Datenspeichern in ESXi, ausgelöst durch bestimmte VMs. Ich vermute, dass dies durch VMs verursacht werden könnte, die NCQ / TCQ verwenden, da dies bei virtuellen IDE-Laufwerken nicht der Fall ist.

Dies kann mit reproduziert werden fsync-Tester (von Ted Ts'o) und Ioping. Zum Beispiel mit einem Grml-Live-System mit einer 8-GB-Festplatte:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

Das sind 5 Sekunden, keine Millisekunden. Dies erzeugt sogar IO-Latenzen auf einer anderen VM, die auf demselben Host und demselben Datenspeicher ausgeführt wird:

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Wenn ich die erste VM in den lokalen Speicher verschiebe, sieht das völlig normal aus:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

Dinge, die ich versucht habe, machten keinen Unterschied:

  • Getestet mehrere ESXi Builds: 381591, 348481, 260247
  • Getestet auf unterschiedlicher Hardware, verschiedenen Intel- und AMD-Boxen
  • Getestet mit verschiedenen NFS-Servern zeigen alle das gleiche Verhalten:
    • OpenIndiana b147 (ZFS-Synchronisierung immer oder deaktiviert: kein Unterschied)
    • OpenIndiana b148 (ZFS-Synchronisierung immer oder deaktiviert: kein Unterschied)
    • Linux 2.6.32 (sync oder async: kein Unterschied)
    • Es macht keinen Unterschied, ob sich der NFS-Server auf demselben Computer (als virtuelle Speichereinheit) oder auf einem anderen Host befindet

Gastbetriebssystem getestet, Probleme zeigend:

  • Windows 7 64 Bit (mit CrystalDiskMark, Latenzspitzen treten meist während der Vorbereitungsphase auf)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Ich konnte dieses Problem auf Linux 2.6.18 VMs nicht reproduzieren.

Eine weitere Problemumgehung besteht in der Verwendung virtueller IDE-Festplatten (vs. SCSI / SAS). Dies beeinträchtigt jedoch die Leistung und die Anzahl der Laufwerke pro VM.

Update 2011-06-30:

Die Latenzspitzen scheinen öfter zu passieren, wenn die Anwendung vor fsync mehrere kleine Blöcke schreibt. Zum Beispiel macht fsync-tester dies (strace-Ausgabe):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

Ioping macht dies während der Vorbereitung der Datei:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

Die Setup-Phase von Ioping hängt fast immer, während fsync-Tester manchmal gut funktioniert. Kann jemand fsync-tester aktualisieren, um mehrere kleine Blöcke zu schreiben? Meine C-Fähigkeiten sind scheiße;)

Update 2011-07-02:

Dieses Problem tritt bei iSCSI nicht auf. Ich habe dies mit dem OpenIndiana COMSTAR iSCSI Server versucht. Aber iSCSI bietet Ihnen keinen einfachen Zugriff auf die VMDK-Dateien, sodass Sie sie zwischen Hosts mit Snapshots und rsync verschieben können.

Update 2011-07-06:

Dies ist Teil einer Wireshark-Erfassung, die von einer dritten VM auf demselben vSwitch erfasst wird. Dies alles geschieht auf demselben Host, ohne ein physisches Netzwerk.

Ich habe mit Zeit 20 angefangen. Es wurden keine Pakete gesendet, bis die fünf Sekunden Verzögerung vorbei war:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2. Update 2011-07-06:

Es scheint einen Einfluss von TCP-Fenstergrößen zu geben. Ich konnte dieses Problem nicht mit FreeNAS (basierend auf FreeBSD) als NFS-Server reproduzieren. Die Wireshark-Captures zeigten in regelmäßigen Abständen Aktualisierungen des TCP-Fensters auf 29127 Bytes. Ich habe sie nicht mit OpenIndiana gesehen, die standardmäßig größere Fenstergrößen verwendet.

Ich kann dieses Problem nicht mehr reproduzieren, wenn ich die folgenden Optionen in OpenIndiana einstelle und den NFS-Server neu starte:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Aber das kostet Leistung: Das Schreiben von / dev / zero in eine Datei mit dd_rescue reicht von 170 MB / s bis 80 MB / s.

Update 2011-07-07:

Ich habe das hochgeladen tcpdump erfassen (kann mit wireshark analysiert werden). In diesem Fall ist 192.168.250.2 der NFS-Server (OpenIndiana b148) und 192.168.250.10 der ESXi-Host.

Dinge, die ich während dieses Captures getestet habe:

Begonnen "Ioping -w 5 -i 0.2." zur Zeit 30, 5 Sekunden hängen in der Einrichtung, vervollständigt zur Zeit 40.

Begonnen "Ioping -w 5 -i 0.2." zur Zeit 60, 5 Sekunden hängen in der Einstellung, abgeschlossen zur Zeit 70.

Begann "fsync-tester" zum Zeitpunkt 90 mit der folgenden Ausgabe, gestoppt zum Zeitpunkt 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2. Update 2011-07-07:

Testete eine andere NFS-Server-VM, diesmal NexentaStor 3.0.5 Community Edition: Zeigt die gleichen Probleme.

Update 2011-07-31:

Ich kann dieses Problem auch auf dem neuen ESXi Build 4.1.0.433742 reproduzieren.


44
2018-06-29 08:33


Ursprung


Ich muss sagen, es ist schon eine Weile her, seit ein brandneuer Benutzer mit einer so gut dokumentierten und durchdachten Frage an den Vorstand gekommen ist - Ernsthaft, Hut ab vor dir. Es ist auch wirklich interessant, ich habe noch keinen fsync-Tester gefunden, bevor auch nicht danke. Das heißt, ich bin mir nicht sicher, ob ich etwas hinzufügen kann, du hast so viele Dinge ausprobiert, die ich schon hätte - ich würde sagen, VMWare selbst, um ehrlich zu sein, sie sind sehr gut darin, diese Art zu nehmen von "Long-Tail" / "kein Service-Ausfall" Zeug ernsthaft. Wie auch immer, ich wollte nur sagen, was du bisher gemacht hast :) - Chopper3
Leider kann ich die VMware-Website nicht kontaktieren: "Sie haben derzeit keine aktiven Support-Berechtigungen" - exo_cw
Ah, ja, das kann natürlich ein Problem sein ... - Chopper3
5 Sekunden Timeout mit NFS klang vertraut. In Linux NFS gibt es ein .7 Sekunden Timeout für RPC, das sich nach jedem Fehler verdoppelt und einen Major nach 3 fehlschlägt (Standardeinstellungen). .7 + 1,4 + 2,8 = 4,9 Sekunden. Es gibt eine Vielzahl von RPC-Authentifizierungsproblemen, die dies verursachen können. - Mark
@Ryan: Ich habe die Capture-Datei hochgeladen. Ich habe auch die hochgeladen nfsstat Ausgabe. - exo_cw


Antworten:


Dieses Problem scheint in ESXi 5 behoben zu sein. Ich habe Build 469512 erfolgreich getestet.


5
2017-09-13 06:54





Danke, nfsstat sieht gut aus. Ich habe die Erfassung überprüft. Habe nichts Schlüssiges gefunden, habe aber etwas Interessantes gefunden. Ich filterte auf tcp.time_delta> 5. Was ich in fand jeden Delay-Instanz war der genaue Start eines RPC-Aufrufs. Nicht alle neuen RPC-Aufrufe waren langsam, aber alle Verzögerungen erfolgten genau zum Beginn eines RPC-Aufrufs. Auch aus dem Capture scheint, dass 192.168.250.10 die gesamte Verzögerung enthält. 192.168.250.2 reagiert sofort auf alle Anfragen.

Ergebnisse:

  • Verzögerungen treten immer im ersten Paket eines RPC-Aufrufs auf
  • NFS-Befehlstypen waren nicht mit Verzögerungsinstanzen korreliert
  • Fragmentierung = verzögert nur das erste Paket

Ein großer Schreibanruf kann sich in 300 einzelne TCP-Pakete aufteilen, und nur der erste wird verzögert, aber der Rest fliegt alle durch. Niemals tritt die Verzögerung in der Mitte auf. Ich bin mir nicht sicher, wie sich die Fenstergröße auswirken könnte Anfang von der Verbindung so drastisch.

Nächste Schritte: Ich würde beginnen, die NFS-Optionen wie NFSSVC_MAXBLKSIZE nach unten anstatt das TCP-Fenster zu optimieren. Außerdem habe ich bemerkt, dass 2.6.18 funktioniert, während 2.6.38 nicht funktioniert. Ich weiß, dass Unterstützung für den VMXnet3-Treiber während dieses Zeitrahmens hinzugefügt wurde. Welche NIC-Treiber verwenden Sie auf den Hosts? TCP-Entlastung ja / nein? Um die 95-Sekunden-Marke gibt es mehr als 500 TCP-Pakete für einen einzelnen NFS-Schreibanruf. Was immer für TCP zuständig ist und die große PDU aufbrechen könnte, könnte blockieren.


3
2017-07-08 23:26



Ich habe versucht, nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots und nfs: nfs3_bsize alle bis 8192: Kein Unterschied, gleiche Probleme. Die Linux-Gäste benutzen nur ihre SCSI / SAS-Festplatten, kein NFS - der ESXi ist der NFS-Client, daher gibt es auf dem Linux-Gast keinen Netzwerktreiber. Auf der NFS-Serverseite habe ich sowohl virtuelles e1000 als auch vmxnet3 ausprobiert: Hat keinen Unterschied gemacht. Soweit ich weiß, verwendet ESXi nur TCP-Offloading für iSCSI. - exo_cw
Der Größte ? Ich bin der Grund, warum die Anpassung des TCP-Fensters einen Unterschied machen würde ... Mein Bauchgefühl sagt mir, dass es etwas damit zu tun hat, diese großen PDUs über TCP zu fragmentieren. Etwas im Netzwerk-Stack, das daran erstickt. Kann mir einfach nichts vorstellen, was zu dem Verhalten passt, das wir sehen. Wenn die Fenstergröße ein Problem war, sollten wir eine Latenz sehen, die Bandbreite in der Mitte einer großen Übertragung einschränkt, nicht der Anfang, aber es ist immer das erste Paket des RPC-Aufrufs ... ein zäher. - Ryan


Ich habe das gleiche Problem mit ESXi4.1U1 und CentOS VMs. Die Hosts sind Dell R610, Storage ist ein EMC2 Isilon-Cluster.

Haben Sie zufällig VLANs benutzt? Ich habe festgestellt, dass die Verwendung eines VLANs auf dem VMkernel-Port für den Speicher die 4000-5000ms "Hänge" für den gesamten Speicherverkehr auf dem VMHost verursachte. Wenn ich jedoch den VMkernel-Port aus dem VLAN verschiebe, sodass er nicht markierte Pakete empfängt, sehe ich das Problem nicht.

Die folgende einfache Einrichtung führt zu dem Problem in meinem Netzwerk:

1) Installieren Sie ESXi 4.1U1 auf einem Server oder einer Workstation (beide zeigten das Problem, als ich es versuchte)

2) Fügen Sie einen VMkernel-Port in einem VLAN hinzu.

3) Fügen Sie einen NFS-Datenspeicher hinzu (meine befindet sich im selben VLAN, d. H. Die Isilon empfängt markierte Pakete)

4) Installieren Sie 2 CentOS 5.5 VMs, eines mit Ioping.

5) Starten von VMs in den Einzelbenutzermodus (d. H. Kein Netzwerk, Mindestdienste)

6) Führen Sie Ioping auf einer Maschine aus, damit diese auf ihre virtuelle Festplatte schreibt

7) Führen Sie dd oder so etwas auf dem anderen Rechner aus, um 100 MB Daten nach / tmp oder ähnlichem zu schreiben

Meistens sehe ich beide VMs 4-5 Sekunden lang frieren.

Seid wirklich interessiert zu sehen, ob jemand anderes Ähnliches gesehen hat.


2
2017-12-17 12:38



Willkommen bei Serverfehler! Das ist eine alte Frage. Wenn Ihnen die Antworten nicht direkt helfen, sollten Sie eine neue Frage stellen, indem Sie auf die Schaltfläche klicken Frage stellen Taste. - Iain
Ja, natürlich verwende ich markierte VLANs. Da ich sie überall benutze, dachte ich nicht einmal an sie als potentielle Quelle dieses Problems. Ich werde versuchen, dies auf einem unmarkierten Port zu reproduzieren. - exo_cw
Ich kann dieses Problem auch auf einem unmarkierten Port reproduzieren, keine VLANs auf diesem Host überhaupt. - exo_cw
Ich habe es nur noch einmal versucht und sehe das Problem auch auf dem unmarkierten Port, es ist ein bisschen weniger häufig, vielleicht habe ich es deshalb verpasst. Entschuldigung für den Penner. Ich kann das Problem auf Win7 64 Bit nicht mit dem iometer sehen, und es scheint, ich kann das c: Laufwerk durchsuchen, während die anderen Linux-Vms hängen. Ich werde es mit Crystaldiskmark versuchen - Nick
Eigentlich wäre ich interessiert, Ihre Ergebnisse mit iometer auf win7 x64 zu sehen. Es misst die Latenz, aber die höchste Gesamtanzahl, die ich erhielt, war 300 ms unter Verwendung des 4k-Lesetests, nicht 4000 + ms - Nick


Wir hatten genau das gleiche Problem vor zwei Wochen. ESX41 U1 und Netapp FAS3170 + NFS-Datenspeicher. RHEL5 VMs hängen für 2 oder 4 Sekunden und wir haben sehr hohe Spitzen von der Virtual Center-Leistungskonsole gesehen.

Ich frage den Netzwerk-Typ, um die Konfiguration zu überprüfen, und das Problem war auf dem Cisco-Switch. Wir haben zwei Ethernet-Links, die auf EtherChannel auf der NetApp-Seite und nicht auf der Cisco-Seite konfiguriert wurde. Er erstellt einen statischen Ethernet-Kanal auf der Cisco und jetzt funktioniert es gut. Um diese Art von Problem zu identifizieren, fahren Sie den gesamten Port bis auf einen zwischen dem Filer und dem Switch herunter. Lassen Sie nur einen Hafen am Leben und sehen Sie, wie die Dinge laufen.

Die zweite Sache, die wir tun, war, die Flusskontrolle auf dem switcj und dem Filer zu entfernen, weil wir vermuten, dass es einen Pausenrahmen sendet.


2
2018-01-09 22:48





Wie sieht dein DNS aus? Ist dein /etc/resolv.conf richtig? Das Standard-Timeout beträgt 5 Sekunden.

Von man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Versuchen Sie, anzuhängen timeout:3 zu deinem /etc/resolv.conf und führen Sie dann Ihre fsync-Tests erneut aus.


1
2017-07-06 15:30



Ich habe versucht, dies auf dem NFS-Server (in diesem Fall OpenIndiana) und auf dem ESXi-Host hinzuzufügen. Leider macht das keinen Unterschied. Ich kann den Server und die Gast-IP gut lösen. - exo_cw
Sieht so aus, als hättest du den gesamten Traffic gefiltert, der nicht mit dem nfs-Stream zusammenhängt. Wir müssen vielleicht mehr sehen! - tony roth
@tony roth: Das ist eigentlich der ganze Verkehr zu dieser Zeit. Ich habe das auf einem separaten vSwitch mit nur dem Host und dem NFS-Server getestet. - exo_cw
Können Sie DNS mit wireshark dump? - Joseph Kern
@Joseph Kern: Ich habe gerade die Capture-Dateien erneut analysiert: Es gab überhaupt keinen DNS-Verkehr während meiner Captures. Der NFS-Datenspeicher wird über IP auf dem ESXi-Host zugeordnet. DNS funktioniert gut auf dem ESXi und dem NFS-Server. Ich habe das Vorwärts- und Rückwärtssuchen aller beteiligten IPs getestet. Im Moment habe ich keinen Grund zu glauben, dass DNS die Ursache dafür ist. - exo_cw


Hier nach Strohhalmen greifen, aber welche NICs benutzen Sie in diesen Servern? Die Stack Overflow-Systemadministratoren hatten seltsame Netzwerkprobleme mit Broadcom-Netzwerkkarten, die beim Wechsel zu Intel-Netzwerkkarten verloren gingen: http://blog.serverfault.com/post/broadcom-die-mutha/ 


1
2017-07-08 17:00



Die letzten Tests wurden nur auf einem vSwitch durchgeführt, ohne dass ein physisches Netzwerk involviert war (e1000 und vmxnet3: machten keinen Unterschied). Aber ich habe auch dies auf Intel 82574L, Intel 82576 und Intel 82567LF-3 getestet, die alle das Problem zeigen. Ich habe noch keine Hardware gefunden, die ich nicht reproduzieren kann. - exo_cw


Hier ist eine weitere Vermutung ... Ist Ihr IPv6 auf dem EXS Host aktiviert? Wenn ja, dann schalte es aus? Aus meiner Erfahrung, wenn Ihr gesamtes Netzwerk nicht ordnungsgemäß für IPv6 (d. H. RADV, DHCP6, DNS, Reverse-DNS) konfiguriert ist, kann es für einige Dienste ein Problem sein. Stellen Sie außerdem sicher, dass es auf dem NFS-Server deaktiviert ist.


1
2017-07-12 02:04



IPv6 war bereits auf dem ESXi-Host deaktiviert. Ich habe IPv6 auf dem NFS-Server deaktiviert (ifconfig -a6 ist jetzt leer), aber es macht keinen Unterschied: Es zeigt die gleichen Probleme. - exo_cw