Pourquoi une faible utilisation moyenne peut-elle masquer un serveur domestique très sollicité ?

Une faible utilisation moyenne peut masquer un serveur domestique occupé car une moyenne compresse le temps, les cœurs CPU, les processus et les types de ressources en un petit ensemble de chiffres. Un serveur peut passer la majeure partie d'une minute inactif et pourtant suspendre chaque requête interactive pendant une courte rafale de cinq secondes.

Le même décalage apparaît lorsqu'un cœur est saturé, que des tâches attendent sur le stockage, que des threads sont bloqués sur un verrou, que la récupération mémoire bloque les allocations, ou qu'une petite fraction des requêtes subit une latence très élevée. La machine semble occupée lorsque la requête critique attend, pas seulement lorsque le CPU ou la RAM affichent 100 %.

Pourquoi les longues fenêtres d'échantillonnage effacent-elles les périodes courtes d'activité ?

Les systèmes de surveillance font souvent la moyenne des compteurs de ressources sur quinze secondes, une minute ou plus. les fenêtres d'échantillonnage longues masquent les pics courts de CPU car une période brève à pleine capacité devient un nombre modéré une fois combinée à une période d'inactivité plus longue.

Un serveur à 100 % de CPU pendant six secondes et presque inactif pendant les cinquante-quatre secondes restantes peut afficher une faible moyenne sur une minute. Une requête web arrivant pendant ces six secondes subit la file d'attente complète, pas le temps d'inactivité ultérieur qui dilue le graphique.

Le sous-échantillonnage amplifie cet effet. Une métrique haute résolution peut capturer le pic, tandis qu'un tableau de bord horaire ne stocke que la moyenne, le minimum et le maximum, voire un seul point moyen.

Comment un cœur peut-il être saturé alors que l'utilisation totale du CPU semble faible ?

L'utilisation totale du processeur fait la moyenne de l'activité sur tous les processeurs logiques, mais l'utilisation du CPU peut masquer une exécution bloquée. Une application mono-thread ou une file d'attente noyau très sollicitée peut atteindre sa limite tandis que les autres cœurs restent inactifs.

Sur un système à huit cœurs, un cœur entièrement occupé peut apparaître comme environ un huitième de la capacité totale du processeur. Si un écrivain de base de données, une boucle d'événements, un thread de compression ou un chemin softirq dépend de ce cœur, ajouter des cœurs inactifs ne raccourcit pas l'étape sérialisée.

La fréquence, la limitation thermique, l'hyper-threading, la migration du planificateur et les blocages mémoire modifient également la quantité de travail représentée par un point de pourcentage. L'utilisation par cœur et le travail accompli sont plus informatifs qu'un seul chiffre global pour l'hôte.

Pourquoi le processeur peut-il sembler inactif alors que les applications attendent le stockage ?

La charge Linux n'est pas simplement un pourcentage de CPU. la moyenne de charge inclut les tâches en attente d'E/S, donc les threads bloqués sur des disques, systèmes de fichiers réseau ou contrôleurs de stockage peuvent donner l'impression que le système est bloqué.

Le processeur peut être disponible, mais l'application ne peut pas continuer tant qu'une lecture, un engagement de journal, une vidange de base de données, une opération de métadonnées ou une réponse de stockage réseau n'est pas terminée. Le temps d'inactivité du CPU est donc une conséquence du goulot d'étranglement, pas la preuve que la requête dispose de suffisamment de ressources.

Vérifiez la latence des périphériques, la profondeur des files d'attente, l'attente d'E/S, les tâches bloquées, le comportement du système de fichiers et le RTT du stockage réseau. Une faible valeur en Mo/s n'exclut pas la saturation lorsque la charge consiste en de nombreuses petites opérations synchrones.

Comment les verrous, pools et files d'attente créent-ils du travail sans forte utilisation CPU ?

Des threads peuvent être présents et des requêtes actives sans consommer de CPU car ils attendent un état partagé. la contention des verrous peut augmenter la latence sans pic de CPU lorsqu'une transaction empêche d'autres opérations de progresser.

Les pools de connexions, verrous de fichiers, transactions de base de données, files d'attente de travailleurs, arriérés de sockets et sémaphores d'application ont tous une concurrence limitée. Un pool avec tous les emplacements occupés est saturé même si les tâches occupant ces emplacements attendent elles-mêmes.

C'est pourquoi la longueur de la file d'attente et le temps d'attente sont importants. L'utilisation décrit la ressource en train de travailler ; la saturation décrit une demande qui ne peut pas commencer ou se terminer immédiatement.

Pourquoi la pression mémoire peut-elle bloquer les applications avant que la RAM ne semble épuisée ?

Un conteneur peut avoir de la mémoire libre dans sa propre limite alors que l'hôte est déjà sous pression. la récupération directe de mémoire peut bloquer les threads d'application lorsque le noyau doit libérer des pages avant de satisfaire une nouvelle allocation.

Un tableau de bord peut ne montrer aucun événement de mémoire insuffisante alors que les threads de requête entrent en récupération, attendent l'écriture des pages sales, provoquent des défauts sur des pages récemment évincées ou reconstruisent un ensemble de travail supprimé par une autre charge.

Mesurez la pression mémoire, les défauts de page majeurs, l'activité de swap, le temps de récupération, l'écriture des pages sales et les refauts de cache. La question importante est de savoir si les tâches sont bloquées par la mémoire, et non si la barre de mémoire utilisée semble pleine visuellement.

Quelles métriques révèlent l'état caché d'occupation ?

Les utilisateurs subissent les requêtes lentes à l'extrémité de la distribution, donc la latence moyenne peut masquer les requêtes les plus lentes. Suivez les percentiles, les maximums et les traces au niveau des requêtes plutôt que seulement le temps de réponse moyen.

Combinez le CPU par cœur à haute résolution, les files d'attente d'exécution, la latence E/S, les tâches bloquées, les informations de pression et de blocage, la récupération de mémoire, l'occupation du pool de connexions, les attentes de verrou et la latence p95 ou p99 de l'application. Alignez-les sur la même chronologie pour tracer un chemin d'attente à travers les couches.

les connexions courtes répètent un travail de configuration fixe. Mesurez le travail accompli et le temps d'attente pendant le moment lent ; une moyenne calme à long terme ne peut pas expliquer quelle ressource a empêché cette requête de progresser.

FAQ

La charge moyenne Linux est-elle la même chose que l'utilisation du CPU ?

Non. La charge moyenne inclut les tâches exécutables et les tâches en sommeil non interruptible, ce qui inclut souvent les threads en attente d'E/S.

Un CPU total à 20 % peut-il signifier un goulot d'étranglement CPU ?

Oui. Un cœur, un thread ou un chemin noyau sérialisé peut être saturé tandis que les autres cœurs restent majoritairement inactifs.

Pourquoi le serveur semble-t-il lent après la disparition du pic ?

Les files d'attente peuvent encore se vider, les caches peuvent nécessiter un réchauffement, les données modifiées peuvent encore être en cours d'écriture, ou des tentatives peuvent s'être accumulées pendant le blocage initial.

Quelle métrique unique devrait remplacer l'utilisation du CPU ?

Aucune métrique unique ne suffit. Associez l'utilisation aux signaux de saturation et de latence pour le CPU, la mémoire, le stockage, le réseau et le chemin de requête de l'application elle-même.

Conclusion finale

Une moyenne basse ne prouve pas qu'un serveur domestique dispose immédiatement de capacité. L'agrégation temporelle peut effacer les pics, le total du CPU peut masquer un cœur surchargé, les processeurs inactifs peuvent attendre le stockage, et les verrous ou la récupération de mémoire peuvent bloquer les requêtes sans qu'une barre d'utilisation dramatique n'apparaisse. Des métriques de saturation à haute résolution et la latence en queue révèlent si le travail critique pouvait réellement progresser lorsque le serveur semblait occupé.