Passer au contenu 
Je montre comment Métriques du serveur tels que CPU Idle, Load et iowait, de manière à pouvoir distinguer les véritables goulots d'étranglement des fluctuations inoffensives et à prendre des mesures correctives ciblées. J'explique quelles valeurs limites sont judicieuses, comment les chiffres clés interagissent et comment je peux déduire des mesures concrètes à partir des valeurs mesurées.
Points centraux
- CPU au reposindique le temps de calcul disponible et les phases d'attente cachées
- Charge moyennemesure les files d'attente et la charge du noyau
- iowait: démasque les freins au stockage et au réseau
- InteractionReconnaître des modèles au lieu de voir des valeurs isolées
- Alertesdéfinir des seuils et des tendances pertinents
Interpréter correctement CPU Idle
Je lis CPU au repos comme la part du temps pendant laquelle le CPU n'exécute rien ou attend des E/S, et je l'évalue toujours dans le contexte des charges de travail actuelles. Si Idle reste souvent au-dessus de 60 à 80 pour cent, je planifie davantage de tâches ou j'adapte les services vers le bas, car des réserves sont inutilisées. Si Idle descend en dessous de 20 % pendant une période prolongée, je recherche d'abord les processus liés au CPU, les boucles inefficaces et le manque de parallélisation. Si Idle s'effondre alors que le temps utilisateur (us) et le temps système (sy) sont élevés, il y a beaucoup à dire sur la faim de calcul pur ; si Idle chute alors que iowait augmente, cela indique au contraire des blocages en dehors du CPU. Pour les serveurs web, je considère qu'une fourchette de 20 à 40 % d'inactivité en moyenne quotidienne est saine, à condition que les temps de réponse restent stables et qu'aucune anomalie n'affecte sensiblement les utilisateurs.
Comprendre la charge du serveur
Je valorise le Charge moyenne comme nombre moyen de processus qui veulent calculer ou qui attendent du temps de CPU, et le compare directement au nombre de noyaux. Si la charge d'une minute dépasse de manière répétée le nombre de cœurs, des files d'attente se forment, ce qui se traduit par des retards dans l'ordonnancement et des requêtes plus longues à exécuter. Pour les décisions quotidiennes, je tiens surtout compte des charges de 5 et 15 minutes, car elles permettent de lisser les heures de pointe et d'éviter les fausses alertes dues à des pics courts. Sur un serveur à 4 cœurs, j'interprète les valeurs de charge jusqu'à environ 3,2 comme une utilisation solide, pour les valeurs à partir de 4,0, j'examine activement les processus, les verrous et les chemins d'E/S. Si vous voulez éviter les erreurs d'interprétation typiques de la charge, vous trouverez des conseils pratiques dans Bien interpréter la charge moyenne, J'ai également publié un article sur les cas limites et les exemples de calcul.
Délimiter clairement l'attente I/O (CPU Wait)
Je distingue iowait car le CPU est prêt mais ne peut pas calculer car il attend des opérations de stockage ou de réseau. Si iowait reste en permanence au-dessus de 10 %, je vérifie d'abord les latences des disques, les profondeurs de file d'attente, les goulots d'étranglement du système de fichiers et les chemins d'accès au réseau. Si de nombreux processus apparaissent dans top avec le statut D (uninterruptible sleep), cela renforce mon soupçon d'accès E/S bloquants. Dans de tels cas, des SSD NVMe, plus d'IOPS, des options de montage optimisées ou un cache de page plus important accélèrent le traitement avant que je ne pense à une mise à l'échelle. Le guide fournit une introduction compacte avec des schémas types Comprendre l'attente E/S, J'ai besoin de quelqu'un qui m'aide à faire un premier diagnostic.
Classer correctement la pression de la mémoire
Je sépare Pression de la mémoire conscient des bottlenecks CPU et I/O, car le manque de mémoire a ses propres signatures. Si l'activité de recouvrement de page augmente, je vois dans vmstat les colonnes si/so (swap in/out) ou dans sar les taux de paresse de page, et je corrèle cela avec iowait et les temps de réponse. Une utilisation modérée du swap n'est pas automatiquement mauvaise en cas de cache de page important, mais un swap continu ralentit chaque CPU. Dans de telles situations, la part d'inactivité ne diminue pas nécessairement, alors que la charge peut augmenter - les processus attendent alors les pages récupérées et bloquent la file d'attente d'exécution. Je vérifie de manière ciblée la part du cache de pages (free/buffers/cache), les défauts majeurs des processus concernés et le paramètre de swappiness avant de redimensionner la RAM ou d'ajuster les caches. Sous Linux, j'utilise en plus PSI (Pressure Stall Information) sous /proc/pressure/memory pour voir si les tâches attendent sensiblement de la mémoire. Si le PSI montre des décrochages élevés sur des fenêtres de temps significatives, j'augmente la marge de manœuvre du cache de pages, je soulage par des caches d'objets/de requêtes dans l'application ou je déplace les tâches par lots dans des fenêtres plus calmes, afin que les charges de travail interactives ne soient pas étouffées par la pression de la mémoire.
Interaction entre Idle, Load et Wait
J'évalue le Interaction des indicateurs, car les modèles sont plus révélateurs que les valeurs individuelles. Une charge élevée associée à une inactivité importante indique souvent des blocages d'E/S : De nombreux processus attendent, le CPU lui-même s'ennuie. Un Idle faible avec un Load faible indique par contre des processus individuels intensifs en calcul qui occupent longtemps le CPU sans provoquer de grandes files d'attente. Si le Steal-Time (st) augmente en outre dans les VM, j'informe l'hébergeur d'une surréservation potentielle ou j'envisage de changer d'hébergeur. Ce n'est que lorsque l'interaction semble propre que je décide de mesures telles que le redimensionnement vertical, la répartition horizontale ou l'optimisation ciblée du code.
Prendre en compte la fréquence du CPU, le turbo et le throttling
Je vérifie Fréquences CPU et turbo-boost, car les pourcentages (us/sy) peuvent être trompeurs si la fréquence est mise à l'échelle de manière dynamique. Si la fréquence diminue (Power-Saving, Thermal-Throttling), la puissance de calcul absolue diminue, bien que l'état inactif et la charge puissent paraître inchangés. Je lis les MHz momentanés par cœur (par ex. via turbostat ou cpupower) parallèlement à la charge de travail et j'évalue les pics en fonction de la température et du gouverneur (powersave, performance). Si des pics de latence apparaissent lors de courtes phases d'inactivité, des C-States bas (C6+) peuvent augmenter le temps de réveil - pour les services critiques en termes de latence, je fixe des limites C-State plus conservatrices ou le gouverneur de performance, tandis que la charge par lots profite de l'économie d'énergie. Je découvre Throttling thermique sous charge continue, je planifie des améliorations du refroidissement, je réduis les tâches d'arrière-plan non critiques pendant les phases chaudes ou je répartis les charges de travail pour que les cœurs ne ralentissent pas et que les métriques donnent une image plus réaliste.
NUMA, interruptions et affinité
Je fais attention à Zones NUMA et la répartition des interruptions, car les trafics croisés faussent les métriques. Si un thread accède de manière répétée à la mémoire du „mauvais“ nœud NUMA, les latences augmentent sensiblement, tandis que Load et iowait montrent des schémas du type „beaucoup de travail, mais peu de progrès“. Je vérifie les hotspots avec numactl/numastat, j'épingle les charges de travail aux nœuds (CPU et mémoire) si nécessaire et je fais attention à la taille des pools de tampons par socket pour les bases de données. Je répartis la charge du réseau via RSS/RPS/XPS et je contrôle /proc/interrupts pour éviter qu'un seul cœur ne porte toutes les interruptions de la carte réseau et ne serve de goulot d'étranglement. Si je détecte une forte proportion de sy% avec peu de travail de la part de l'utilisateur, je l'interprète comme un indicateur de la pression de l'IRQ, des chemins de copie du noyau ou du checksumming - dans de tels cas, des pilotes mis à jour, des options de déchargement adaptées et un juste équilibre de l'IRQ sur les noyaux aident.
Un flux de travail de diagnostic rapide sur le terminal
Je commence avec top ou htop pour voir immédiatement le breakdown du CPU (us, sy, ni, id, wa, hi, si, st), les valeurs de charge et les processus remarquables. Ensuite, je vérifie uptime pour le load à trois valeurs et je compare les tendances de 1, 5 et 15 minutes avec le temps événementiel. Avec vmstat, j'obtiens un aperçu du flux de la file d'attente d'exécution, des changements de contexte, de l'activité de swap et des historiques iowait. Pour le disque, j'utilise iostat, je lis tps, await, svctm et j'identifie les pics de latence par périphérique ou LUN. Si pidstat et perf indiquent des points chauds dans le code, je donne la priorité aux chemins concernés avant de penser au matériel, car j'obtiens souvent des gains rapides en apportant un petit correctif au bon endroit.
Conteneurs et Cgroups : détecter le throttling
Je note Limites des conteneurs comme cause possible lorsque les images de charge ne correspondent pas. Si les quotas CPU (CFS) réduisent le temps de processus, je vois une charge croissante avec un temps us% étonnamment faible, car les tâches attendent la prochaine fenêtre de tranche de temps. Dans Kubernetes, je veille à ce que requests et limits sont réalistes : Des limits trop serrés conduisent au throttling, des requests trop bas à des goulots d'étranglement d'ordonnancement sur le nœud. Je vérifie les compteurs de throttling du cgroup, j'observe les conteneurs avec un taux de changement de contexte élevé et une affinité étroite avec le CPU pinning et je mets d'abord à l'échelle les quotas avant de mettre à niveau les nœuds. Les limites de mémoire sans headroom menacent de tuer les OOM - je le reconnais aux processus qui s'interrompent brusquement, aux défauts majeurs remarquables en amont et aux pics de latence erratiques. Les antidotes sont des headrooms judicieux, une répartition horizontale et des tampons pour les tâches d'arrière-plan, afin que les chemins productifs ne soient pas freinés par des limites.
Choisir judicieusement les valeurs limites et les alertes
Je mets Valeurs seuils de manière à ce qu'ils signalent les risques réels et que les pics à court terme ne déclenchent pas constamment des alertes. Pour le CPU Idle, je prévois des alertes à partir d'environ 20 %, pour iowait à partir de 10 %, et pour Load à partir de 80 % des cœurs, à chaque fois avec un court délai. Un deuxième niveau avec un seuil plus élevé déclenche l'escalade ou l'auto-scaling, afin que je gagne du temps pour agir. Pour l'observation des tendances, j'utilise la charge de 15 minutes et je la compare aux modèles journaliers et hebdomadaires afin d'identifier les pics saisonniers. J'envoie des alertes groupées afin de rester concentré sur les situations d'incident et de ne pas être noyé sous les notifications.
| Métriques | Orientation | avertissement | Critique | Cause possible | Action rapide |
|---|---|---|---|---|---|
| CPU au repos | > 60 % | < 20 % | < 10 % | Chemin de code fort, pas assez de noyaux | profiler les hotspots, les mettre en parallèle |
| Charge | < nombre de noyaux | > 0,8 × noyaux | > 1,0 × noyaux | files d'attente, locks, embouteillage d'E/S | Vérifier les processus de haut niveau, réduire le verrouillage |
| iowait | < 5 % | > 10 % | > 20 % | Disque/réseau lent, files d'attente trop petites | NVMe/RAID, augmenter la profondeur de la file d'attente |
Planification des capacités avec les SLO et les baselines
J'associe Capacité avec des SLO (par ex. temps de réponse 95%) au lieu d'utiliser uniquement des valeurs moyennes. Pour le CPU, je déduis des objectifs de headroom (par exemple P95-Idle pas en dessous de 20 pour cent), afin que les charges de pointe courtes ne se transforment pas immédiatement en files d'attente. Pour la charge, j'utilise des bases historiques par moment de la journée et par saison pour construire des seuils dynamiques qui tiennent compte de la croissance ou des campagnes. Je définis les alertes comme un composite : Ce n'est que lorsque, par exemple, la charge > noyaux, iowait > 10 pour cent et la latence P95 augmentent que le niveau 2 se déclenche. Dans les environnements cloud, je prévois des réserves de niveau (p. ex. +25 pour cent de noyaux, +x IOPS) et je tiens à disposition des playbooks sur la manière dont les règles d'auto-scaling s'appliquent sans générer de thrash. Je vérifie les modifications à l'aide de mesures A/B, je documente les métriques avant/après et je m'assure que les optimisations ne se contentent pas de déplacer la charge, mais qu'elles éliminent durablement les goulets d'étranglement.
Causes typiques et solutions
Je vois souvent des valeurs iowait élevées sur de petits volumes cloud avec une garantie d'IOPS trop faible, c'est pourquoi je passe de manière ciblée au stockage NVMe ou à des volumes plus grands avec une garantie plus élevée et je réduis nettement les temps d'attente. Si une charge élevée arrive avec un iowait normal, je trouve souvent des regex inefficaces, des caches manquants ou des chatty-ORM, que je désamorce avec des index, le Query-Tuning et le Response-Caching. Lorsque le temps système domine, je regarde les interruptions réseau, les niveaux des pilotes et les fonctionnalités de déchargement de la carte réseau, car les tempêtes d'IRQ mobilisent le CPU. En cas d'irruptions sporadiques avec un temps de vol simultané dans les VM, je vérifie l'occupation des hôtes et je tire une fenêtre de déménagement dans un quartier moins bruyant. Si l'application évolue horizontalement, je scelle les goulots d'étranglement par des caches centraux, des files d'attente asynchrones et des délais d'attente clairs, afin que des fugueurs isolés ne bloquent pas tout le nœud.
Virtualisation : attention au steal time
Je mesure steal time (st) dans les environnements virtualisés, car elle indique dans quelle mesure l'hyperviseur détourne le temps de calcul. Si st augmente régulièrement de plus de quelques pour cent, je partage le ticket avec le fournisseur avec des preuves de métriques et je demande un déménagement ou des ressources dédiées. Dans les scénarios multi-locataires, je prévois en outre des tampons pour la charge, afin que les courts goulots d'étranglement causés par les voisins n'entraînent pas directement des alarmes. Du côté de l'hôte, je réduis les tâches d'arrière-plan inutiles afin de créer plus d'espace pour la charge productive dans les fenêtres délicates. Pour les systèmes critiques, je préfère les cœurs dédiés ou les instances bare metal afin de garantir des temps de latence prévisibles.
Tableaux de bord et pratique du monitoring
Je construis Tableaux de bord de telle sorte qu'ils montrent ensemble les valeurs d'arrêt du processeur, de charge, d'iowait, de mémoire, de disque et de réseau et me fournissent des chaînes de causes en quelques secondes. Des intervalles d'échantillonnage courts de cinq secondes révèlent des pics, tandis que des vues condensées font apparaître des tendances. Je crée des alertes en fonction de la saisonnalité et du moment de la journée, afin que les équipes de nuit ne se déclenchent pas à chaque pic. Lors de l'évaluation, je m'aide de playbooks dans lesquels j'enregistre des tests standard et des voies d'escalade afin que personne ne parte de zéro. Ceux qui souhaitent commencer de manière structurée peuvent s'inspirer de ma contribution Evaluer les données de monitoring qui regroupe les principaux panels et indicateurs.
Des tests de performance sans points aveugles
Je vérifie Goulots d'étranglement non seulement à pleine charge, mais aussi pendant les phases d'inactivité, car les sauvegardes, les tâches cron et les exécutions d'index perturbent souvent la nuit. Pour les applications avec un trafic en rafale, je crée des profils de charge réalistes qui incluent des caches froids et des phases d'échauffement. J'enregistre systématiquement les comparaisons A/B avant et après les modifications afin de séparer les effets réels des fluctuations aléatoires. Pour les chemins de stockage, je corrèle la latence, les profondeurs de file d'attente et le débit afin d'identifier les causes et les effets. Au niveau du réseau, j'utilise la capture de paquets de manière ponctuelle lorsque les métriques seules n'expliquent pas pourquoi les requêtes restent bloquées.
Recettes de cuisine pour la pratique : Échantillons de mesures
- Load élevé, idle élevé, iowait élevé : vérifier les chemins d'E/S, augmenter la profondeur de la file d'attente, mettre en cache avant le disque.
- Faible inertie, faible charge : Un seul thread chaud - profilage, parallélisation ou batch.
- sy% élevé, us% normal : optimiser le hotpath IRQ/noyau, le driver/offloading et la distribution des interruptions.
- Load proche du nombre de noyaux, pics de latence uniquement sous l'étranglement du turbo : vérifier le refroidissement/le gouverneur, éviter l'étranglement.
- Conteneurs avec traces de throttling : augmenter les quotas CPU, harmoniser les requêtes/limites, réduire la co-tenancy.
- Memory-PSI augmenté, iowait modéré : adapter le cache de page/le working-set, ajouter de la RAM ou déplacer des jobs batch.
En bref
Je lis CPU au repos, Load et iowait, car l'échantillon fournit le résultat et clarifie mes prochaines étapes. Avec des seuils clairs, des intervalles courts et des tableaux de bord pertinents, j'évite les vols à l'aveuglette et je réagis à temps. Pour la charge CPU, je cherche des points chauds dans le code, pour iowait, de meilleurs chemins I/O et la mise en cache, pour une charge élevée, je simplifie les files d'attente et la synchronisation. Dans les VM, j'intègre le steal time pour que les limites de l'infrastructure n'apparaissent pas comme un problème d'application. En respectant cette discipline, on réduit les pannes, on utilise les ressources à bon escient et on maintient les temps de réponse à un niveau bas et fiable.
