Passer au contenu 
Charge moyenne indique le nombre de processus en cours d'exécution ou en attente de temps CPU, et non le pourcentage d'utilisation du CPU. Ceux qui lisent cette valeur hors contexte réagissent souvent avec panique ou procèdent à des mises à niveau inappropriées. Je vais vous expliquer comment l'interpréter correctement et en tirer des conclusions utiles pour l'hébergement.
Points centraux
- Pas de CPU%: Load compte les processus dans la file d'attente d'exécution.
- Par noyau Pensez : divisez la charge par le nombre de noyaux.
- Attente E/S souvent plus sollicité que le CPU.
- 1/5/15-Les moyennes sur plusieurs minutes lissent les pics.
- Contexte Avant les mesures : heure, emplois, trafic.
Ce que mesure réellement la charge moyenne
Je lis la valeur comme le nombre moyen de Processus, qui sont actifs pendant 1, 5 et 15 minutes ou qui attendent dans la file d'attente d'exécution. Beaucoup le confondent avec la charge CPU en pourcentage, mais le compteur ne connaît que les files d'attente, pas le temps de calcul. Une charge de 1,0 signifie une utilisation maximale permanente sur un système à un seul cœur, tandis que la même valeur reste modérée sur quatre cœurs. Je compare donc toujours la charge par rapport à la chiffre clé et n'évalue ensuite que s'il s'agit d'une véritable surcharge. La moyenne sur 15 minutes montre les tendances et m'aide à distinguer les pics éphémères des charges persistantes.
Pourquoi les valeurs élevées indiquent souvent des problèmes d'E/S
Une charge élevée peut survenir même si le CPU fonctionne à peine – les files d'attente d'E/S bloquent alors Fils de discussion. Je vérifie la proportion %wa (I/O-Wait) avec top ou htop et j'utilise iotop pour voir quels processus ralentissent le stockage. Souvent, la cause réside dans des bases de données lentes, des tâches de sauvegarde ou des lecteurs réseau surchargés. Si %wa augmente, une mise à niveau du processeur n'apporte pas grand-chose ; un stockage plus rapide, la mise en cache et moins de synchronisations ont un effet plus important. L'article suivant fournit des informations détaillées à ce sujet. Comprendre l'attente E/S, que je consulte lorsque les délais d'attente sont trop longs.
Idée fausse : la charge correspond à l'utilisation du processeur
Je fais une distinction stricte entre les pourcentages de la CPU et la charge moyenne comme métrique de file d'attente. Une charge de 8 sur un serveur à 8 cœurs peut être normale si tous les cœurs fonctionnent et qu'il n'y a pas d'attente. La situation devient critique lorsque la charge est nettement supérieure au nombre de cœurs et que la courbe sur 15 minutes augmente simultanément. Pour voir les corrélations, je place côte à côte CPU%, I/O-Wait, les temps de planification et les listes de processus. Seule l'interaction de ces signaux m'indique si la machine calcule, bloque ou traite simplement de nombreuses tâches de courte durée.
Classer correctement les pointes au lieu de donner l'alerte
Les pics de charge courts dus à Cron, à la rotation des journaux ou aux sauvegardes font partie du quotidien et ne signifient pas automatiquement Dérangement. J'évalue toujours l'heure, la durée et la ligne des 15 minutes avant de déclencher des alarmes ou d'ajouter de la capacité. Je calibre les seuils avec le nombre de cœurs, par exemple, alarme uniquement lorsque la charge est supérieure à 2× cœurs pendant plusieurs minutes. Je vérifie également les pics irréguliers dans les systèmes de gestion de contenu pour les tâches en arrière-plan ; pour WordPress, la remarque suivante s'applique Tâches cron WP et charge. Je préviens ainsi les réactions irréfléchies et privilégie les mesures utiles.
Lire la charge moyenne dans le quotidien de l'hébergement
Je démarre avec uptime pour un aperçu rapide, puis j'ouvre htop, pour voir les processus, la répartition du CPU, la RAM et les E/S. Si la charge sur 15 minutes reste élevée, je recherche les coupables à l'aide d'iotop ou de pidstat. Pour les charges de travail liées aux bases de données, je vérifie les latences des requêtes, les index et les hits du cache. Sur les serveurs web, je vérifie si trop de workers PHP simultanés sont en attente ou si, le cas échéant, l'OpCache intervient. Cette routine permet de distinguer les symptômes des causes et m'évite des mises à niveau matérielles coûteuses et inefficaces.
| Métriques | Vie quotidienne | Signal d'alarme (4 noyaux) | Prochaine étape |
|---|---|---|---|
| Chargement 1 min | <4 | >8 pendant 3 à 5 minutes | Vérifier les processus prioritaires |
| Charge 15 min | <3 | >6 en augmentation | Planifier la capacité/l'architecture |
| CPU% | <80% | >95% permanent | Optimiser le code/les travailleurs |
| Attente E/S | <10% | >20% Pointes | Vérifier le stockage/la mise en cache |
Outils pour une surveillance propre de l'hébergement
Je combine Métriques à partir d'agents avec des journaux et des traces afin de trouver plus rapidement les causes. Pour les séries chronologiques, j'utilise Prometheus ou d'autres collecteurs, visualisés dans Grafana. Sur le plan infrastructurel, Zabbix m'aide pour les vérifications et les règles d'alerte flexibles, ainsi que les services SaaS pour les tableaux de bord rapides. Il est important d'avoir une vue uniforme de la charge, du CPU%, de la RAM, du swap, des latences du disque et du réseau. Sans chronologie commune, l'interprétation des valeurs de charge reste fragmentaire.
| Catégorie | Exemple | Points forts |
|---|---|---|
| Open-Source | Zabbix | Contrôles, agent, logique d'alarme |
| Série chronologique | Prometheus | Modèle Pull, PromQL |
| visualisation | Grafana | Tableaux de bord, alertes |
| SaaS | Datadog | Intégrations, APM |
Optimisation en cas de charge élevée permanente
Je commence par la douleur la plus intense : la lenteur. Requêtes, des chemins d'E/S bloquants ou un trop grand nombre de travailleurs simultanés. Les index de base de données, les pools de connexions et les caches de requêtes tels que Redis ou Memcached réduisent considérablement le temps d'attente. Au niveau de l'application, je soulage la source : mise en cache de pages, de fragments et d'objets, et traitement propre des files d'attente. Au niveau du système, je règle vm.swappiness de manière appropriée, je vérifie les pages volumineuses et je fixe des limites raisonnables pour les services. Ce n'est que lorsque les possibilités logicielles sont épuisées que je procède à une mise à l'échelle verticale (plus de RAM/CPU) ou horizontale (plus d'instances avec équilibreur de charge).
Charge moyenne sur les systèmes multicœurs
Je calcule toujours la charge par rapport à Noyaux: Load 16 peut être acceptable sur 16 cœurs physiques. L'hyper-threading double le nombre de processeurs logiques, mais les performances réelles ne suivent pas toujours une courbe linéaire ; j'évalue donc également les latences. Dans les conteneurs ou les machines virtuelles, les parts de CPU, les quotas CFS et les limites entrent en jeu, ce qui fausse les valeurs apparemment „ normales “. Un coup d'œil au throttling du CPU et aux temps d'attente du planificateur permet de distinguer les limites strictes des véritables problèmes de capacité. Pour prendre des décisions claires, je m'appuie sur la courbe de 15 minutes comme référence de tendance.
Hébergement mutualisé, voisins et goulots d'étranglement cachés
Dans les environnements partagés, l'influence de voisins souvent plus forte que celle de ma propre application. C'est pourquoi j'observe également le CPU-Steal, les temps de disponibilité et les conflits de stockage afin de détecter les charges externes. Si des cœurs sont „ volés “, la charge continue d'augmenter malgré mes propres optimisations. Pour prendre ma décision, je me base sur le guide suivant Temps d'utilisation du processeur et planifie des ressources dédiées si nécessaire. Je garantis ainsi des performances prévisibles au lieu de rester bloqué dans un goulot d'étranglement.
Définir correctement les tendances, les seuils et les alertes
Je calibre les seuils par Noyau et je définis une hystérésis afin que les alarmes ne se déclenchent pas à chaque pic. Pour 4 cœurs, je commence par des alarmes à partir d'une charge > 8 pendant plusieurs minutes et je confirme avec une tendance sur 15 minutes. J'exclus les fenêtres de maintenance et les temps de traitement par lots de l'évaluation afin que les graphiques ne donnent pas une image faussée de la situation. De plus, j'utilise la détection des anomalies par rapport à la médiane historique propre à l'entreprise, au lieu de perpétuer des valeurs fixes rigides. Cela me permet de réagir rapidement aux changements réels sans fatiguer l'équipe avec de fausses alertes.
Comment Linux compte réellement la charge
Si nécessaire, je jette un œil sous le capot : le noyau calcule la longueur moyenne de la file d'attente d'exécution et compte non seulement les threads actifs (état „ R “), mais aussi ceux en sommeil ininterrompu („ D “, généralement état d'attente E/S). C'est précisément ce qui explique les valeurs de charge élevées pour une faible utilisation du processeur : de nombreux threads bloquent le noyau sur des disques lents, des accès réseau ou NFS. Dans /proc/loadavg Je vois les trois moyennes, ainsi que les threads „ en cours/totaux “ et le dernier PID. Les zombies ne jouent aucun rôle ici, mais les threads du noyau et les threads utilisateur sont pris en compte de manière égale. Sur les systèmes comportant de nombreuses tâches de courte durée (builds, workers), la valeur sur 1 minute varie naturellement davantage, tandis que la valeur sur 15 minutes reste mon repère de stabilité.
Pour moi, il est important de traduire „ charge “ par „ temps d'attente “ : si la charge est nettement supérieure au nombre central, des files d'attente se forment. Cela n'est pas nécessairement mauvais s'il s'agit de tâches de courte durée, mais si la latence des requêtes augmente en même temps, le système bascule en surcharge. C'est pourquoi je considère toujours la charge en relation avec Durée de validité(Req-Latency, ttfb) afin d'évaluer les files d'attente non seulement en termes de chiffres, mais aussi en termes d'impact.
Pression mémoire, swap et blocages cachés
Je constate souvent des valeurs de charge élevées constantes dans les cas suivants pression de stockage. Lorsque le cache de page diminue ou que kswapd déplace des pages, les processus se retrouvent en attente. Le swapping génère des E/S et ralentit tout. Je vérifie vmstat (si/so), erreurs de page majeures, /proc/meminfo (Cached, Dirty, Writeback) et observez si les latences d'E/S augmentent simultanément. Une charge élevée avec un CPU% modéré et un „ await “ disque croissant est pour moi un signe clair : il manque de la RAM ou l'ensemble de données ne tient pas dans le cache.
Je réagis par étapes : d'abord, j'identifie les points chauds de la RAM (par exemple, les tris volumineux, les requêtes non mises en cache, les tableaux PHP gigantesques), puis je renforce les caches et vm.swappiness de manière à ce que la mémoire vive ne soit pas évincée trop tôt. Il est rarement judicieux de désactiver complètement le swap : un swap petit et rapide (NVMe) utilisé de manière disciplinée permet d'éviter les pics OOM Killer. Si les écritures différées deviennent un goulot d'étranglement, j'atténue les vagues de synchronisation (traitement par lots, options de journalisation, vidages asynchrones) et je réduis le nombre d'écritures simultanées.
Conteneurs, cgroups et limitation du CPU
Dans Containers, j'interprète Load en tenant compte de cgroups. Les quotas CFS limitent le temps CPU par période ; lorsque la limite est atteinte, le conteneur continue d'afficher des valeurs de charge élevées, même s'il est simplement réduit Je vérifie. cpu.max (cgroup v2) ou. cfs_quota_us/cfs_period_us (v1) et le compteur d'accélération (cpu.stat). Si „ throttled_time “ augmente, cela n'est pas dû à un manque de puissance de calcul, mais à des limites strictes. Dans Kubernetes, je fais une distinction stricte entre les „ requêtes “ (planification) et les „ limites “ (restriction) : des limites mal définies génèrent des files d'attente artificielles.
L'affinité CPU et NUMA influencent également le résultat : si les threads sont épinglés sur quelques cœurs ou placés sur un nœud NUMA, la charge peut s'accumuler localement, tandis que le CPU% global semble correct. Je répartis les threads chauds de manière ciblée, je vérifie l'équilibrage IRQ et je veille à ce que les conteneurs ne soient pas tous concentrés sur les mêmes cœurs physiques. Je réduis ainsi les temps d'attente sans avoir à mettre à niveau le matériel.
Liste de contrôle pour une prise de décision rapide
- Charge relative à Noyaux évaluer (charge/cœurs ≈ 1 bon, ≫1 critique).
- CPU% et Attente E/S Opposer : la caisse calcule-t-elle ou attend-elle ?
- 15 minutesVérifier la tendance : surcharge prolongée ou pic bref.
- Processus de pointe et States (R/D/S/Z) ; nombreux D-States = goulot d'étranglement E/S.
- Latences du disque, Mesurer la profondeur de la file d'attente et %util ; vérifier également les chemins d'accès NFS/réseau.
- RAM: Erreurs de page, activité de swap, kswapd – Réduire la pression sur la mémoire.
- Limites Vérifier dans les conteneurs/VM : quotas, partages, vol, limitation.
- Concurrence limiter : travailleurs/threads, files d'attente, contre-pression.
- Pointes temporelles Déplacer : Cron, sauvegardes, index, ETL.
- réajustement, puis mesurez à nouveau – l'effet avant le matériel.
Exemples concrets de tuning dans le domaine de l'hébergement
Sur les piles Web/PHP, Concurrence le plus grand levier. Je mise sur PHP‑FPM de manière réaliste pm.max_children, afin que les requêtes ne saturent pas la base de données en parallèle. Dans nginx ou Apache, je limite les connexions amont simultanées, j'active Keep-Alive de manière judicieuse et je laisse les ressources statiques se mettre en cache de manière agressive. L'OpCache empêche les tempêtes de préchauffage, tandis qu'un cache d'objets (Redis/Memcached) réduit considérablement la charge des requêtes.
Pour les bases de données, je commence par Indexation et plans. Au lieu d'augmenter aveuglément les connexions, j'utilise des pools de connexions et limite les requêtes simultanées coûteuses. Je surveille les taux d'accès au pool de tampons, les temps d'attente de verrouillage et les débordements de tables temporaires. Les rapports volumineux ou les tâches de migration s'exécutent de manière asynchrone et par lots – je préfère une charge constante de 60% à 5 minutes de 200% suivies d'un arrêt complet.
Pour les runners gourmands en mémoire (par exemple, le traitement d'images/vidéos), je définis une limite maximale de tâches simultanées par hôte. Je définis sympa et ionice, afin que les processus par lots ne perturbent pas les latences interactives. Sur les disques NVMe rapides, je veille à ce que la configuration du planificateur reste légère, à ce que la profondeur de la file d'attente soit suffisante et à éviter les synchronisations bavardes. Ainsi, les avalanches D-State disparaissent et la charge diminue sans que CPU% n'augmente : la machine attend tout simplement moins.
Exécuter les charges de travail de compilation et de traitement par lots de manière planifiée
Lors de la compilation ou du rendu, la charge est fortement corrélée à la Parallélisme des tâches. Je choisis -j Conscient : les noyaux × (0,8–1,2) constituent un bon début, mais je me réfère à RAM Il vaut mieux avoir moins de tâches parallèles stables que des pics de charge importants. Les caches d'artefacts, les compilations incrémentielles et les volumes d'E/S dédiés empêchent les états D de saturer la file d'attente avec de nombreux petits fichiers.
Je planifie les fenêtres batch avec une faible charge. Les rotations, les sauvegardes, les ETL et les réindexations s'exécutent de manière échelonnée, et non pas toutes à l'heure pile. Les files d'attente de travail sont soumises à une contre-pression : seuls les nouveaux travaux sont traités lorsque des emplacements sont disponibles, au lieu d'un simple „ fire-and-forget “. Cela permet de contrôler la charge et les latences, et de rendre les pics prévisibles.
PSI : Pressure Stall Information, un système d'alerte précoce
En plus du Load classique, j'utilise le Informations sur le décrochage par perte de pression (PSI) de Linux dans /proc/pressure/cpu, .../io et .../mémoire. PSI indique la durée des tâches collectivement ont dû attendre – idéal pour éviter la surcharge tôt Si la pression CPU augmente pendant plusieurs minutes alors que CPU% est modéré, je sais que la file d'attente d'exécution est encombrée. La pression E/S me permet de voir si les latences de stockage ont un impact sur l'ensemble du système, même si les valeurs iotop individuelles semblent inoffensives.
Je combine le PSI avec la charge sur 15 minutes : si les deux augmentent, la saturation est réelle. Si seule la charge augmente, mais que le PSI reste stable, il est possible que de nombreuses tâches courtes soient en cours d'exécution, sans que les utilisateurs ne s'en aperçoivent. Il en résulte des alertes plus claires et de meilleures décisions : augmenter les limites, répartir les tâches ou renforcer le matériel de manière ciblée là où des goulots d'étranglement sont mesurables.
Bref aperçu à emporter
Je lis le Charge Jamais isolées, mais dans le contexte des cœurs, de l'attente E/S, du CPU% et de la courbe de 15 minutes. Je n'interprète les valeurs élevées qu'après avoir examiné les latences de stockage et de réseau, car c'est souvent là que se trouve le véritable frein. Pour les mesures à prendre, je donne la priorité aux leviers visibles : requêtes, mise en cache, travailleurs, limites, puis seulement ensuite le matériel. Dans les environnements partagés, je vérifie les effets parasites tels que le vol et, si nécessaire, je planifie des ressources dédiées. Grâce à ces règles, je prends des décisions sereines et solides et je garantis la fiabilité et la rapidité des configurations d'hébergement.
