Je rencontre des latences fsync d'environ cinq secondes sur les datastores NFS dans ESXi, déclenchées par certaines machines virtuelles. Je soupçonne que cela pourrait être causé par des ordinateurs virtuels utilisant NCQ / TCQ, car cela ne se produit pas avec les lecteurs IDE virtuels.
Ceci peut être reproduit en utilisant fsync-tester (par Ted Ts'o) et ioping . Par exemple, en utilisant un système live Grml avec un disque de 8 Go:
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 ...]
C'est 5 secondes, pas millisecondes. Cela crée même des latences d'E / S sur une machine virtuelle différente s'exécutant sur le même hôte et le même magasin de données :
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
Lorsque je déplace la première machine virtuelle vers un stockage local, cela semble parfaitement normal:
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 ...]
Les choses que j'ai essayées ne font aucune différence:
- Testé plusieurs éditions ESXi: 381591, 348481, 260247
- Testé sur différents matériels, différents boîtiers Intel et AMD
- Testé avec différents serveurs NFS, tous présentent le même comportement:
- OpenIndiana b147 (synchronisation ZFS toujours ou désactivée: aucune différence)
- OpenIndiana b148 (synchronisation ZFS toujours ou désactivée: aucune différence)
- Linux 2.6.32 (sync ou async: pas de différence)
- Cela ne fait aucune différence si le serveur NFS est sur le même ordinateur (en tant que dispositif de stockage virtuel) ou sur un hôte différent
OS invité testé, présentant des problèmes:
- Windows 7 64 bits (avec CrystalDiskMark, les pointes de latence se produisent principalement pendant la phase de préparation)
- Linux 2.6.32 (testeur fsync + lecture)
- Linux 2.6.38 (testeur fsync + lecture)
Je ne pouvais pas reproduire ce problème sur les machines virtuelles Linux 2.6.18.
Une autre solution consiste à utiliser des disques IDE virtuels (vs SCSI / SAS), mais cela limite les performances et le nombre de lecteurs par machine virtuelle.
Mise à jour du 30/06/2011:
Les pointes de latence semblent se produire plus souvent si l'application écrit dans plusieurs petits blocs avant fsync. Par exemple, fsync-tester fait ceci (strace output):
pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3) = 0
ioping fait ceci pendant la préparation du fichier:
[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3) = 0
La phase d’installation de ioping est presque toujours suspendue, alors que fsync-tester fonctionne parfois très bien. Est-ce que quelqu'un est capable de mettre à jour fsync-tester pour écrire plusieurs petits blocs? Mes compétences C sucer;)
Mise à jour 2011-07-02:
Ce problème ne se produit pas avec iSCSI. J'ai essayé cela avec le serveur OpenIndiana COMSTAR iSCSI. Mais iSCSI ne vous donne pas un accès facile aux fichiers VMDK, vous pouvez donc les déplacer entre les hôtes avec des instantanés et rsync.
Mise à jour 2011-07-06:
Cela fait partie d'une capture wirehark, capturée par une troisième machine virtuelle sur le même vSwitch. Tout cela se passe sur le même hôte, aucun réseau physique impliqué.
J'ai commencé à lire vers 20 heures. Aucun paquet n'a été envoyé avant la fin du délai de cinq secondes:
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ème mise à jour 2011-07-06:
Il semble y avoir une certaine influence de la taille des fenêtres TCP. Je ne pouvais pas reproduire ce problème en utilisant FreeNAS (basé sur FreeBSD) en tant que serveur NFS. Les captures wirehark ont montré des mises à jour de la fenêtre TCP à 29127 octets à intervalles réguliers. Je ne les ai pas vus avec OpenIndiana, qui utilise par défaut des fenêtres plus grandes.
Je ne peux plus reproduire ce problème si je définis les options suivantes dans OpenIndiana et si je redémarre le serveur NFS:
ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576
Mais cela tue les performances: l’écriture de / dev / zero dans un fichier avec dd_rescue passe de 170 Mo / s à 80 Mo / s.
Mise à jour 2011-07-07:
J'ai téléchargé cette capture tcpdump (peut être analysée avec Wireshark). Dans ce cas, 192.168.250.2 est le serveur NFS (OpenIndiana b148) et 192.168.250.10 est l'hôte ESXi.
Choses que j'ai testées lors de cette capture:
A commencé "ioping -w 5 -i 0.2." à l’heure 30, l’installation dure 5 secondes et se termine à l’heure 40.
A commencé "ioping -w 5 -i 0.2." à l’heure 60, l’installation dure 5 secondes et se termine à l’heure 70.
Démarrage de "fsync-tester" à l’heure 90, avec la sortie suivante, arrêté à l’heure 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ème mise à jour 2011-07-07:
Tester une autre machine virtuelle de serveur NFS, cette fois-ci dans l’édition de la communauté NexentaStor 3.0.5: présente les mêmes problèmes.
Mise à jour du 31/07/2011:
Je peux également reproduire ce problème sur la nouvelle version d'ESXi 4.1.0.433742.
la source
Réponses:
Ce problème semble être résolu dans ESXi 5. J'ai testé la version 469512 avec succès.
la source
Merci, nfsstat a l'air bien. J'ai revu la capture. Je n'ai rien trouvé de concluant, mais j'ai trouvé quelque chose d'intéressant. J'ai filtré sur tcp.time_delta> 5. Ce que j'ai trouvé dans chaque instance de délai était le début exact d'un appel RPC. Tous les nouveaux appels RPC n'étaient pas lents, mais tous les ralentissements se sont produits exactement au début d'un appel RPC. En outre, il ressort de la capture que 192.168.250.10 contient tout le retard. 192.168.250.2 répond immédiatement à toutes les demandes.
Résultats:
Un appel d'écriture volumineux peut se décomposer en 300 paquets TCP individuels, et seul le premier est retardé, mais tous les autres survolent. Jamais le retard ne se produit au milieu. Je ne suis pas sûr que la taille de la fenêtre puisse affecter le début de la connexion de manière aussi radicale.
Prochaines étapes: je commencerais par peaufiner les options NFS telles que NFSSVC_MAXBLKSIZE plutôt que la fenêtre TCP. En outre, j'ai remarqué que 2.6.18 fonctionne alors que 2.6.38 ne fonctionne pas. Je sais que le pilote VMXnet3 a été pris en charge au cours de cette période. Quels pilotes de carte réseau utilisez-vous sur les hôtes? Déchargement TCP oui / non? Environ 95 secondes, il y a plus de 500 paquets TCP pour un seul appel d'écriture NFS. Ce qui est en charge de TCP et de la rupture de la grande PDU pourrait être ce qui bloque.
la source
J'ai le même problème avec les machines virtuelles ESXi4.1U1 et CentOS. Les hôtes sont des Dell R610, le stockage est un cluster EMC2 Isilon.
Avez-vous utilisé VLANS par hasard? J'ai constaté que l'utilisation d'un réseau local virtuel sur le port VMkernel pour le stockage provoquait le blocage de 4000 à 5000 ms pour tout le trafic de stockage sur le VMHost. Cependant, si je déplace le port VMkernel du VLAN pour qu'il reçoive les paquets non étiquetés, je ne vois pas le problème.
La configuration simple ci-dessous causera le problème sur mon réseau:
1) Installez ESXi 4.1U1 sur un serveur ou une station de travail (les deux ont présenté le problème lorsque j'ai essayé)
2) Ajoutez un port VMkernel sur un VLAN.
3) Ajouter un magasin de données NFS (le mien est sur le même réseau local virtuel, c’est-à-dire que l’Isilon reçoit les paquets étiquetés)
4) Installez 2 machines virtuelles CentOS 5.5, une avec ioping.
5) Démarrer les VM en mode mono-utilisateur (c'est-à-dire pas de réseau, services minimum)
6) Exécuter ioping sur une machine pour écrire sur son disque virtuel
7) Exécutez dd ou quelque chose sur l’autre machine pour écrire 100 Mo de données dans / tmp ou similaire
Le plus souvent, je constate le gel des deux ordinateurs virtuels pendant 4 à 5 secondes.
Soyez vraiment intéressé de voir si quelqu'un d'autre a vu la même chose.
la source
Nous avons eu exactement le même problème il y a deux semaines. ESX41 U1 et Netapp FAS3170 + Banques de données NFS. Les machines virtuelles RHEL5 s’arrêtent pendant 2 ou 4 secondes et nous avons constaté des pics très élevés à partir de la console de performance Virtual Center.
Je demande au responsable du réseau de vérifier la configuration et le problème se situe au niveau du commutateur Cisco. Nous avons deux liaisons Ethernet configurées sur Etherchannel du côté de Netapp et non du côté de Cisco. Il crée un Ethechannel statique sur le cisco et maintenant tout fonctionne bien. Pour identifier ce type de problème, fermez tous les ports sauf un entre le gestionnaire de fichiers et le commutateur. Laissez un seul port en vie et voyez comment les choses se passent.
La deuxième chose que nous avons faite était de supprimer le contrôle de flux sur le commutateur et le fichier car nous soupçonnons qu’il envoie une trame en pause.
la source
A quoi ressemble votre DNS? Est votre
/etc/resolv.confcorrect? Le délai d'attente par défaut est de 5 secondes.De
man resolv.confEssayez d’ajouter
timeout:3à/etc/resolv.confvotre fichier, puis exécutez à nouveau vos tests fsync.la source
Vous ne savez pas quoi, mais quelles cartes réseau utilisez-vous sur ces serveurs? Les administrateurs système de Stack Overflow ont eu d’excellents problèmes de réseau avec les cartes réseau Broadcom, qui ont disparu lorsqu’ils sont passés aux cartes réseau Intel: http://blog.serverfault.com/post/broadcom-die-mutha/
la source
Voici une autre hypothèse ... Votre IPv6 est-il activé sur un hôte EXS? Si oui, alors essayez de l'éteindre? D'après mon expérience, si tout votre réseau n'est pas correctement configuré pour IPv6 (c'est-à-dire RADV, DHCP6, DNS, DNS inversé), cela peut poser problème pour certains services. Assurez-vous également qu'il est désactivé sur le serveur NFS.
la source