{"id":16221,"date":"2025-12-25T15:05:47","date_gmt":"2025-12-25T14:05:47","guid":{"rendered":"https:\/\/webhosting.de\/load-average-interpretieren-hosting-missverstaendnisse-serveropti\/"},"modified":"2025-12-25T15:05:47","modified_gmt":"2025-12-25T14:05:47","slug":"interpreter-la-charge-moyenne-hebergement-malentendus-serveropti","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/load-average-interpretieren-hosting-missverstaendnisse-serveropti\/","title":{"rendered":"Interpr\u00e9ter correctement la charge moyenne : malentendus dans l'h\u00e9bergement"},"content":{"rendered":"<p><strong>Charge moyenne<\/strong> indique le nombre de processus en cours d'ex\u00e9cution ou en attente de temps CPU, et non le pourcentage d'utilisation du CPU. Ceux qui lisent cette valeur hors contexte r\u00e9agissent souvent avec panique ou proc\u00e8dent \u00e0 des mises \u00e0 niveau inappropri\u00e9es. Je vais vous expliquer comment l'interpr\u00e9ter correctement et en tirer des conclusions utiles pour l'h\u00e9bergement.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Pas de CPU%<\/strong>: Load compte les processus dans la file d'attente d'ex\u00e9cution.<\/li>\n  <li><strong>Par noyau<\/strong> Pensez : divisez la charge par le nombre de noyaux.<\/li>\n  <li><strong>Attente E\/S<\/strong> souvent plus sollicit\u00e9 que le CPU.<\/li>\n  <li><strong>1\/5\/15<\/strong>-Les moyennes sur plusieurs minutes lissent les pics.<\/li>\n  <li><strong>Contexte<\/strong> Avant les mesures : heure, emplois, trafic.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/loadaverage-serverraum-7683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ce que mesure r\u00e9ellement la charge moyenne<\/h2>\n\n<p>Je lis la valeur comme le nombre moyen de <strong>Processus<\/strong>, qui sont actifs pendant 1, 5 et 15 minutes ou qui attendent dans la file d'attente d'ex\u00e9cution. Beaucoup le confondent avec la charge CPU en pourcentage, mais le compteur ne conna\u00eet que les files d'attente, pas le temps de calcul. Une charge de 1,0 signifie une utilisation maximale permanente sur un syst\u00e8me \u00e0 un seul c\u0153ur, tandis que la m\u00eame valeur reste mod\u00e9r\u00e9e sur quatre c\u0153urs. Je compare donc toujours la charge par rapport \u00e0 la <strong>chiffre cl\u00e9<\/strong> et n'\u00e9value ensuite que s'il s'agit d'une v\u00e9ritable surcharge. La moyenne sur 15 minutes montre les tendances et m'aide \u00e0 distinguer les pics \u00e9ph\u00e9m\u00e8res des charges persistantes.<\/p>\n\n<h2>Pourquoi les valeurs \u00e9lev\u00e9es indiquent souvent des probl\u00e8mes d'E\/S<\/h2>\n\n<p>Une charge \u00e9lev\u00e9e peut survenir m\u00eame si le CPU fonctionne \u00e0 peine \u2013 les files d'attente d'E\/S bloquent alors <strong>Fils de discussion<\/strong>. Je v\u00e9rifie 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\u00e9side dans des bases de donn\u00e9es lentes, des t\u00e2ches de sauvegarde ou des lecteurs r\u00e9seau surcharg\u00e9s. Si %wa augmente, une mise \u00e0 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\u00e9taill\u00e9es \u00e0 ce sujet. <a href=\"https:\/\/webhosting.de\/fr\/comprendre-lattente-de-s-resoudre-le-goulot-detranglement-de-la-memoire-optimisation\/\">Comprendre l'attente E\/S<\/a>, que je consulte lorsque les d\u00e9lais d'attente sont trop longs.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/loadaveragemeeting5937.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Id\u00e9e fausse : la charge correspond \u00e0 l'utilisation du processeur<\/h2>\n\n<p>Je fais une distinction stricte entre les pourcentages de la <strong>CPU<\/strong> et la charge moyenne comme m\u00e9trique de file d'attente. Une charge de 8 sur un serveur \u00e0 8 c\u0153urs peut \u00eatre normale si tous les c\u0153urs fonctionnent et qu'il n'y a pas d'attente. La situation devient critique lorsque la charge est nettement sup\u00e9rieure au nombre de c\u0153urs et que la courbe sur 15 minutes augmente simultan\u00e9ment. Pour voir les corr\u00e9lations, je place c\u00f4te \u00e0 c\u00f4te 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\u00e2ches de courte dur\u00e9e.<\/p>\n\n<h2>Classer correctement les pointes au lieu de donner l'alerte<\/h2>\n\n<p>Les pics de charge courts dus \u00e0 Cron, \u00e0 la rotation des journaux ou aux sauvegardes font partie du quotidien et ne signifient pas automatiquement <strong>D\u00e9rangement<\/strong>. J'\u00e9value toujours l'heure, la dur\u00e9e et la ligne des 15 minutes avant de d\u00e9clencher des alarmes ou d'ajouter de la capacit\u00e9. Je calibre les seuils avec le nombre de c\u0153urs, par exemple, alarme uniquement lorsque la charge est sup\u00e9rieure \u00e0 2\u00d7 c\u0153urs pendant plusieurs minutes. Je v\u00e9rifie \u00e9galement les pics irr\u00e9guliers dans les syst\u00e8mes de gestion de contenu pour les t\u00e2ches en arri\u00e8re-plan ; pour WordPress, la remarque suivante s'applique <a href=\"https:\/\/webhosting.de\/fr\/charge-cpu-irreguliere-wordpress-cronjobs-stabilite\/\">T\u00e2ches cron WP et charge<\/a>. Je pr\u00e9viens ainsi les r\u00e9actions irr\u00e9fl\u00e9chies et privil\u00e9gie les mesures utiles.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/load-average-hosting-fehler-4831.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lire la charge moyenne dans le quotidien de l'h\u00e9bergement<\/h2>\n\n<p>Je d\u00e9marre avec uptime pour un aper\u00e7u rapide, puis j'ouvre <strong>htop<\/strong>, pour voir les processus, la r\u00e9partition du CPU, la RAM et les E\/S. Si la charge sur 15 minutes reste \u00e9lev\u00e9e, je recherche les coupables \u00e0 l'aide d'iotop ou de pidstat. Pour les charges de travail li\u00e9es aux bases de donn\u00e9es, je v\u00e9rifie les latences des requ\u00eates, les index et les hits du cache. Sur les serveurs web, je v\u00e9rifie si trop de workers PHP simultan\u00e9s sont en attente ou si, le cas \u00e9ch\u00e9ant, l'OpCache intervient. Cette routine permet de distinguer les sympt\u00f4mes des causes et m'\u00e9vite des mises \u00e0 niveau mat\u00e9rielles co\u00fbteuses et inefficaces.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e9triques<\/th>\n      <th>Vie quotidienne<\/th>\n      <th>Signal d'alarme (4 noyaux)<\/th>\n      <th>Prochaine \u00e9tape<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Chargement 1 min<\/td>\n      <td><strong>&lt;4<\/strong><\/td>\n      <td>&gt;8 pendant 3 \u00e0 5 minutes<\/td>\n      <td>V\u00e9rifier les processus prioritaires<\/td>\n    <\/tr>\n    <tr>\n      <td>Charge 15 min<\/td>\n      <td><strong>&lt;3<\/strong><\/td>\n      <td>&gt;6 en augmentation<\/td>\n      <td>Planifier la capacit\u00e9\/l'architecture<\/td>\n    <\/tr>\n    <tr>\n      <td>CPU%<\/td>\n      <td><strong>&lt;80%<\/strong><\/td>\n      <td>&gt;95% permanent<\/td>\n      <td>Optimiser le code\/les travailleurs<\/td>\n    <\/tr>\n    <tr>\n      <td>Attente E\/S<\/td>\n      <td><strong>&lt;10%<\/strong><\/td>\n      <td>&gt;20% Pointes<\/td>\n      <td>V\u00e9rifier le stockage\/la mise en cache<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Outils pour une surveillance propre de l'h\u00e9bergement<\/h2>\n\n<p>Je combine <strong>M\u00e9triques<\/strong> \u00e0 partir d'agents avec des journaux et des traces afin de trouver plus rapidement les causes. Pour les s\u00e9ries chronologiques, j'utilise Prometheus ou d'autres collecteurs, visualis\u00e9s dans Grafana. Sur le plan infrastructurel, Zabbix m'aide pour les v\u00e9rifications et les r\u00e8gles 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\u00e9seau. Sans chronologie commune, l'interpr\u00e9tation des valeurs de charge reste fragmentaire.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Cat\u00e9gorie<\/th>\n      <th>Exemple<\/th>\n      <th>Points forts<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Open-Source<\/td>\n      <td><strong>Zabbix<\/strong><\/td>\n      <td>Contr\u00f4les, agent, logique d'alarme<\/td>\n    <\/tr>\n    <tr>\n      <td>S\u00e9rie chronologique<\/td>\n      <td><strong>Prometheus<\/strong><\/td>\n      <td>Mod\u00e8le Pull, PromQL<\/td>\n    <\/tr>\n    <tr>\n      <td>visualisation<\/td>\n      <td><strong>Grafana<\/strong><\/td>\n      <td>Tableaux de bord, alertes<\/td>\n    <\/tr>\n    <tr>\n      <td>SaaS<\/td>\n      <td><strong>Datadog<\/strong><\/td>\n      <td>Int\u00e9grations, APM<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/loadaveragehosting2347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimisation en cas de charge \u00e9lev\u00e9e permanente<\/h2>\n\n<p>Je commence par la douleur la plus intense : la lenteur. <strong>Requ\u00eates<\/strong>, des chemins d'E\/S bloquants ou un trop grand nombre de travailleurs simultan\u00e9s. Les index de base de donn\u00e9es, les pools de connexions et les caches de requ\u00eates tels que Redis ou Memcached r\u00e9duisent consid\u00e9rablement 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\u00e8me, je r\u00e8gle vm.swappiness de mani\u00e8re appropri\u00e9e, je v\u00e9rifie les pages volumineuses et je fixe des limites raisonnables pour les services. Ce n'est que lorsque les possibilit\u00e9s logicielles sont \u00e9puis\u00e9es que je proc\u00e8de \u00e0 une mise \u00e0 l'\u00e9chelle verticale (plus de RAM\/CPU) ou horizontale (plus d'instances avec \u00e9quilibreur de charge).<\/p>\n\n<h2>Charge moyenne sur les syst\u00e8mes multic\u0153urs<\/h2>\n\n<p>Je calcule toujours la charge par rapport \u00e0 <strong>Noyaux<\/strong>: Load 16 peut \u00eatre acceptable sur 16 c\u0153urs physiques. L'hyper-threading double le nombre de processeurs logiques, mais les performances r\u00e9elles ne suivent pas toujours une courbe lin\u00e9aire ; j'\u00e9value donc \u00e9galement 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 \u201e normales \u201c. Un coup d'\u0153il au throttling du CPU et aux temps d'attente du planificateur permet de distinguer les limites strictes des v\u00e9ritables probl\u00e8mes de capacit\u00e9. Pour prendre des d\u00e9cisions claires, je m'appuie sur la courbe de 15 minutes comme r\u00e9f\u00e9rence de tendance.<\/p>\n\n<h2>H\u00e9bergement mutualis\u00e9, voisins et goulots d'\u00e9tranglement cach\u00e9s<\/h2>\n\n<p>Dans les environnements partag\u00e9s, l'influence de <strong>voisins<\/strong> souvent plus forte que celle de ma propre application. C'est pourquoi j'observe \u00e9galement le CPU-Steal, les temps de disponibilit\u00e9 et les conflits de stockage afin de d\u00e9tecter les charges externes. Si des c\u0153urs sont \u201e vol\u00e9s \u201c, la charge continue d'augmenter malgr\u00e9 mes propres optimisations. Pour prendre ma d\u00e9cision, je me base sur le guide suivant <a href=\"https:\/\/webhosting.de\/fr\/temps-vole-au-processeur-hebergement-virtuel-voisin-bruyant-perfboost\/\">Temps d'utilisation du processeur<\/a> et planifie des ressources d\u00e9di\u00e9es si n\u00e9cessaire. Je garantis ainsi des performances pr\u00e9visibles au lieu de rester bloqu\u00e9 dans un goulot d'\u00e9tranglement.<\/p>\n\n<h2>D\u00e9finir correctement les tendances, les seuils et les alertes<\/h2>\n\n<p>Je calibre les seuils par <strong>Noyau<\/strong> et je d\u00e9finis une hyst\u00e9r\u00e9sis afin que les alarmes ne se d\u00e9clenchent pas \u00e0 chaque pic. Pour 4 c\u0153urs, je commence par des alarmes \u00e0 partir d'une charge &gt; 8 pendant plusieurs minutes et je confirme avec une tendance sur 15 minutes. J'exclus les fen\u00eatres de maintenance et les temps de traitement par lots de l'\u00e9valuation afin que les graphiques ne donnent pas une image fauss\u00e9e de la situation. De plus, j'utilise la d\u00e9tection des anomalies par rapport \u00e0 la m\u00e9diane historique propre \u00e0 l'entreprise, au lieu de perp\u00e9tuer des valeurs fixes rigides. Cela me permet de r\u00e9agir rapidement aux changements r\u00e9els sans fatiguer l'\u00e9quipe avec de fausses alertes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/serveranalyse-hosting-7482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment Linux compte r\u00e9ellement la charge<\/h2>\n\n<p>Si n\u00e9cessaire, je jette un \u0153il sous le capot : le noyau calcule la longueur moyenne de la file d'attente d'ex\u00e9cution et compte non seulement les threads actifs (\u00e9tat \u201e R \u201c), mais aussi ceux en <strong>sommeil ininterrompu<\/strong> (\u201e D \u201c, g\u00e9n\u00e9ralement \u00e9tat d'attente E\/S). C'est pr\u00e9cis\u00e9ment ce qui explique les valeurs de charge \u00e9lev\u00e9es pour une faible utilisation du processeur : de nombreux threads bloquent le noyau sur des disques lents, des acc\u00e8s r\u00e9seau ou NFS. Dans <code>\/proc\/loadavg<\/code> Je vois les trois moyennes, ainsi que les threads \u201e en cours\/totaux \u201c et le dernier PID. Les zombies ne jouent aucun r\u00f4le ici, mais les threads du noyau et les threads utilisateur sont pris en compte de mani\u00e8re \u00e9gale. Sur les syst\u00e8mes comportant de nombreuses t\u00e2ches de courte dur\u00e9e (builds, workers), la valeur sur 1 minute varie naturellement davantage, tandis que la valeur sur 15 minutes reste mon rep\u00e8re de stabilit\u00e9.<\/p>\n\n<p>Pour moi, il est important de traduire \u201e charge \u201c par \u201e temps d'attente \u201c : si la charge est nettement sup\u00e9rieure au nombre central, des files d'attente se forment. Cela n'est pas n\u00e9cessairement mauvais s'il s'agit de t\u00e2ches de courte dur\u00e9e, mais si la latence des requ\u00eates augmente en m\u00eame temps, le syst\u00e8me bascule en surcharge. C'est pourquoi je consid\u00e8re toujours la charge en relation avec <strong>Dur\u00e9e de validit\u00e9<\/strong>(Req-Latency, ttfb) afin d'\u00e9valuer les files d'attente non seulement en termes de chiffres, mais aussi en termes d'impact.<\/p>\n\n<h2>Pression m\u00e9moire, swap et blocages cach\u00e9s<\/h2>\n\n<p>Je constate souvent des valeurs de charge \u00e9lev\u00e9es constantes dans les cas suivants <strong>pression de stockage<\/strong>. Lorsque le cache de page diminue ou que kswapd d\u00e9place des pages, les processus se retrouvent en attente. Le swapping g\u00e9n\u00e8re des E\/S et ralentit tout. Je v\u00e9rifie <code>vmstat<\/code> (si\/so), erreurs de page majeures, <code>\/proc\/meminfo<\/code> (Cached, Dirty, Writeback) et observez si les latences d'E\/S augmentent simultan\u00e9ment. Une charge \u00e9lev\u00e9e avec un CPU% mod\u00e9r\u00e9 et un \u201e await \u201c disque croissant est pour moi un signe clair : il manque de la RAM ou l'ensemble de donn\u00e9es ne tient pas dans le cache.<\/p>\n\n<p>Je r\u00e9agis par \u00e9tapes : d'abord, j'identifie les points chauds de la RAM (par exemple, les tris volumineux, les requ\u00eates non mises en cache, les tableaux PHP gigantesques), puis je renforce les caches et <strong>vm.swappiness<\/strong> de mani\u00e8re \u00e0 ce que la m\u00e9moire vive ne soit pas \u00e9vinc\u00e9e trop t\u00f4t. Il est rarement judicieux de d\u00e9sactiver compl\u00e8tement le swap : un swap petit et rapide (NVMe) utilis\u00e9 de mani\u00e8re disciplin\u00e9e permet d'\u00e9viter les pics OOM Killer. Si les \u00e9critures diff\u00e9r\u00e9es deviennent un goulot d'\u00e9tranglement, j'att\u00e9nue les vagues de synchronisation (traitement par lots, options de journalisation, vidages asynchrones) et je r\u00e9duis le nombre d'\u00e9critures simultan\u00e9es.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/loadaveragedevdesk4892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Conteneurs, cgroups et limitation du CPU<\/h2>\n\n<p>Dans Containers, j'interpr\u00e8te Load en tenant compte de <strong>cgroups<\/strong>. Les quotas CFS limitent le temps CPU par p\u00e9riode ; lorsque la limite est atteinte, le conteneur continue d'afficher des valeurs de charge \u00e9lev\u00e9es, m\u00eame s'il est simplement <em>r\u00e9duit<\/em> Je v\u00e9rifie. <code>cpu.max<\/code> (cgroup v2) ou. <code>cfs_quota_us<\/code>\/<code>cfs_period_us<\/code> (v1) et le compteur d'acc\u00e9l\u00e9ration (<code>cpu.stat<\/code>). Si \u201e throttled_time \u201c augmente, cela n'est pas d\u00fb \u00e0 un manque de puissance de calcul, mais \u00e0 des limites strictes. Dans Kubernetes, je fais une distinction stricte entre les \u201e requ\u00eates \u201c (planification) et les \u201e limites \u201c (restriction) : des limites mal d\u00e9finies g\u00e9n\u00e8rent des files d'attente artificielles.<\/p>\n\n<p>L'affinit\u00e9 CPU et NUMA influencent \u00e9galement le r\u00e9sultat : si les threads sont \u00e9pingl\u00e9s sur quelques c\u0153urs ou plac\u00e9s sur un n\u0153ud NUMA, la charge peut s'accumuler localement, tandis que le CPU% global semble correct. Je r\u00e9partis les threads chauds de mani\u00e8re cibl\u00e9e, je v\u00e9rifie l'\u00e9quilibrage IRQ et je veille \u00e0 ce que les conteneurs ne soient pas tous concentr\u00e9s sur les m\u00eames c\u0153urs physiques. Je r\u00e9duis ainsi les temps d'attente sans avoir \u00e0 mettre \u00e0 niveau le mat\u00e9riel.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/serveranalyse-hosting-7482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Liste de contr\u00f4le pour une prise de d\u00e9cision rapide<\/h2>\n\n<ul>\n  <li>Charge relative \u00e0 <strong>Noyaux<\/strong> \u00e9valuer (charge\/c\u0153urs \u2248 1 bon, \u226b1 critique).<\/li>\n  <li><strong>CPU%<\/strong> et <strong>Attente E\/S<\/strong> Opposer : la caisse calcule-t-elle ou attend-elle ?<\/li>\n  <li><strong>15 minutes<\/strong>V\u00e9rifier la tendance : surcharge prolong\u00e9e ou pic bref.<\/li>\n  <li><strong>Processus de pointe<\/strong> et States (R\/D\/S\/Z) ; nombreux D-States = goulot d'\u00e9tranglement E\/S.<\/li>\n  <li><strong>Latences du disque<\/strong>, Mesurer la profondeur de la file d'attente et %util ; v\u00e9rifier \u00e9galement les chemins d'acc\u00e8s NFS\/r\u00e9seau.<\/li>\n  <li><strong>RAM<\/strong>: Erreurs de page, activit\u00e9 de swap, kswapd \u2013 R\u00e9duire la pression sur la m\u00e9moire.<\/li>\n  <li><strong>Limites<\/strong> V\u00e9rifier dans les conteneurs\/VM : quotas, partages, vol, limitation.<\/li>\n  <li><strong>Concurrence<\/strong> limiter : travailleurs\/threads, files d'attente, contre-pression.<\/li>\n  <li><strong>Pointes temporelles<\/strong> D\u00e9placer : Cron, sauvegardes, index, ETL.<\/li>\n  <li><strong>r\u00e9ajustement<\/strong>, puis mesurez \u00e0 nouveau \u2013 l'effet avant le mat\u00e9riel.<\/li>\n<\/ul>\n\n<h2>Exemples concrets de tuning dans le domaine de l'h\u00e9bergement<\/h2>\n\n<p>Sur les piles Web\/PHP, <strong>Concurrence<\/strong> le plus grand levier. Je mise sur PHP\u2011FPM de mani\u00e8re r\u00e9aliste <code>pm.max_children<\/code>, afin que les requ\u00eates ne saturent pas la base de donn\u00e9es en parall\u00e8le. Dans nginx ou Apache, je limite les connexions amont simultan\u00e9es, j'active Keep-Alive de mani\u00e8re judicieuse et je laisse les ressources statiques se mettre en cache de mani\u00e8re agressive. L'OpCache emp\u00eache les temp\u00eates de pr\u00e9chauffage, tandis qu'un cache d'objets (Redis\/Memcached) r\u00e9duit consid\u00e9rablement la charge des requ\u00eates.<\/p>\n\n<p>Pour les bases de donn\u00e9es, je commence par <strong>Indexation<\/strong> et plans. Au lieu d'augmenter aveugl\u00e9ment les connexions, j'utilise des pools de connexions et limite les requ\u00eates simultan\u00e9es co\u00fbteuses. Je surveille les taux d'acc\u00e8s au pool de tampons, les temps d'attente de verrouillage et les d\u00e9bordements de tables temporaires. Les rapports volumineux ou les t\u00e2ches de migration s'ex\u00e9cutent de mani\u00e8re asynchrone et par lots \u2013 je pr\u00e9f\u00e8re une charge constante de 60% \u00e0 5 minutes de 200% suivies d'un arr\u00eat complet.<\/p>\n\n<p>Pour les runners gourmands en m\u00e9moire (par exemple, le traitement d'images\/vid\u00e9os), je d\u00e9finis une limite maximale de t\u00e2ches simultan\u00e9es par h\u00f4te. Je d\u00e9finis <code>sympa<\/code> et <code>ionice<\/code>, afin que les processus par lots ne perturbent pas les latences interactives. Sur les disques NVMe rapides, je veille \u00e0 ce que la configuration du planificateur reste l\u00e9g\u00e8re, \u00e0 ce que la profondeur de la file d'attente soit suffisante et \u00e0 \u00e9viter les synchronisations bavardes. Ainsi, les avalanches D-State disparaissent et la charge diminue sans que CPU% n'augmente : la machine attend tout simplement moins.<\/p>\n\n<h2>Ex\u00e9cuter les charges de travail de compilation et de traitement par lots de mani\u00e8re planifi\u00e9e<\/h2>\n\n<p>Lors de la compilation ou du rendu, la charge est fortement corr\u00e9l\u00e9e \u00e0 la <strong>Parall\u00e9lisme des t\u00e2ches<\/strong>. Je choisis <code>-j<\/code> Conscient : les noyaux \u00d7 (0,8\u20131,2) constituent un bon d\u00e9but, mais je me r\u00e9f\u00e8re \u00e0 <strong>RAM<\/strong> Il vaut mieux avoir moins de t\u00e2ches parall\u00e8les stables que des pics de charge importants. Les caches d'artefacts, les compilations incr\u00e9mentielles et les volumes d'E\/S d\u00e9di\u00e9s emp\u00eachent les \u00e9tats D de saturer la file d'attente avec de nombreux petits fichiers.<\/p>\n\n<p>Je planifie les fen\u00eatres batch avec une faible charge. Les rotations, les sauvegardes, les ETL et les r\u00e9indexations s'ex\u00e9cutent de mani\u00e8re \u00e9chelonn\u00e9e, et non pas toutes \u00e0 l'heure pile. Les files d'attente de travail sont soumises \u00e0 une contre-pression : seuls les nouveaux travaux sont trait\u00e9s lorsque des emplacements sont disponibles, au lieu d'un simple \u201e fire-and-forget \u201c. Cela permet de contr\u00f4ler la charge et les latences, et de rendre les pics pr\u00e9visibles.<\/p>\n\n<h2>PSI : Pressure Stall Information, un syst\u00e8me d'alerte pr\u00e9coce<\/h2>\n\n<p>En plus du Load classique, j'utilise le <strong>Informations sur le d\u00e9crochage par perte de pression<\/strong> (PSI) de Linux dans <code>\/proc\/pressure\/cpu<\/code>, <code>...\/io<\/code> et <code>...\/m\u00e9moire<\/code>. PSI indique la dur\u00e9e des t\u00e2ches <em>collectivement<\/em> ont d\u00fb attendre \u2013 id\u00e9al pour \u00e9viter la surcharge <em>t\u00f4t<\/em> Si la pression CPU augmente pendant plusieurs minutes alors que CPU% est mod\u00e9r\u00e9, je sais que la file d'attente d'ex\u00e9cution est encombr\u00e9e. La pression E\/S me permet de voir si les latences de stockage ont un impact sur l'ensemble du syst\u00e8me, m\u00eame si les valeurs iotop individuelles semblent inoffensives.<\/p>\n\n<p>Je combine le PSI avec la charge sur 15 minutes : si les deux augmentent, la saturation est r\u00e9elle. Si seule la charge augmente, mais que le PSI reste stable, il est possible que de nombreuses t\u00e2ches courtes soient en cours d'ex\u00e9cution, sans que les utilisateurs ne s'en aper\u00e7oivent. Il en r\u00e9sulte des alertes plus claires et de meilleures d\u00e9cisions : augmenter les limites, r\u00e9partir les t\u00e2ches ou renforcer le mat\u00e9riel de mani\u00e8re cibl\u00e9e l\u00e0 o\u00f9 des goulots d'\u00e9tranglement sont mesurables.<\/p>\n\n<h2>Bref aper\u00e7u \u00e0 emporter<\/h2>\n\n<p>Je lis le <strong>Charge<\/strong> Jamais isol\u00e9es, mais dans le contexte des c\u0153urs, de l'attente E\/S, du CPU% et de la courbe de 15 minutes. Je n'interpr\u00e8te les valeurs \u00e9lev\u00e9es qu'apr\u00e8s avoir examin\u00e9 les latences de stockage et de r\u00e9seau, car c'est souvent l\u00e0 que se trouve le v\u00e9ritable frein. Pour les mesures \u00e0 prendre, je donne la priorit\u00e9 aux leviers visibles : requ\u00eates, mise en cache, travailleurs, limites, puis seulement ensuite le mat\u00e9riel. Dans les environnements partag\u00e9s, je v\u00e9rifie les effets parasites tels que le vol et, si n\u00e9cessaire, je planifie des ressources d\u00e9di\u00e9es. Gr\u00e2ce \u00e0 ces r\u00e8gles, je prends des d\u00e9cisions sereines et solides et je garantis la fiabilit\u00e9 et la rapidit\u00e9 des configurations d'h\u00e9bergement.<\/p>","protected":false},"excerpt":{"rendered":"<p>**Interpr\u00e9ter correctement la charge moyenne** : id\u00e9es re\u00e7ues courantes dans le domaine de l'h\u00e9bergement et comment apprendre \u00e0 **comprendre la charge du serveur** gr\u00e2ce \u00e0 la **surveillance de l'h\u00e9bergement**.<\/p>","protected":false},"author":1,"featured_media":16214,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-16221","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2746","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Load Average","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"16214","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16221","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=16221"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16221\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16214"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16221"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16221"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16221"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}