Vraag Problemen met latentiepieken op ESXi NFS-gegevensarchieven oplossen


Ik ervaar fsync latencies van ongeveer vijf seconden op NFS-datastores in ESXi, geactiveerd door bepaalde VM's. Ik vermoed dat dit wordt veroorzaakt door VM's die NCQ / TCQ gebruiken, omdat dit niet gebeurt met virtuele IDE-schijven.

Dit kan worden gereproduceerd met behulp van fsync-tester (door Ted Ts'o) en ioping. Bijvoorbeeld met behulp van een Grml live-systeem met een schijf van 8 GB:

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 ...]

Dat is 5 seconden, geen milliseconden. Dit is zelfs het maken van IO-latenties op een andere VM die op dezelfde host en datastore draait:

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

Wanneer ik de eerste VM naar lokale opslagruimte verplaats, ziet het er volkomen normaal uit:

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 ...]

Dingen die ik heb geprobeerd die geen verschil maakten:

  • Getest verschillende ESXi Builds: 381591, 348481, 260247
  • Getest op verschillende hardware, verschillende Intel- en AMD-boxen
  • Getest met verschillende NFS-servers, vertonen allemaal hetzelfde gedrag:
    • OpenIndiana b147 (ZFS sync altijd of uitgeschakeld: geen verschil)
    • OpenIndiana b148 (ZFS-synchronisatie altijd of uitgeschakeld: geen verschil)
    • Linux 2.6.32 (sync of async: geen verschil)
    • Het maakt geen verschil of de NFS-server zich op dezelfde machine (als een virtueel opslagapparaat) of op een andere host bevindt

Gast-OS getest, met problemen:

  • Windows 7 64 Bit (met behulp van CrystalDiskMark treden latentiepieken meestal op tijdens de voorbereidingsfase)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Ik kon dit probleem niet reproduceren op Linux 2.6.18 VM's.

Een andere oplossing is om virtuele IDE-schijven (vs SCSI / SAS) te gebruiken, maar dat is de prestaties en het aantal schijven per VM beperken.

Update 2011-06-30:

De latency-spikes lijken vaker te gebeuren als de toepassing in meerdere kleine blokken vóór fsync schrijft. Fsync-tester doet dit bijvoorbeeld (strace-uitvoer):

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

ioping doet dit tijdens het voorbereiden van het bestand:

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

De opstartfase van ioping hangt bijna altijd, terwijl fsync-tester soms goed werkt. Is iemand in staat om fsync-tester bij te werken om meerdere kleine blokken te schrijven? Mijn C-vaardigheden zuigen;)

Update 2011-07-02:

Dit probleem doet zich niet voor met iSCSI. Ik probeerde dit met de OpenIndiana COMSTAR iSCSI-server. Maar iSCSI geeft je geen gemakkelijke toegang tot de VMDK-bestanden, zodat je ze kunt verplaatsen tussen hosts met snapshots en rsync.

Update 2011-07-06:

Dit maakt deel uit van een wireshark-opname, vastgelegd door een derde VM op dezelfde vSwitch. Dit gebeurt allemaal op dezelfde host, er is geen fysiek netwerk bij betrokken.

Ik ben rond 20. begonnen met ioping. Er waren geen pakketten verzonden totdat de vertraging van vijf seconden voorbij was:

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

2e update 2011-07-06:

Er lijkt enige invloed te zijn van TCP-vensterformaten. Ik kon dit probleem niet reproduceren met FreeNAS (op basis van FreeBSD) als een NFS-server. De wireshark-opnames toonden TCP-vensterupdates met regelmatige tussenpozen van 29127 bytes. Ik heb ze niet gezien met OpenIndiana, die standaard grotere venstergroottes gebruikt.

Ik kan dit probleem niet meer reproduceren als ik de volgende opties in OpenIndiana installeer en de NFS-server opnieuw start:

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

Maar dit scheelt prestaties: het schrijven van / dev / zero naar een bestand met dd_rescue gaat van 170MB / s tot 80MB / s.

Update 2011-07-07:

Ik heb dit geüpload tcpdump capture (kan worden geanalyseerd met wireshark). In dit geval 192.168.250.2 is de NFS-server (OpenIndiana b148) en 192.168.250.10 is de ESXi-host.

Dingen die ik heb getest tijdens deze opname:

Gestart "ioping -w 5 -i 0.2." op het moment 30, 5 seconden in setup hangen, voltooid op tijdstip 40.

Gestart "ioping -w 5 -i 0.2." op tijd 60, 5 seconden hangen in setup, voltooid op tijdstip 70.

Gestart met "fsync-tester" op tijdstip 90, met de volgende uitvoer, gestopt op tijdstip 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

2e update 2011-07-07:

Een andere NFS-server VM getest, dit keer NexentaStor 3.0.5-communityeditie: toont dezelfde problemen.

Update 2011-07-31:

Ik kan dit probleem ook reproduceren op de nieuwe ESXi build 4.1.0.433742.


44
2018-06-29 08:33


oorsprong


Ik moet zeggen dat het een tijdje geleden is dat een gloednieuwe gebruiker naar het bord is gekomen met zo'n goed gedocumenteerde en doordachte vraag - serieus, petje af voor jou. Het is ook echt interessant, ik ben fsync-tester nog niet tegengekomen, dus bedankt. Dat gezegd hebbende, ik weet niet zeker of ik iets toe te voegen heb, je hebt zoveel van de dingen geprobeerd die ik al zou hebben - ik zou zeggen tegen VMWare zelf te praten om eerlijk te zijn, ze zijn erg goed in het nemen van dit soort van 'long-tail' / 'geen echte service-uitval' spul serieus. In elk geval wilde ik gewoon zeggen: goed gedaan over wat je tot nu toe hebt gedaan :) - Chopper3
Helaas zal de VMware-website me niet toestaan ​​contact met hen op te nemen: "U hebt momenteel geen actieve ondersteuningsrechten" - exo_cw
ah, ja, dat kan natuurlijk een probleem zijn ... - Chopper3
5 seconden time-out met NFS klonk bekend. In linux NFS is er een .7 tweede time-out voor RPC die verdubbelt na elke fout en trekt een majeur na 3 mislukkingen (standaardinstellingen). .7 + 1.4 + 2.8 = 4.9 seconden. Er is een breed scala aan RPC-authenticatieproblemen die dit kunnen veroorzaken. - Mark
@Ryan: ik heb het capture-bestand geüpload. Ik heb ook het nfsstat-uitvoer. - exo_cw


antwoorden:


Dit probleem lijkt te worden opgelost in ESXi 5. Ik heb build 469512 met succes getest.


5
2017-09-13 06:54





Bedankt, nfsstat ziet er goed uit. Ik heb de opname bekeken. Ik heb niets overtuigend gevonden, maar vond wel iets interessants. Ik heb gefilterd op tcp.time_delta> 5. Wat ik heb gevonden elk delay instance was de exacte start van een RPC-aanroep. Niet alle nieuwe RPC-aanroepen waren traag, maar alle vertragingen deden zich voor aan het exacte begin van een RPC-aanroep. Ook blijkt uit de opname dat 192.168.250.10 alle vertraging bevat. 192.168.250.2 reageert onmiddellijk op alle verzoeken.

bevindingen:

  • Vertragingen treden altijd op in het eerste pakket van een RPC-oproep
  • NFS-opdrachttypen waren niet gecorreleerd aan vertragingsinstanties
  • Fragmentatie = vertraagt ​​alleen eerste pakket

Een grote Write-oproep kan in 300 individuele TCP-pakketten worden onderbroken en alleen de eerste wordt vertraagd, maar de rest vliegt door. Nooit gebeurt de vertraging in het midden. Ik weet niet zeker hoe de venstergrootte het effect kan hebben begin van de verbinding zo drastisch.

Volgende stappen: Ik zou de NFS-opties zoals NFSSVC_MAXBLKSIZE naar beneden aanpassen in plaats van het TCP-venster. Ook merkte ik dat 2.6.18 werkt terwijl 2.6.38 dat niet doet. Ik weet dat in die periode ondersteuning voor de VMXnet3-driver is toegevoegd. Welke NIC-stuurprogramma's gebruikt u op de hosts? TCP offloading ja / nee? Rond het 95 seconden-teken zijn er meer dan 500 TCP-pakketten voor een enkele NFS Write-oproep. Wat de leiding heeft over TCP en het verbreken van de grote PDU kan zijn wat blokkeert.


3
2017-07-08 23:26



Ik probeerde het instellen van nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots en nfs: nfs3_bsize allemaal tot 8192: geen verschil, dezelfde problemen. De Linux-gasten gebruiken gewoon hun SCSI / SAS-schijven, geen NFS - de ESXi is de NFS-client, dus geen probleem met het netwerkstuurprogramma op de linux-gast. Aan de NFS-server heb ik zowel virtuele e1000 als vmxnet3 geprobeerd: maakte geen verschil. Voor zover ik weet, gebruikt ESXi alleen TCP offloading voor iSCSI. - exo_cw
De grootste ? Ik heb is waarom het aanpassen van het TCP-venster een verschil zou maken ... Mijn gevoel zegt me dat het iets te maken heeft met het fragmenteren van die grote PDU's via TCP. Iets in de netwerkstack die zich ertussen verstikt. Kan gewoon niets bedenken dat past bij het gedrag dat we zien. Als de venstergrootte een probleem was, zouden we latentie beperkende bandbreedte moeten zien in het midden van een grote overdracht, niet het begin, maar het is altijd het eerste pakket van de RPC-oproep ... moeilijk. - Ryan


Ik heb wat hetzelfde probleem lijkt met ESXi4.1U1 en CentOS VM's. De hosts zijn Dell R610's, opslag is een EMC2 Isilon-cluster.

Was je toevallig bij het gebruik van VLANS? Ik vond het gebruik van een VLAN op de VMkernel-poort voor opslag veroorzaakt dat de 4000-5000 ms 'hangt' voor al het opslagverkeer op de VMHost. Maar als ik de VMkernel-poort van de VLAN verwijder zodat deze niet-gecodeerde pakketten ontvangt, zie ik het probleem niet.

De eenvoudige installatie hieronder zal het probleem op mijn netwerk veroorzaken:

1) Installeer ESXi 4.1U1 op een server of werkstation (beide hebben het probleem getoond toen ik het probeerde)

2) Voeg een VMkernel-poort toe aan een VLAN.

3) Voeg een NFS Datastore toe (de mijne is op dezelfde VLAN, d.w.z. de Isilon ontvangt getagde pakketten)

4) Installeer 2 CentOS 5.5 VM's, een met ioping.

5) Start de VM's in de modus voor één gebruiker (d.w.z. geen netwerk, minimale services)

6) Voer ioping uit op één machine, dus het schrijft naar zijn virtuele schijf

7) Voer dd of iets dergelijks uit om 100 MB gegevens te schrijven naar / tmp of iets dergelijks

Vaker wel dan niet zie ik beide VM's gedurende 4-5 seconden bevriezen.

Wees echt geïnteresseerd om te zien of iemand anders hetzelfde heeft gezien.


2
2017-12-17 12:38



Welkom bij Server Fault! Dit is een oude vraag. Als de antwoorden u niet direct helpen, moet u een nieuwe NIEUWE vraag stellen door op de. Te klikken Stel vraag knop. - Iain
Ja, natuurlijk gebruik ik getagde VLAN's. Omdat ik ze overal gebruik, zag ik ze zelfs niet als een mogelijke oorzaak van dit probleem. Ik ga proberen dit te reproduceren op een niet-gecodeerde poort. - exo_cw
Ik kan dit probleem ook op een niet-gecodeerde poort reproduceren, helemaal geen VLAN's op die host. - exo_cw
Ik probeerde het gewoon opnieuw en zag het probleem ook op de niet-gecodeerde poort, het is iets minder vaak, misschien daarom heb ik het gemist. Sorry voor de bum-steer. Ik kan het probleem niet zien op Win7 64 bit met behulp van iometer, en het lijkt erop dat ik de c: drive kan doorbladeren terwijl de andere linux vms zijn opgehangen. Ik ga het proberen met crystaldiskmark - Nick
Ik zou eigenlijk graag uw resultaten zien met iometer op win7 x64. Het meet latentie, maar het hoogste algemene cijfer dat ik kreeg was 300 ms met behulp van de 4k-leestest, niet 4000 + ms - Nick


We hadden precies hetzelfde probleem twee weken geleden. ESX41 U1 en Netapp FAS3170 + NFS Datastores. RHEL5 VM's hangen 2 of 4 seconden en we zagen heel hoge spikes van de Virtual Center-uitvoeringsconsole.

Ik vraag de netwerkkerel om de configuratie te controleren en het probleem was op de cisco-switch. We hebben twee ethernet-links die op Etherchannel aan de Netapp-kant en niet aan de cisco-kant waren geconfigureerd. Hij maakt een statisch Ethechannel op de cisco en nu werkt het prima. Om dit soort problemen te identificeren, sluit u alle poorten behalve één tussen de filer en de switch. Laat slechts één poort in leven en zie hoe de dingen gaan.

Het tweede dat we doen was het verwijderen van de Flow Control op de switcj en de filer omdat we verwachten dat het een pauze-frame verzendt.


2
2018-01-09 22:48





Hoe ziet uw DNS eruit? Is jouw /etc/resolv.conf correct? De standaardtime-out is 5 seconden.

Van 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>).

Probeer toe te voegen timeout:3 aan jouw /etc/resolv.conf en voer je fsync-tests opnieuw uit.


1
2017-07-06 15:30



Ik heb geprobeerd dit toe te voegen aan de NFS-server (in dit geval OpenIndiana) en aan de ESXi-host. Helaas maakt dit geen verschil. Ik kan het server & guest IP prima oplossen. - exo_cw
het lijkt erop dat je al het verkeer hebt gefilterd dat niet gerelateerd is aan de nfs-stream, we moeten misschien meer zien! - tony roth
@tony roth: Eigenlijk is dat het hele verkeer op dat moment. Ik testte dat op een afzonderlijke vSwitch met alleen de host en de NFS-server erop. - exo_cw
Kun je DNS met wireshark dumpen? - Joseph Kern
@ Joseph Kern: Ik heb net de capture-bestanden opnieuw geanalyseerd: er was helemaal geen DNS-verkeer tijdens mijn opnames. De NFS-datastore wordt toegewezen door IP op de ESXi-host. DNS werkt prima op de ESXi en de NFS-server, ik heb de forward & reverse lookup van alle betrokken IP's getest. Op dit moment heb ik geen reden om aan te nemen dat DNS hier de oorzaak van is. - exo_cw


Grijp hier naar rietjes, maar welke NIC's gebruikt u op deze servers? De Stack Overflow-sysadmins hebben rare netwerkproblemen met Broadcom NIC's die zijn verdwenen toen ze overschakelden op Intel NIC's: http://blog.serverfault.com/post/broadcom-die-mutha/ 


1
2017-07-08 17:00



De laatste tests werden alleen uitgevoerd op een vSwitch, er was geen fysiek netwerk bij betrokken (e1000 en vmxnet3: maakten geen verschil). Maar ik heb dit ook getest op Intel 82574L, Intel 82576 en Intel 82567LF-3, die allemaal het probleem laten zien. Ik heb nog geen hardware gevonden waar ik dit niet kan reproduceren. - exo_cw


Hier is nog een gok ... Is uw IPv6 ingeschakeld op de EXS-host? Zo ja, probeer dan het uit te zetten? Uit mijn ervaring dat uw volledige netwerk niet juist is geconfigureerd voor IPv6 (zoals RADV, DHCP6, DNS, reverse DNS), kan het voor sommige services een probleem zijn. Zorg er ook voor dat het uitgeschakeld is op de NFS-server.


1
2017-07-12 02:04



IPv6 was al uitgeschakeld op de ESXi-host. Ik heb IPv6 op de NFS-server uitgeschakeld (ifconfig -a6 is nu leeg), maar het maakt geen verschil: het laat dezelfde problemen zien. - exo_cw