VMXNET3 reçoit le dimensionnement du tampon et l'utilisation de la mémoire


12

Contexte

Nous avons eu un incident lors duquel un cluster de basculement Windows a subi une interruption. Une autopsie a montré que le nœud avait été "supprimé" comme décrit dans cet article .

Nous avons récemment récemment entièrement migré ce cluster dans notre environnement VMware, et il semble que l'événement décrit ci-dessus ait pu être la cause de la panne.

L'article VMware KB associé à ce sujet parle d'augmentation de Small Rx Bufferset du Rx Ring #1paramètre, mais prévient qu'une augmentation excessive de ces paramètres pourrait considérablement augmenter la surcharge de mémoire sur l'hôte.

Après un audit des Network Interface\Packets Received Discardedcompteurs de performance pour nos ~ 150 machines virtuelles Windows, 22 vNIC sur 16 invités ont eu des paquets rejetés.

Une quantité suffisamment petite pour que je ne m'inquiète pas de taxer les hôtes avec une utilisation supplémentaire de la mémoire, mais je veux comprendre comment la mémoire est utilisée pour ces paramètres et d'où vient la mémoire.

Des questions

  1. Quelle est la relation entre le nombre de tampons et la taille de l'anneau?
  2. Comment calcule-t-on la quantité de mémoire utilisée pour des valeurs données de ces paramètres?
  3. Étant donné que ces paramètres se trouvent sur la carte réseau elle-même dans le système d'exploitation invité, je suppose que ce sont des paramètres de pilote. Cela me fait penser que la RAM utilisée peut être un pool paginé ou non paginé.
    1. Est-ce correct?
    2. Si oui, devrais-je m'en inquiéter?
  4. Y a-t-il des préoccupations que je ne prends pas en compte ici?

Nous essayons de déterminer s'il existe un inconvénient à les définir à leur maximum sur les machines virtuelles affectées, autres que l'utilisation de la mémoire hôte VMware. Si nous augmentons le risque d'épuisement de la mémoire du pool chez l'invité par exemple, nous sommes plus enclins à commencer petit.

Certaines (peut-être toutes) de ces questions peuvent ne pas être spécifiques à VMware ou à la virtualisation.


J'ai vu des choses vraiment floconneuses lorsque le moteur de déchargement TCP de la carte réseau physique se comportait mal et que les machines virtuelles affichaient un comportement étrange, peut-être une piste que vous pouvez suivre.
SpacemanSpiff

@SpacemanSpiff, cela vaut la peine d'être vérifié, mais seulement 16 machines virtuelles sur 150+ présentent le comportement. Ces 16 sont répartis sur le cluster à 12 nœuds, et ils reçoivent tous occasionnellement des rafales élevées de trafic, ce qui semble être à l'origine des symptômes décrits dans l'article de la Base de connaissances. Certains d'entre eux sont des clusters Windows, ils ne se déplacent donc pas avec DRS, sinon je pourrais vérifier si tous les invités concernés ont montré des paquets perdus sur un hôte spécifique avant d'être désactivés. Je vais vérifier à nouveau et voir si je peux trouver des corrélations. Merci.
briantist

Microbursting peut-être, de quel matériel s'agit-il?
SpacemanSpiff

@SpacemanSpiff Serveurs IBM, quelques modèles et révisions différents, je ne sais pas non plus quelles cartes réseau, je peux vérifier les détails demain.
briantist

Réponses:


5

Quelle est la relation entre le nombre de tampons et la taille de l'anneau?

Ils sont liés, mais indépendants. Le «anneau» rx fait référence à un ensemble de tampons en mémoire qui sont utilisés comme file d'attente pour transmettre les paquets réseau entrants de l'hôte (hyperviseur) à l'invité (machine virtuelle Windows). La mémoire est réservée dans l'invité par le pilote réseau et elle est mappée dans la mémoire hôte.

À mesure que de nouveaux paquets réseau arrivent sur l'hôte, ils sont placés sur le prochain tampon disponible dans l'anneau. Ensuite, l'hôte déclenche une IRQ dans l'invité, à laquelle le pilote invité répond en retirant le paquet de l'anneau et en le distribuant à la pile réseau de l'OS invité, qui l'envoie vraisemblablement à l'application invitée en prétendant le recevoir. En supposant que les paquets arrivent assez lentement et que le pilote invité les traite assez rapidement, il devrait toujours y avoir un emplacement libre dans l'anneau. Cependant, si les paquets arrivent trop rapidement ou si l'invité les traite trop lentement, l'anneau peut devenir plein et les paquets peuvent être abandonnés (comme vous l'avez vu dans votre situation).

L'augmentation de la taille de la bague peut aider à atténuer ce problème. Si vous l'augmentez, plus de slots seront disponibles dans le ring à la fois. Cela se poursuit dans le deuxième paramètre, "Small Rx Buffers", qui est la quantité totale de tampons disponibles qui peuvent être utilisés pour remplir les emplacements de l'anneau. Il doit y avoir au moins autant de tampons que d'emplacements dans l'anneau. En général, vous en voulez plus. Lorsque l'invité enlève un tampon de l'anneau pour le donner à la pile du réseau invité, il ne peut pas toujours être immédiatement renvoyé au pilote. Si cela se produit, avoir des tampons de rechange pour remplir l'anneau signifie que vous pouvez continuer plus longtemps sans perdre de paquets.

Les tampons Rx Ring # 1 / Small Rx sont utilisés pour les trames non jumbo. Si vous avez une configuration NIC par défaut, c'est le seul anneau qui sera utilisé.

Comment calcule-t-on la quantité de mémoire utilisée pour des valeurs données de ces paramètres?

En supposant que vous parlez de trames non jumbo, chaque tampon doit être suffisamment grand pour stocker un paquet réseau entier, environ 1,5 Ko. Donc, si vous avez 8192 tampons disponibles, cela utiliserait 12 Mo. Un anneau plus grand utilisera également plus de mémoire, mais les descripteurs sont petits (octets), c'est donc vraiment les tampons dont vous devez vous soucier.

Étant donné que ces paramètres se trouvent sur la carte réseau elle-même dans le système d'exploitation invité, je suppose que ce sont des paramètres de pilote. Cela me fait penser que la RAM utilisée peut être un pool paginé ou non paginé.

Oui, c'est une piscine non paginée. Si les tampons en anneau étaient paginés, cela entraînerait probablement la perte de paquets pendant que les tampons étaient renvoyés.

Y a-t-il des préoccupations que je ne prends pas en compte ici?

Je ne suis pas sûr que cela soit pertinent pour votre situation, mais il convient de noter qu'un anneau plus grand augmentera l'encombrement du cache du chemin de réception réseau. Dans les microbenchmarks, vous verrez qu'un anneau plus grand nuit généralement aux performances. Cela dit, dans les applications réelles, si un paquet est abandonné, c'est généralement plus important qu'un petit gain de performances en rafales de vitesse.

Source: J'ai travaillé chez VMware.


1
Merci Roger, excellente première réponse. Je n'ai pas été dans cette entreprise depuis un certain temps, donc ce problème est loin de mon radar, mais pour être complet, y a-t-il un problème d'utilisation de la mémoire pour les régler à leur maximum? L'article de la base de connaissances donne l'impression que vous pourriez utiliser beaucoup de mémoire de cette façon, mais il semble que la quantité soit assez petite. Je pose cette question car il est également difficile de savoir comment dimensionner ces valeurs autres que les essais et les erreurs, il peut donc être plus facile de les définir au maximum s'il n'y a pas / peu d'inconvénients.
briantist

1
Re: utilisation de la mémoire, deux choses que je noterais: 1) Si vous n'utilisez pas de trames jumbo, je suis d'accord, la quantité de mémoire au réglage maximum est encore assez petite. Si vous utilisez des trames jumbo, la taille de la mémoire tampon est d'environ 9 Ko et vous utilisez donc plus de mémoire. 2) La quantité de mémoire disponible dans un pool non paginé est inférieure à la quantité totale de mémoire sur l'hôte. Je ne suis pas un expert ici mais ce lien a un aperçu assez complet sur la façon de calculer la mémoire disponible: blogs.technet.microsoft.com/markrussinovich/2009/03/10/…
Roger Jacobson

Super merci. J'espère que cette réponse aidera quelqu'un à l'avenir (ce sera peut-être même moi si je retrouve ça!)
briantist

0

Je n'ai pas de réponse pour le point 1-2-3 mais vous pouvez vérifier auprès de votre ingénieur virtuel la configuration de l'hôte Vmware. S'il est VCP, il comprendra les choses :)

Vous devez vraiment vérifier votre hôte car les problèmes Windows peuvent être sur l'hôte et non sur l'invité.

Il existe de nombreuses fonctionnalités matérielles qui pourraient expliquer vos problèmes, directpath io, rss, vcpu, schéma de gestion de l'alimentation ...

Je peux vous donner un lien qui aide votre équipe virtuelle, ou vous :)

Ce lien concerne le réglage de l'hôte http://buildvirtual.net/tuning-esxi-host-networking-configuration/

Et ce gros pdf:

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Et celui-ci concerne rss:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008925


Merci pour la réponse, mais je suis un VCP. Ce n'est pas du tout une configuration d'hôte. L'article de Microsoft auquel j'ai lié explique que le compteur de performances en question ne doit pas être supérieur à 0 et qu'il se trouve sur plusieurs machines virtuelles. J'essaie de comprendre les paramètres vNIC au-delà de ce qui est expliqué dans l'article VMware KB.
briantist

-1

Je ne suis pas en mesure de faire une recherche complète et de vous orienter vers les bonnes pages: je vous demande donc de rechercher vous-même les détails ... (désolé)

Dans Fail over Cluster, il y a 4 paramètres qui peuvent être modifiés; et ils n'affecteront pas les tampons ou paginés ou non paginés ... Cela change la façon dont le basculement de cluster prend la décision de considérer un nœud "supprimé". Ces paramètres sont les suivants:

SameSubnetDelay SameSubnetThreshold CrossSubnetDelay CrossSubnetThreshold

Ils ne résoudront peut-être pas votre problème, mais les régler peut vous éviter des ennuis pour le moment ...

De retour lundi, je reviendrai sur cet article si vous avez d'autres questions

HTH, Edwin.


PS: pouvez-vous nous indiquer la version de Windows que vous utilisez?
Edwin van Mierlo

C'était Windows 2008. J'ai obtenu une réponse de VMware (après tous ces mois), mais je ne suis même pas dans l'entreprise où j'étais quand cela s'est produit. La réponse n'est pas simple et j'ai voulu lire leur réponse et poster quelque chose, mais je n'ai pas eu le temps. J'apprécie vos conseils sur le cluster, mais je ne peux pas les essayer pour le moment.
briantist du

Je remarque seulement que le message d'origine date de quelques mois, ce n'était pas très clair dans l'application android ... J'y regarderai de plus près la prochaine fois ... en attendant, ma réponse est toujours valable pour les autres utilisateurs qui peuvent rechercher pour des expériences similaires.
Edwin van Mierlo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.