Non officiel
Sur cette page
  1. 01Attentes matérielles et réalité
  2. 02Branche 1 : la base de référence, en isolant les services
  3. 03Branche 2 : états D et goulots d'étranglement cachés
  4. 04Allocation CPU : pCPU, lCPU et vCPU
  5. 05Surveillance des machines virtuelles
  6. 06Lecture des graphiques : les états critiques
  7. 07Bonnes pratiques KVM : le modèle CPU
  8. 08Connaissances de base : surallocation des ressources

Réalités matérielles, limites de ressources et surveillance approfondie des performances

Lorsqu'un NAS QNAP semble lent, l'investigation commence par ce que son matériel peut faire. Ensuite, on examine à quoi le NAS consacre ses ressources, et seulement après, on s'intéresse aux files d'attente plus profondes : les processus bloqués sur les E/S et les machines virtuelles qui se disputent le processeur.

  1. Attentesà quoi sert ce matériel
  2. Base de référencearrêtez les extras, surveillez la RAM et le SWAP
  3. États Dprocessus bloqués sur les E/S
  4. vCPUthreads, surréservation, vol (steal)
  5. GraphiquesBlackBox et Pulse, bien lire

01Attentes matérielles et réalité

Les serveurs QNAP sont construits avec des pièces qui correspondent à leur prix. QNAP fournit toujours des mises à jour de firmware pour des unités vieilles de plus de dix ans, mais cela ne signifie pas qu'un NAS ancien ou d'entrée de gamme peut faire tourner toute la gamme d'applications d'aujourd'hui sans compromis. Les logiciels s'alourdissent au fil de leur développement ; le matériel reste ce qu'il était.

Un NAS économique est conçu pour un partage de fichiers fluide. S'attendre à ce qu'il fasse tourner des machines virtuelles ou de lourdes bases de données sans problème, c'est mal comprendre ce qu'il est. Vérifiez ce que votre processeur et votre mémoire peuvent réellement faire, et assumez votre choix de matériel. La tâche principale du NAS est de travailler avec des fichiers ; tout le reste est un complément qui s'exécute dans la limite des ressources restantes.

02Branche 1 : la base de référence, en isolant les services

Lorsque le NAS ralentit, surtout lorsque sa mémoire s'épuise et qu'il commence à utiliser le SWAP (ce qui ralentit fortement toutes les opérations), la première étape de diagnostic consiste à isoler les services.

  1. Connectez-vous à QTS ou QuTS hero.
  2. Ouvrez l'App Center et arrêtez les applications et services non essentiels un par un. Workbench n'arrête pas les applications à votre place.
  3. Surveillez le système dans le Moniteur de ressources de QTS ou dans Pulse de Workbench (bureau Utilities, menu Démarrer → Monitoring → Pulse ; administrateurs uniquement). Son cockpit s'actualise toutes les deux secondes : utilisation du CPU avec une barre par CPU logique, RAM utilisée par rapport au total avec le cache de pages dans une bande distincte, une barre SWAP lorsque le NAS a du swap, la charge sur 1 minute et la file d'attente d'exécution. Regardez la charge du CPU et le SWAP utilisé diminuer.
  4. Trouver la base de référence : continuez à arrêter des services jusqu'à ce que la fonction principale du NAS, le partage de fichiers fluide, soit pleinement rétablie.

Il s'agit de la base de référence de votre matériel. À partir de là, démarrez les autres applications une par une, strictement dans la limite des ressources dont dispose encore le matériel.

Démonstration · 0:58. Pulse et BlackBox sur un NAS qui fait tourner quatre machines virtuelles sur douze threads : le cockpit, le verdict sur la contention CPU, l'onglet VM, le filtre D + Z, puis la carte thermique (heat map) du jour. Pulse · BlackBox · le NAS du propriétaire, en lecture seule

03Branche 2 : états D et goulots d'étranglement cachés

Parfois, le problème ne vient pas d'un CPU surchargé ou d'un manque de RAM. Le système peut se bloquer avec un processeur loin d'être à pleine charge lorsque des processus sont en veille ininterruptible, l'état D. Selon les propres termes de Workbench, un processus à l'état D est bloqué en attente d'E/S du noyau (disque, un système de fichiers réseau, un pilote figé) et ne peut même pas être tué tant que cette E/S n'est pas terminée. Quand de nombreux processus sont en D, c'est qu'ils font la queue, généralement derrière des E/S disque lentes, et l'appareil se fige.

Cette file d'attente pénalise surtout un NAS qui héberge des machines virtuelles (Virtualization Station, KVM). Une mauvaise allocation des ressources à ce niveau se traduit par des paquets réseau perdus et de longs délais d'E/S.

  • Pulse signale les Processes in D-state (I/O) dès qu'un processus est en D, et le marque comme critique au-delà de deux. Sur son onglet Processes, D + Z n'affiche que les processus bloqués (D) et zombies (Z) ainsi que leurs parents.
  • BlackBox enregistre le NAS toutes les 20 secondes dès que le paquet fonctionne ; il n'y a rien à activer. Il conserve l'utilisation du CPU, l'iowait et l'horloge par cœur, la charge, la file d'attente d'exécution et les Blocked (D) ; la mémoire utilisée et disponible, le cache de pages, le swap et les OOM kills ; par interface le trafic, les rejets et les retransmissions TCP ; par disque l'await, la profondeur de la file d'attente et l'utilisation ; les températures et les ventilateurs ; et par VM son CPU, ses vCPU, sa mémoire et ses E/S disque. Il conserve chaque échantillon de 20 secondes pendant un jour, puis des résumés par minute pendant une semaine, par cinq minutes pendant un mois et par heure pendant un an.
  • Deux décomptes D différents. Les Blocked (D) de BlackBox représentent le décompte par le noyau des tâches bloquées ; Pulse compte les processus qu'il voit à l'état D. Les deux valeurs peuvent différer.
  • iowait, pas PSI. Les noyaux de QNAP sont compilés sans les informations de blocage sous pression (Pressure Stall Information) : Workbench mesure donc le délai d'E/S par l'iowait.
Pulse, D + Z. Sur ce NAS, la barre de titre indique Processes in D-state (I/O), le filtre ne laisse que le processus en D et les zombies, et le cockpit au-dessus montre la mémoire presque pleine avec 15,2 sur 29,3 Go de swap en cours d'utilisation.

04Allocation CPU : pCPU, lCPU et vCPU

Avant d'attribuer des ressources à une VM, connaissez la topologie :

  • pCPU (physical CPU) : les cœurs physiques du processeur du NAS.
  • lCPU (logical CPU) : les cœurs vus par le système d'exploitation, Hyper-Threading inclus. L'Hyper-Threading ne double pas les performances ; en règle générale, il ajoute environ 30 % de débit.
  • vCPU (virtual CPU) : les cœurs virtuels attribués aux VM.

Pulse compte les CPU logiques : lorsqu'il indique 12 cores sur un Xeon W-1250 à six cœurs et douze threads, il s'agit de threads.

Le piège de la surréservation (oversubscription). Attribuer 128 vCPU à des VM sur un processeur à 32 cœurs suppose qu'ils ne seront jamais tous occupés en même temps. Lorsque c'est le cas, l'hyperviseur ne peut pas planifier les vCPU assez rapidement, et les VM se bloquent en attendant du temps CPU, ce qui se traduit à l'intérieur d'un invité par du « steal time » (temps volé). Pulse le signale côté hôte :

  • vCPU over-subscription (information) lorsque les VM en cours d'exécution ont plus de vCPU que le NAS n'a de CPU logiques ;
  • VMs contending for CPU (avertissement) lorsque, en plus de cela, l'hôte est occupé à plus de 75 % ou que sa file d'attente d'exécution est plus longue que son nombre de threads. Sa note sur ce NAS : Over-subscribed (17 vCPUs / 12 cores) AND the host is busy (84%, queue 11) — your VMs are likely contending for physical cores NOW. This is CPU theft, host-side.
  • Le steal time est mesuré à l'intérieur de l'invité. Sur le NAS, il vaut zéro par principe ; la propre note de Workbench indique que vous ne pouvez pas voir le vol d'un invité depuis l'hôte. Évaluez la contention sur le NAS d'après le nombre de vCPU comparé au nombre de threads, le pourcentage d'occupation et la file d'attente d'exécution, et lisez le steal à l'intérieur de la VM (la colonne st de top ou vmstat dans un invité Linux).
Pulse, CPU. VM contention, 17 vCPU sur 12 CPU logiques, la file d'attente d'exécution au-dessus du nombre de threads, chaque CPU occupée à près de 90 %, et une colonne de steal à 0 % sur l'hôte, comme il se doit.

05Surveillance des machines virtuelles

Workbench ne demande d'installer aucun agent dans une VM. Il mesure le NAS sur lequel il s'exécute, et cela inclut les machines virtuelles hébergées par le NAS :

  1. Ouvrez Pulse, l'onglet VM : chaque VM en cours d'exécution avec ses vCPU, % CPU, mémoire, RSS, état et identifiant de processus, et la ligne de titre Hosting 4 VM(s), 17 vCPUs.
  2. Ouvrez BlackBox (Menu Démarrer → Monitoring), passez à Heat map (carte thermique) et activez la ligne Virtual machines : le CPU de chaque VM tout au long de la journée, à côté des températures et de l'await des disques. Ses graphiques conservent également les vCPU, la mémoire et les E/S disque de chaque VM, ainsi que le démarrage et l'arrêt de chaque VM.
  3. Pour suivre l'accessibilité réseau d'une VM, ajoutez son adresse dans BlackBox sous Settings → Monitored hosts : BlackBox enregistre alors son aller-retour (round trip) et sa perte de paquets.
  4. À l'intérieur de la VM, surveillez son steal time avec les propres outils de l'invité.

La fenêtre Virtual Machines · LOCAL (Local NAS → Virtual Machines) affiche la configuration de chaque VM à partir de Virtualization Station : ses vCPU, sa topologie, son jeu de CPU, son modèle de CPU, ses disques et ses cartes réseau. À son ouverture, elle lance les dumps de diagnostic de QNAP lui-même vers le cache de Workbench ; elle ne modifie aucun paramètre.

Pulse, VM. Quatre VM, 17 vCPU en tout ; celle qui a 8 vCPU consomme plus de cinq cœurs de CPU. Le badge de l'onglet : 17 vCPU / 12 cores, en surréservation.

06Lecture des graphiques : les états critiques

  • État D élevé et délai d'E/S. Des processus sont en attente sur les disques. Le rapport hebdomadaire de BlackBox nomme cela Processes waiting on storage (un iowait au 95e centile de 20 % ou plus est un avertissement, 40 % ou plus critique) et désigne le disque le plus occupé ; Slow array member signale un disque dont l'await est le double de celui des autres disques de la grappe et d'au moins 50 ms (critique à 200 ms), et Disk with no headroom un disque occupé à 90 % ou plus pendant deux heures. Le remède correspond au conseil de l'auteur : déplacez la VM vers un volume SSD, vérifiez l'état de santé des disques (le guide des performances), et vérifiez qu'aucun autre processus ne sature le RAID.
  • Forte file d'attente CPU. Le processeur du NAS est en surréservation : Pulse indique VMs contending for CPU, et le rapport hebdomadaire Virtual machine hogging the host signale une VM qui utilise 150 % d'un cœur ou plus (300 % critique). Donnez moins de vCPU aux VM : commencez avec un ou deux par VM et ajoutez-en davantage uniquement lorsque l'invité en a besoin.
  • Bridage thermique (Thermal throttling). Une température CPU élevée, puis une horloge plus basse et des délais plus longs, signifient que le processeur surchauffe. Le rapport hebdomadaire l'appelle CPU thermal throttling : un cœur fonctionnant à 60 % ou moins de sa propre horloge habituelle alors que le CPU est occupé à au moins 60 %. Sur la carte thermique, 65 °C est ambre et 80 °C rouge. Le propre conseil de Workbench : nettoyez la poussière du dissipateur thermique, des ventilateurs et des entrées d'air, vérifiez que les ventilateurs tournent, et améliorez la circulation de l'air ou abaissez la température de la pièce ; une vitesse de ventilateur plus élevée dans QTS aide également.
BlackBox, carte thermique, 24 heures. Les cœurs et le package passent une grande partie de la journée à 80 °C ou plus (rouge), l'await des disques connaît des pics ici et là, et la ligne des machines virtuelles commence en dessous. La ligne des allers-retours de l'hôte (host round trips) est désactivée sur cette image.

07Bonnes pratiques KVM : le modèle CPU

  • Hôte / passthrough (recommandé) : transmet le processeur du NAS lui-même à la VM, avec chaque jeu d'instructions dont il dispose (AVX, par exemple). Cela offre les meilleures performances et la surcharge la plus faible sur un seul NAS.
  • Un modèle émulé (un CPU Intel ou AMD générique) : masque le processeur de l'hôte. C'est utile dans un cluster, pour déplacer des VM en cours d'exécution entre des hôtes physiquement différents ; sur un seul NAS, il ne fait que réduire les performances.

La fenêtre Virtual Machines · LOCAL montre le modèle de CPU attribué à chaque VM (par exemple Westmere) et sa topologie ; Workbench ne juge pas ce choix.

08Connaissances de base : surallocation des ressources (overcommit)

Comment ne pas écraser les performances des VM quand le NAS est à la limite de ses capacités. Le ratio de vCPU par rapport aux cœurs physiques (pCPU) est le premier chiffre à calculer :

Surallocation : gains, risques et conseils (Hyper-V, VMware, Citrix)
RessourceGainRisqueConseil
CPU (vCPU : pCPU)plus de VM, marge de manœuvre peu coûteuse pour de courtes pointesà saturation, le steal et les files d'attente ralentissent chaque VMproduction 2:1–4:1, VM critiques jusqu'à 2:1 ; hôte en dessous de 80 %
RAM (ballooning, Dynamic Memory)mémoire déplacée à la volée, utile pour les VM inactivesle swap de l'hôte entraîne une chute drastique des performancesne laissez jamais l'hôte swapper des pages actives ; réservez de la mémoire pour les VM critiques
Stockage (thin)espace économisé, disques créés en un instantun datastore plein arrête les VM immédiatementalertes à 75–85 % ; récupérez l'espace (UNMAP) ; données critiques plutôt en « thick »

Règle générale. L'overcommit est sûr sous une charge légère et inégale avec une surveillance active, et dangereux lors des pics sans marge de manœuvre. Gardez une réserve.

Astuces

  • Commencez avec 1 vCPU par VM et ajoutez-en davantage uniquement lorsque la charge le nécessite. Plus de vCPU que nécessaire signifie plus de surcharge pour le planificateur, pas plus de vitesse.
  • Comptez les cœurs physiques, pas les threads. Ne donnez pas à l'ensemble des VM plus de vCPU que l'hôte n'a de cœurs.
  • Gardez le CPU de l'hôte en dessous de 80 %. Au-dessus de 90 %, les VM se disputent les cycles et le steal augmente à l'intérieur des invités.
  • Lisez « top » dans l'invité : %wa est l'attente d'E/S (un goulot d'étranglement disque), %st est le steal (trop de surallocation), %id est la capacité de réserve.
  • %wa élevé ? Stockage plus rapide ou un SSD. %st élevé ? Moins de vCPU ou moins de VM.
  • VirtIO pour le disque et le réseau, beaucoup plus rapide que l'émulation. Le passthrough PCIe ou GPU uniquement lorsque c'est vraiment nécessaire : l'appareil appartient alors à une seule VM en exclusivité.

Un snapshot de VM n'est pas une sauvegarde

Un snapshot n'enregistre que la différence par rapport à son point de base (les modifications apportées aux disques, et avec un état sauvegardé, également la mémoire). Si la base ou la chaîne de snapshots est endommagée, les snapshots deviennent eux aussi inutilisables. Pour une véritable protection, sauvegardez des images de VM complètes : un export, HBS ou un support distinct.