"Nu mă, nu mă iei"
– Dan Mihai Balan
Comme le sait peut-être quiconque a déjà administré un système de fichiers Linux, la mise à niveau vers une nouvelle version du noyau Linux n'est généralement pas trop difficile, mais elle peut parfois avoir des impacts surprenants sur les performances. C'est l'histoire d'une de ces époques.
Qumulo logiciel de système de fichiers est livré avec une distribution Ubuntu assez standard. Nous mettons périodiquement à jour la distribution et le noyau Linux sous-jacent pour rester sur les versions prises en charge à long terme, afin que nous puissions continuer à nous tenir au courant des dernières mises à jour de sécurité et corrections de bogues, ainsi que de prendre en charge les nouveaux périphériques de stockage.
Nous avons récemment mis à jour toutes nos plates-formes pour utiliser Linux 5.4 - auparavant, certaines étaient sur 4.4 et d'autres sur 4.15. Pour la plupart, tout s'est bien passé. Mais lors des tests de performances avec le nouveau noyau, nous avons remarqué quelque chose d'étrange : le débit de nos systèmes Qumulo 4U Dual Intel CPU (connus de nos clients sous le nom de systèmes Qumulo QC104, QC208, QC260 et QC360) avait beaucoup baissé. Dans un test avec un grand nombre de flux d'écriture, le débit est passé d'environ 4.5 Go/s à environ 3.2 Go/s, soit une baisse de près de 30 % !
Ces systèmes utilisent un Haswell à double processeur. Beaucoup de nos clients ont des déploiements importants et actifs dont ils dépendent pour gérer leurs données - et nous travaillons constamment pour rendre nos plates-formes plus rapides au fil du temps, pas plus lentes !
Il était donc temps de creuser, de déterminer ce qui avait rendu notre logiciel plus lent et de le réparer.
Surveillance, dépannage et diagnostic des problèmes de performances Linux
Lors du diagnostic de tout type de problème de performances, nous commençons généralement par examiner les compteurs de performances, les mesures de latence et d'autres métriques générées par l'instrumentation au sein de notre système de fichiers. Les outils de surveillance des performances Linux tels que ceux-ci nous permettent de déterminer facilement où le système passe son temps et de diagnostiquer plus précisément la source du problème. Dans ce cas, les métriques racontaient une histoire claire : les E/S disque étaient normales, l'utilisation du processeur était normale, mais il y avait beaucoup plus de temps consacré à la mise en réseau.
Cela nous a incités à rechercher de plus près tout élément lié au réseau qui aurait pu changer de manière significative dans le cadre de la mise à niveau. Heureusement, nous avons été épargnés par la corvée de fouiller dans le code du noyau, car nous avons tout de suite trouvé un suspect principal : en plus de la mise à niveau vers Linux 5.4, nous avions changé les pilotes Ethernet. Auparavant, nous utilisions OFED pour les cartes réseau Mellanox, mais maintenant nous utilisions la version incluse avec le noyau.
Les détails du code du pilote se sont avérés sans importance non plus, car la véritable cause de la dégradation des performances était un petit changement de configuration : OFED inclut un script qui affine automatiquement les interruptions de réseau avec le processeur le plus proche, contrairement au pilote intégré. Réintroduire le script, ou simplement définir les affinités manuellement, a immédiatement ramené tout le débit.
Nous avons donc eu notre réponse, et avec un petit ajustement, nous avons pu envoyer en toute confiance la nouvelle distribution avec le noyau 5.4 à nos clients.
Dépannage d'un goulot d'étranglement des performances lié à NUMA
Nous ne nous contentons pas de simplement pouvoir résoudre les problèmes. Nous voulons comprendre leurs causes sous-jacentes. Et dans ce cas, quelque chose semblait étrange. Dans un système NUMA (système d'accès à la mémoire non uniforme), il est généralement préférable d'avoir des interruptions localement affinitées, mais aux niveaux de débit considérés (seulement quelques Go/s sur un nœud donné), cela n'avait pas de sens que la communication entre les processeurs pourraient être le goulot d'étranglement.
Le schéma ci-dessous montre une image simplifiée de l'architecture. Il dispose de deux processeurs Xeon E5-2620 v3, de 128 Go de RAM et de nombreux disques :
Notez les liens entre les deux CPU. Ce sont des canaux QuickPath Interconnect (QPI), qui sont utilisés chaque fois qu'un CPU a besoin de données qui ne sont disponibles que pour l'autre CPU - par exemple, si le CPU 1 doit traiter des données reçues du réseau, les données devront traverser QPI .
[type de boîte = "ombre"]Qu'est-ce que l'interconnexion QuickPath ?
QuickPath Interconnect est une connexion de données entre un processeur et d'autres ressources de la carte mère (telles qu'un concentrateur d'E/S ou d'autres processeurs) dans certaines microarchitectures Intel, introduite pour la première fois en 2008. Son objectif est de fournir une bande passante extrêmement élevée pour permettre une évolutivité élevée à bord - après tout, il ne sert à rien de mettre plus de processeurs sur une carte mère s'ils ne peuvent pas utiliser pleinement les ressources système. (Elle a été remplacée en 2017 par une nouvelle version, appelée UltraPath Interconnect, avec la sortie de la microarchitecture Skylake.)[/box]
Le E5-2620 v3 dispose de deux canaux d'interconnexion QuickPath 16 bits cadencé à 4 GHz. Chaque canal transfère des données sur les fronts d'horloge montant et descendant, ce qui entraîne 8 gigatransferts (GT) par seconde, ou 16 Go/s de bande passante dans les deux sens. Ainsi, avec deux d'entre eux, nous devrions approcher les 32 Go/s avant que ce lien ne devienne un goulot d'étranglement – plus que suffisant pour gérer les exigences relativement modestes de la carte réseau et des périphériques de stockage !
Cependant, il est clair que nous étions confrontés à un goulot d'étranglement, et il a disparu lorsque nous avons pris des mesures pour éviter la communication entre processeurs. Alors que se passait-il ?
Jetons un coup d'œil à ce qui doit se passer lorsqu'un nœud Qumulo traite une demande de lecture de données, par exemple en utilisant le protocole NFS. Le diagramme ci-dessous montre une version simplifiée du flux de données :
- Certaines données devront être récupérées à partir d'autres nœuds (la flèche bleue). Ces données arrivent sous la forme d'une série de segments TCP sur la carte réseau, qui sont ensuite déchargés via DMA vers des tampons en anneau dans le noyau, et de là vers le tampon de page interne du système de fichiers Qumulo.
- Certaines données seront récupérées à partir de ce nœud (flèche violette). Ceci est lu à partir du disque et copié dans le tampon de page.
- Une fois que les données locales et les données distantes ont été collectées, un agent de protocole les assemble en une réponse, qui est ensuite placée dans des tampons de transmission, à partir desquels elle sera envoyée par DMA à la carte réseau et envoyée via le réseau au client demandeur. .
Arriver au centre de l'oignon
Une idée clé ici est que chacune des flèches de l'organigramme ci-dessus (à l'exception de celles qui sortent de la carte réseau) représente un point où il serait possible pour les données de traverser le lien QPI, parfois plus d'une fois.
Par exemple, rappelez-vous du schéma d'architecture qu'il y a des périphériques de stockage connectés aux deux CPU. Si le processeur 0 lit 1 Go de données à partir d'un disque connecté au processeur 1, puis le copie dans une région de tampon de page mappée sur la mémoire connectée au processeur 1, ces données traverseront le lien deux fois. L'agent de protocole qui traite les données peut s'exécuter sur le processeur 0, nécessitant que les mêmes données croisent à nouveau le lien, et ainsi de suite.
Il y a donc un "effet d'amplification" en jeu - même si le nœud peut servir des données à seulement 2 Go/s, il pourrait y avoir plusieurs fois plus de trafic atteignant l'interconnexion QuickPath, en raison des mêmes données qui rebondissent, comme un jeu de tennis de données :
Identifier le véritable coupable du goulot d'étranglement des performances lié à NUMA
Mais attendez, je vous entends dire! Même dans les scénarios les plus pessimaux, cette amplification ne pourrait pas transformer 2 Go/s en 32 Go/s, il n'y a tout simplement pas assez de bords traversant la limite NUMA dans ce graphique !
C'est vrai – nous semblions faire face à un goulot d'étranglement bien en deçà de la vitesse nominale de la liaison. Heureusement, l'Intel Vérificateur de latence de la mémoire (également connu sous le nom d'Intel MLC) peut mesurer directement les performances réelles du système, nous l'avons donc exécuté et cela a confirmé nos soupçons :
Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Numa node
Numa node 0 1
0 46242.9 6291.7
1 6276.3 46268.6</var/www/wordpress>Le CPU 0 pouvait accéder à sa RAM directement connectée à ~ 46 Go/s, et la même chose pour le CPU 1 - mais au moment où l'un d'eux voulait accéder à la mémoire connectée à l'autre CPU, un maigre 6 Go/s était le mieux qu'ils pouvaient faire .
À ce stade, si vous connaissez très bien l'architecture Haswell d'Intel, vous savez peut-être déjà ce qui se passe. Nous n'étions pas spécialement, alors nous avons eu recours à la recherche des symptômes sur Google, et c'est ce qui nous a conduit à la bonne réponse, dans un Fil de la communauté Intel. Allez simplement dans le BIOS, changez le « mode espionnage » de « espionnage précoce » en « espionnage domestique » et le goulot d'étranglement disparaît !
Alors, qu'est-ce que c'est qu'un premier fouineur ? Malheureusement, l'espionnage précoce n'a rien à voir avec un beagle de dessin animé ou un certain rappeur américain prenant sa tasse de café du matin. Au lieu de cela, nous devrons parler de l'un des deux problèmes les plus difficiles de l'informatique : cohérence du cache. (Les deux autres nomment des choses et des erreurs une par une.) Les choses sont sur le point d'obtenir MESI. Plus précisément, le snooping fait partie du protocole MESI, et par extension de la variante MESIF utilisée par les processeurs Intel.
Le protocole de cohérence de cache MESI
MESI est un protocole commun pour imposer la cohérence du cache, c'est-à-dire que tous les différents caches du système ont une vue cohérente du contenu de la mémoire. MESI fonctionne en attribuant l'un des quatre états à chaque ligne de chaque cache, ce qui détermine comment cette ligne de cache peut être utilisée :
- Modifié: la ligne a été modifiée, et ne correspond plus à ce qui est dans la mémoire principale.
- Un bateau rien que pour "Vous": la ligne correspond à la mémoire principale, et n'est présente que dans ce cache.
- Owned: la ligne n'est pas modifiée, mais peut être présente dans d'autres caches.
- Invalide: la ligne est inutilisée ou a été invalidée (par exemple, par la modification d'une copie d'un autre cache).
MESI contre MESIF
MESIF est une extension de MESI qui a été développée par Intel. Il ajoute un cinquième état, F pour "en avant". Forward est similaire à Shared, mais un seul cache du système peut avoir une ligne à l'état Forward. Il s'agit principalement d'une optimisation pour éviter les réponses excessives lorsqu'une ligne de cache est demandée au système. Au lieu de chaque cache contenant une copie de la ligne répondant, seul le cache contenant la ligne à l'état F répondra.
Dans MESI et MESIF, les différents caches sont maintenus cohérents par des notifications sur le bus lorsque des changements importants se produisent - par exemple, si une ligne est écrite dans un cache, tout autre cache avec une copie doit avoir cette copie invalidée.
Early Snoop vs Home Snoop
La raison pour laquelle cette considération est critique pour les performances est liée à la disposition des caches dans l'architecture Haswell d'Intel. Le cache de dernier niveau (LLC) partagé sur chaque package est divisé en plusieurs tranches, une par cœur, connectées à un anneau sur matrice à très large bande passante. Chaque tranche de cache possède son propre « agent » de cache. Il existe également un « agent domestique » pour chaque contrôleur de mémoire :
En mode « early snoop » (illustré ci-dessus, avec deux processeurs), lorsqu'un événement de cache manquant ou de cohérence de cache se produit, l'agent de cache initiateur diffusera un message à tous les autres agents de cache du système. Ceci est destiné à réduire la latence d'accès en réduisant le temps nécessaire pour régler l'état d'une ligne de cache, mais avec tous les agents de cache sur le processeur distant répondant via QuickPath Interconnect, le bavardage de cohérence peut réduire considérablement la bande passante mémoire disponible entre les nœuds. Apparemment, avec le Haswell-EP E5-2620 v3, c'est suffisant pour perdre 75% de votre bande passante.
En revanche, en mode « home snoop », les messages sont d'abord traités par les agents d'accueil sur chaque contrôleur de mémoire, puis délégués aux agents LLC selon les besoins. Le saut supplémentaire ajoute une petite quantité de latence, mais avec l'avantage d'un débit considérablement accru. Notez qu'il y a beaucoup moins de messages envoyés via QuickPath Interconnect :
Voir ce poste pour une explication plus approfondie de la cohérence du cache NUMA.
Alors, qu'est-ce que c'est mieux de fouiner à la maison ?
Avec le mode espionnage modifié sur toutes les machines de notre cluster de test, Memory Latency Checker a montré un débit considérablement amélioré entre les processeurs :
Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Numa node
Numa node 0 1
0 45139.0 25323.8
1 25336.2 45021.7</var/www/wordpress>Mais mieux encore, la réduction de ce goulot d'étranglement a également amélioré de manière significative les performances de ces systèmes - non seulement cela a-t-il éliminé la régression de 30 % observée lorsque l'affinité d'interruption a été perdue, mais a ajouté 30 % supplémentaires de débit supplémentaire en plus :
| Test (4 nœuds, QC208) | Ligne de base (snoop précoce) | espionner à la maison | Modifier |
| Débit d'écriture | 4400 Mo/ | 6000 Mo/ | + 36% |
| Débit de lecture | 7650 Mo / s | 9550 Mo/s/s | + 29% |
Je me souviens du premier dépannage des problèmes de performances sur cette plate-forme il y a cinq ou six ans, très tôt dans ma carrière chez Qumulo - et j'ai un vague souvenir que nous avons expérimenté le mode espionnage à l'époque. À l'époque, cela ne faisait pas beaucoup de différence. Mais au fil des ans, alors que nous continuions d'améliorer les performances en supprimant les goulots d'étranglement logiciels, les performances de la plate-forme matérielle sous-jacente sont devenues le facteur limitant, donc augmenter la limite de débit QuickPath Interconnect est devenu une énorme victoire.
Ainsi, dans la toute prochaine version de Qumulo Core, nous avons ajouté du code pour inverser ce paramètre dans le BIOS pour tous les modèles concernés, afin que tous nos clients avec des déploiements existants bénéficient d'une plus grande capacité de débit.
Il y a beaucoup plus d'excellents travaux en cours chez Qumulo pour améliorer les performances de notre système de fichiers. La plupart du temps, c'est beaucoup plus difficile (et même plus intéressant) que de trouver un interrupteur caché « allez vite », alors continuez à surveiller cet espace !
Vous souhaitez en savoir plus sur l'ingénierie à Qumulo ? Voir plus de messages écrits par les ingénieurs de Qumulo, ici. Sinon, jetez un œil à la Qumulo Data Platform – Présentation de l'architecture logicielle (PDF).
PLUS DE LECTURE
- Histoire connexe sur l'utilisation de fio: 3 étapes pour une mesure de performance cohérente
- Série courte sur l'architecture de base de Qumulo: Construit avec la flexibilité matérielle à l'esprit (Partie 1)
- Suivez l'histoire: Stockage de fichiers d'entreprise indépendant du matériel de construction (Partie 2)
