Vous l’avez déjà vu en production : un service « devrait » supporter la charge, les tableaux de bord ont l’air corrects, et pourtant la latence p99 dérive dans le mauvais sens.
Quelqu’un prononce la sentence maudite : « Il nous faut juste des CPU plus rapides. » Une autre personne répond : « Les fréquences n’ont plus d’importance. »
Les deux ont tort de manières qui coûtent de l’argent.
La course aux fréquences revient — mais pas comme une compétition linéaire en GHz à coller sur une étiquette.
Elle réapparaît sous forme de clocks en rafale, d’opportunisme par cœur, de fréquence de fabric, des timings mémoire, du comportement des liens PCIe, et de noyaux d’accélérateurs
qui tournent à leur propre rythme. La partie douloureuse : vous ne pouvez pas acheter votre sortie à moins de nommer le véritable goulot.
Ce que « la course aux fréquences » signifie en 2026
Au début des années 2000, l’histoire était assez simple pour être mise sur un panneau publicitaire : plus de GHz, ordinateur plus rapide.
Puis la physique est arrivée à la réunion, a pris le marqueur et a écrit densité de puissance sur le tableau en lettres capitales.
La fréquence s’est figée. Le multicœur est arrivé. Et pendant un temps l’industrie a agi comme si les horloges étaient « résolues »,
comme si nous étions passés au parallélisme et qu’il fallait cesser de poser des questions gênantes.
Mais les systèmes en production n’ont pas cessé d’avoir des points d’étranglement mono-thread. Le noyau a toujours des verrous.
Certaines bases de données sérialisent encore du travail. Votre microservice « asynchrone » a toujours un cœur chaud qui fait le parse JSON, TLS et l’export des métriques.
Et la latence de queue vous punit quand un cœur a la malchance.
La course aux fréquences revient, mais de biais :
- La fréquence en rafale est traitée comme un budget utilisable brièvement, pas comme un état permanent.
- Le comportement par cœur compte plus que la « fréquence de base ». Votre service s’exécute sur les cœurs qu’il obtient par hasard.
- Les clocks uncore (contrôleur mémoire, interconnexion, slices LLC, fabric) peuvent dominer lorsque la charge est axée mémoire.
- Les accélérateurs (GPU/TPU/NPU) et leurs règles de boost/throttle créent leur propre « jeu GHz ».
- Les fréquences système sont négociées : limites thermiques, plafonds d’alimentation, firmware et ordonnanceurs négocient la fréquence.
Si vous exploitez des systèmes réels, vous vous fichez que le chiffre GHz soit « de retour ».
Vous vous souciez de savoir si les cœurs qui traitent votre chemin critique peuvent soutenir une fréquence effective élevée quand ça compte,
pendant que le sous-système mémoire suit et que le chemin I/O n’injecte pas de pics de latence.
Huit faits et contexte historique utiles
Ce ne sont pas des anecdotes de quiz. Ils changent la façon dont vous diagnostiquez et ce que vous achetez.
- L’échelle de fréquence a buté en partie parce que le scaling de Dennard s’est arrêté. Vers le milieu des années 2000, la réduction des transistors n’a plus livré des réductions de puissance proportionnelles, donc des GHz plus élevés sont devenus un problème thermique.
- « Le mythe du GHz » est mort, mais la performance mono-thread n’a jamais disparu. La loi d’Amdahl continue de prélever son tribut : même de petites sections sérialisées fixent un plafond d’accélération.
- Turbo/boost a été le compromis. Plutôt que des clocks plus élevées en permanence, les CPU ont commencé à booster opportunistiquement certains cœurs lorsque la marge thermique/power le permet—exactement le comportement « ça dépend » que les SRE aiment détester.
- L’exécution spéculative est devenue un levier majeur. Les pipelines profonds et la spéculation agressive ont amélioré le débit, mais les atténuations de sécurité ont rappelé à tous que la microarchitecture est aussi une question de politique.
- L’« uncore » est devenu un facteur de première classe. Pour les charges liées à la mémoire, augmenter les GHz des cœurs peut ne rien faire si le sous-système mémoire et le fabric ne suivent pas.
- Le NUMA est passé de « niche HPC » à « chaque serveur ». Les designs multi-socket et chiplet rendent la localité critique ; votre thread le plus chaud peut être ralenti par la mémoire distante même avec une haute fréquence.
- Les générations PCIe ont changé la carte des goulots. Des liens plus rapides ont aidé, mais ont aussi exposé de nouveaux plafonds : overhead IOMMU, modulation des interrupts et chemins de drivers peuvent dominer pour de petites I/O.
- Le cloud a rendu la « fréquence » multi-tenant. Le temps volé CPU, la gestion d’énergie et les voisins bruyants signifient que vos performances observées peuvent changer sans modification du code.
La nouvelle « course GHz » : rafales, fabrics et longue traîne
Les clocks en rafale ne sont pas une promesse ; c’est une négociation
Les CPU modernes afficheront volontiers des fréquences de boost impressionnantes. Ce chiffre ne ment pas, mais ce n’est pas non plus un contrat.
Le boost dépend de :
- du nombre de cœurs actifs,
- des limites de puissance du package et des fenêtres temporelles,
- de la qualité du refroidissement et de la température d’entrée,
- du mélange de charges (les instructions vectorielles peuvent changer la consommation),
- des réglages firmware, du gouverneur OS, et parfois des politiques du fournisseur cloud.
Si vous exécutez des services sensibles à la latence, les rafales sont excellentes — jusqu’à ce que votre chemin de requête le plus chaud s’exécute pendant un plateau thermique ou sous power cap et que vous obteniez une falaise p99.
La fréquence effective bat la fréquence annoncée
La seule horloge qui compte est celle que votre thread expérimente pendant qu’il accomplit un travail utile.
« Utile » signifie faire le travail lourd. « Pas utile » signifie tourner en attente sur un verrou, bloqué sur des cache misses, ou attendre de l’I/O.
C’est pourquoi les ingénieurs performance parlent d’IPC (instructions par cycle) et de cycles par instruction et de décompositions des stalls.
Quand un cœur passe des cycles à attendre la mémoire, augmenter les GHz augmente le rythme auquel il attend. C’est une voie d’amélioration déprimante.
Uncore et mémoire : les limiteurs silencieux
En production, beaucoup de « problèmes CPU » sont en réalité des problèmes de latence mémoire. Pas de bande passante — de latence.
Bases de données, caches et meshes de services font fréquemment du pointer chasing et des recherches sur petits objets.
Ces charges sont allergiques à une latence d’accès mémoire élevée et aux sauts NUMA distants.
Votre CPU peut booster à des fréquences héroïques tandis que le chemin critique est bloqué sur la DRAM.
Vous verrez une forte utilisation CPU, un iowait élevé (si swap ou paging entre en jeu), et un débit médiocre.
La solution est rarement « augmenter la fréquence ». La solution est la localité, moins de cache miss, une meilleure disposition des données, et parfois plus de canaux mémoire ou des types d’instances différents.
Les accélérateurs sont le nouveau théâtre de la vitesse d’horloge
Les GPU et autres accélérateurs boostent et throttlent aussi, et leurs performances sont liées à la mémoire, à l’interconnect et à la forme des kernels.
Si vous avez déjà vu un GPU baisser de fréquence parce qu’un rack est devenu chaud, vous savez que le « GHz » est désormais un problème d’installation.
Voici votre première blague, courte et exacte : Acheter des CPU plus rapides pour corriger la latence p99, c’est comme acheter un détecteur de fumée plus bruyant pour éteindre un feu de cuisine.
Où la performance se goulote réellement en production
Dans les systèmes réels, les goulots se comportent comme des adultes : ils ne se signalent pas et ils bougent quand vous les regardez.
Le récit « la course aux fréquences revient » n’est utile que si vous pouvez le cartographier en classes de goulots.
1) Cœur chaud unique (et le mythe du « nous avons 64 cœurs »)
Votre service peut avoir de nombreux threads mais un point de sérialisation : un verrou global, une boucle événementielle mono-thread, une phase GC stop-the-world,
un consommateur de queue, un goulot TLS handshake, un exporteur de métriques avec un mutex, ou un client de base de données faisant une résolution DNS synchrone
(oui, ça arrive encore).
Quand un cœur est chaud, la fréquence peut compter — parce que vous êtes littéralement limité par la vitesse à laquelle ce cœur unique exécute le chemin critique.
Mais vous avez besoin de preuves, pas d’impressions.
2) Latence mémoire et localité NUMA
Si votre charge réalise des accès mémoire aléatoires, vous jouez au jeu de la latence.
Un clock core plus élevé sans meilleure localité peut produire des résultats décevants.
Sur des machines multi-socket, l’accès mémoire distant ajoute une latence mesurable. Cela se manifeste par des cycles bloqués et parfois par des pics de latence en queue lorsque les allocations dérivent.
3) Latence de stockage : le percepteur p99
Le stockage est l’endroit où les récits « fréquence » viennent mourir. Pas parce que le stockage est lent (les NVMe modernes sont rapides),
mais parce que la variabilité de latence est l’ennemi. Une médiane de 200µs et un p99 à 8ms vont ruiner votre journée.
La partie délicate : les pics de latence de stockage peuvent être causés par la garbage collection du firmware, des problèmes de profondeur de file d’attente, le journal du système de fichiers,
la contention CPU dans la couche bloc, ou juste un périphérique bruyant dans un RAID/vdev ZFS.
4) Micro-rafales réseau et mise en file
Beaucoup de tickets « régression CPU » sont en réalité des problèmes de mise en file réseau qui se manifestent par des timeouts.
Les micro-rafales peuvent remplir les buffers et introduire de la latence même quand le débit moyen semble faible.
Votre service n’a pas besoin de plus de GHz. Il a besoin de files plus petites, d’un meilleur pacing, ou d’une correction dans le chemin réseau.
5) Overhead noyau et virtualisation
Les instances cloud peuvent subir du CPU steal, du throttling, ou des voisins bruyants.
Les conteneurs peuvent être limités en CPU. Le noyau peut passer du temps en traitement softirq, en comptabilité cgroups, ou en verrous de système de fichiers.
Une fréquence de boost ne résout pas un hôte qui ne planifie simplement pas votre travail.
6) Limites de puissance et thermiques : la performance comme fonctionnalité HVAC
Si le refroidissement de votre rack est limite, votre histoire de fréquence CPU devient un ticket facilities.
Le throttling thermique ressemble souvent à une « lenteur aléatoire ». Ce n’est pas aléatoire.
Il corrèle avec la température d’entrée, les courbes de ventilateur, et combien de voisins boostent aussi.
Une citation à afficher au-dessus de votre écran, idée paraphrasée de John Gall : « Les systèmes complexes qui fonctionnent tendent à évoluer à partir de systèmes simples qui fonctionnaient. »
Mode d’emploi pour diagnostic rapide : premier, deuxième, troisième
Voici le flux de travail que j’utilise quand quelqu’un page « le service est lent » et que l’équipe dispute déjà des modèles CPU.
Le but n’est pas une compréhension parfaite. Le but est de trouver la ressource limitante rapidement, puis de valider avec un outil plus profond.
Premier : classer la douleur (latence vs débit, CPU vs attente)
- Est-ce la latence p99, ou le débit total ? La latence de queue pointe souvent vers mise en file, contention, GC, ou variance I/O.
- Le CPU est-il réellement occupé ? Un temps utilisateur CPU élevé diffère d’un temps système élevé, qui diffère d’un iowait, qui diffère d’un steal.
- Quelque chose a-t-il changé ? Déploiement, mise à jour du noyau, firmware, type d’instance, classe de stockage, power cap, comportement de l’autoscaler.
Second : trouver la file
Presque tous les problèmes de performance sont une file quelque part :
file d’exécution run queue, file disque, file NIC, file de verrou, file de pool de connexions, file GC (oui), file d’attente BD.
Identifier la file dominante, et vous avez identifié la classe de goulot.
Troisième : valider avec un outil « microscope »
- CPU :
perf, flamegraphs, stats d’ordonnanceur. - Mémoire/NUMA :
numastat,perf stat(cache misses), fautes de pages. - Disque :
iostat -x,nvme smart-log, histogrammes de latence système de fichiers si dispo. - Réseau :
ss,ethtool -S,tc, drops d’interface, retransmits.
Douze tâches pratiques : commandes, sorties, décisions
Elles sont volontairement ennuyeuses. L’ennui est bon en cas de panne. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision que vous prenez.
Task 1: Check load and run queue pressure
cr0x@server:~$ uptime
14:22:19 up 37 days, 3:11, 2 users, load average: 18.42, 17.90, 16.05
Signification : une charge moyenne bien au-dessus du nombre de cœurs (ou de ce qui est typique) suggère des tâches exécutables en file, I/O bloquées, ou les deux.
La charge inclut les tâches en sommeil I/O ininterrompable, ne supposez donc pas que c’est « charge CPU ».
Décision : Si la charge est élevée, vérifiez immédiatement vmstat (run queue vs bloquées) et iostat (files disque).
Task 2: Separate runnable vs blocked tasks
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
12 3 0 821224 92124 3928120 0 0 128 512 6200 8900 42 10 33 13 2
15 4 0 810112 92124 3929008 0 0 256 768 6400 9200 44 11 28 15 2
Signification : r est les processus exécutables ; b est bloqué (généralement I/O).
wa indique le temps d’attente sur I/O ; st indique le temps volé (contention virtualisation).
Décision : Un r élevé avec un wa faible pointe vers une contention CPU.
Un b/wa élevé pointe vers le stockage.
Un st élevé pointe vers une contention cloud/hôte — cessez de blâmer votre code tant que vous n’avez pas prouvé le contraire.
Task 3: Identify CPU frequency behavior (governor and current MHz)
cr0x@server:~$ grep -E 'model name|cpu MHz' /proc/cpuinfo | head -n 8
model name : Intel(R) Xeon(R) CPU
cpu MHz : 1799.998
model name : Intel(R) Xeon(R) CPU
cpu MHz : 3600.123
model name : Intel(R) Xeon(R) CPU
cpu MHz : 3599.876
model name : Intel(R) Xeon(R) CPU
cpu MHz : 1800.045
Signification : des MHz mixtes suggèrent que certains cœurs boostent tandis que d’autres sont parkés ou throttlés.
C’est normal. La question est de savoir si vos threads chauds s’exécutent de façon cohérente sur les cœurs rapides.
Décision : Si la latence critique corrèle avec des MHz plus bas sur des cœurs chargés, investiguez les limites power/thermiques et les réglages du gouverneur CPU.
Task 4: Confirm CPU governor (and set expectations)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Signification : powersave peut convenir aux ordinateurs portables ; c’est généralement suspect sur des serveurs qui exécutent des charges sensibles à la latence.
Certaines plateformes mappent les gouverneurs à des politiques gérées par le hardware, mais le nom reste un indice.
Décision : Si vous exigez une faible latence stable, alignez la politique énergétique avec les SLO.
Dans les datacenters, cela signifie souvent une politique orientée performance — après confirmation des thermiques et budgets d’alimentation.
Task 5: Detect thermal throttling in logs
cr0x@server:~$ dmesg | grep -iE 'thrott|thermal|powercap' | tail -n 5
[123456.789] CPU0: Core temperature above threshold, cpu clock throttled
[123456.790] CPU0: Package temperature/speed normal
Signification : le noyau vous dit que le CPU n’est pas autorisé à tourner à la fréquence demandée.
Décision : Si le throttling apparaît pendant les incidents, corrigez le refroidissement, les courbes de ventilateur, le recyclage d’air ou les power caps.
N’« optimisez » pas le code autour d’un problème d’environnement matériel.
Task 6: Find top CPU consumers and check per-thread behavior
cr0x@server:~$ top -H -b -n 1 | head -n 20
top - 14:23:02 up 37 days, 3:12, 2 users, load average: 18.31, 17.88, 16.12
Threads: 842 total, 19 running, 823 sleeping, 0 stopped, 0 zombie
%Cpu(s): 44.1 us, 10.7 sy, 0.0 ni, 31.8 id, 12.0 wa, 0.0 hi, 0.4 si, 1.0 st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18231 app 20 0 4125588 512132 18932 R 198.7 3.2 12:40.11 api-worker
18244 app 20 0 4125588 512132 18932 R 197.9 3.2 12:39.66 api-worker
Signification : des threads chauds existent ; vous pouvez voir si le travail est parallèle ou si un thread est saturé.
La répartition CPU inclut iowait et steal — ne les ignorez pas.
Décision : Si un ou deux threads dominent, vous avez un point de sérialisation.
Réduisez la contention, shardez le travail, ou déplacez le chemin chaud hors d’un verrou partagé.
Task 7: Identify scheduler contention and context switching
cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (64 CPU)
14:23:21 UID PID cswch/s nvcswch/s Command
14:23:22 1001 18231 1200.00 900.00 api-worker
14:23:22 1001 18244 1180.00 880.00 api-worker
Signification : des switches de contexte volontaires et involontaires élevés suggèrent une contention de verrous, une sursouscription de threads, ou des appels bloquants.
Décision : Si le switching est élevé, réduisez le nombre de threads, corrigez les verrous chauds, ou investiguez l’I/O bloquante dans du code CPU.
Task 8: Check disk latency and queue depth (the usual p99 villain)
cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (64 CPU)
Device r/s w/s rkB/s wkB/s await svctm %util
nvme0n1 120.0 310.0 4096.0 12288.0 8.40 0.21 92.3
nvme1n1 15.0 20.0 512.0 768.0 0.65 0.09 3.1
Signification : await est la latence moyenne des requêtes ; %util proche de 100% suggère saturation.
Un await élevé sur un appareil avec forte utilisation corrèle souvent avec la latence tail de l’application.
Décision : Si un NVMe est saturé, confirmez la santé du périphérique et le placement de la charge.
Envisagez d’étaler l’I/O, d’augmenter la profondeur de file avec prudence, ou de déplacer les données chaudes vers l’appareil moins occupé.
Task 9: Check filesystem and mount options for unintended sync behavior
cr0x@server:~$ mount | grep -E ' /var/lib| /data'
/dev/nvme0n1p2 on /var/lib/postgresql type ext4 (rw,relatime,data=ordered)
/dev/nvme1n1p1 on /data type xfs (rw,relatime,attr2,inode64,logbufs=8)
Signification : le mode de journalisation et le choix du système de fichiers affectent la latence sous pression d’écriture.
Certaines applications forcent aussi par accident des écritures sync (fsync par requête), transformant le stockage en métronome.
Décision : Si la latence est conduite par les écritures, inspectez les paramètres de durabilité de l’application et confirmez que le système de fichiers correspond à la charge.
Task 10: NVMe health and error counters
cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning : 0x00
temperature : 61 C
available_spare : 100%
percentage_used : 7%
media_errors : 0
num_err_log_entries : 2
Signification : la température et les logs d’erreur comptent. Les SSD peuvent se throttler quand ils sont chauds ; les entrées d’erreur peuvent indiquer des liens instables ou des problèmes de firmware.
Décision : Si la température est élevée ou que les logs d’erreur augmentent pendant les incidents, améliorez le refroidissement et investiguez le firmware PCIe/NVMe et le câblage/backplane.
Task 11: Network retransmits and socket pressure
cr0x@server:~$ ss -s
Total: 1542
TCP: 1261 (estab 892, closed 298, orphaned 0, timewait 298)
Transport Total IP IPv6
RAW 0 0 0
UDP 23 21 2
TCP 963 812 151
INET 986 833 153
FRAG 0 0 0
Signification : beaucoup de connexions établies peuvent être normales ; beaucoup de timewait peuvent indiquer un churn de connexion.
Il faut corréler avec les retransmits et la latence.
Décision : Si le churn de connexions est élevé, utilisez des keep-alives/pooling ou corrigez les réglages du load balancer.
Si le TCP a des difficultés, vérifiez les erreurs d’interface et les retransmits.
Task 12: Interface errors, drops, and driver pain
cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
RX: bytes packets errors dropped missed mcast
9876543210 8765432 0 124 0 1234
TX: bytes packets errors dropped carrier collsns
8765432109 7654321 0 9 0 0 0
Signification : les drops indiquent un débordement de file ou des problèmes de driver/anneau. Même de petits taux de drops peuvent provoquer de grandes latences tail via les retransmits.
Décision : Si les drops augmentent pendant les incidents, ajustez les buffers NIC, investiguez les micro-rafales, ou ajustez le shaping/les qdiscs.
Task 13: Check CPU steal time in cloud environments
cr0x@server:~$ mpstat 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (64 CPU)
14:24:10 PM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
14:24:11 PM all 38.20 0.00 11.10 9.80 0.00 1.20 8.30 31.40
Signification : %steal est le temps où votre VM voulait du CPU mais l’hyperviseur ne l’a pas planifiée. C’est une taxe de performance que vous ne pouvez pas optimiser dans l’application.
Décision : Si le steal est notable, changez de type d’instance, migrez vers des hôtes dédiés, ou renégociez le risque voisin-bruyant avec le métier.
Task 14: NUMA locality check
cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 1 cpus: 32-63
node 0 size: 257798 MB
node 0 free: 82122 MB
node 1 size: 257789 MB
node 1 free: 18012 MB
Signification : un déséquilibre mémoire est un indice que les allocations ont dérivé et que des accès distants peuvent avoir lieu.
Décision : Si le processus chaud tourne sur plusieurs nœuds mais que sa mémoire est majoritairement sur un seul, épinglez-le ou exécutez un processus par socket.
Task 15: Page faults and reclaim behavior
cr0x@server:~$ vmstat -S M 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
10 1 0 802 90 3821 0 0 12 44 6100 8700 41 10 36 12 1
11 2 0 620 90 3950 0 0 16 60 6400 9100 43 11 29 16 1
Signification : une mémoire libre qui diminue et une I/O croissante peuvent indiquer une pression de reclaim. Même sans swap, le reclaim peut nuire à la latence.
Décision : Si le reclaim corrèle avec des pics de latence, réduisez l’empreinte mémoire, ajustez les caches, ou ajoutez de la RAM.
Task 16: One quick CPU hotspot sample with perf
cr0x@server:~$ sudo perf top -p 18231
Samples: 1K of event 'cpu-clock', 4000 Hz, Event count (approx.): 251602844
18.12% api-worker libc.so.6 [.] __memmove_avx_unaligned_erms
11.07% api-worker libssl.so.3 [.] aes_gcm_enc_update
7.44% api-worker api-worker [.] json_parse
Signification : vous obtenez une vue rapide d’où va le temps CPU. Ici, mouvements mémoire, crypto et parsing JSON dominent.
Décision : Si le temps CPU est dans des bibliothèques connues, considérez la configuration (suite de chiffrement), les tailles de payload, la compression, ou déplacez le travail hors du chemin critique.
Si le hotspot est un verrou/une boucle d’attente, vous avez une contention à corriger — pas un CPU à upgrader.
Trois mini-histoires d’entreprise (anonymisées, plausibles, pénibles)
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
Une entreprise SaaS de taille moyenne a déplacé une API sensible à la latence d’anciennes instances vers des neuves annoncées avec des clocks de boost plus élevés.
L’équipe s’attendait à une baisse de la latence p99. Ils ont obtenu l’inverse : des pics périodiques et une « régression mystère » hebdomadaire qui semblait aller et venir.
L’hypothèse erronée était subtile : ils traitaient la fréquence de boost comme une propriété stable de la machine.
En réalité, leur nouvelle flotte tournait plus dense et plus chaude. Pendant les pics de trafic, plus de cœurs boostaient simultanément, et le package atteignait les limites de puissance.
Le CPU a fait exactement ce pour quoi il était conçu : se protéger et protéger le rack de devenir un grille-pain.
Le débogage initial a suivi la direction habituelle — modifications de code, tuning GC, ajustements des pools de connexions.
Ils ont même bisecté une release qui n’avait rien à voir avec les pics. Le vrai signal était dans la télémétrie matérielle :
les pics corrélaient avec des seuils de température et une chute de fréquence effective sur les cœurs les plus occupés.
La correction a nécessité une conversation facilities et une conversation scheduling.
Ils ont amélioré le flux d’air, réduit la variance de température d’entrée, et déplacé les pods les plus sensibles à la latence sur des hôtes moins densément peuplés.
Ils ont aussi arrêté d’utiliser le « boost GHz max » comme critère d’achat sans test aligné sur les SLO.
Après la correction, la latence moyenne a peu changé. Le p99 s’est amélioré dramatiquement.
C’est comme ça que fonctionne la production : la moyenne est polie ; la queue est honnête.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une équipe backend fintech a vu l’utilisation CPU monter et a décidé « d’optimiser » en activant une compression agressive sur les payloads inter-services.
Ils ont benché en staging, observé une moindre utilisation réseau, et ont livré avec le sourire.
En production, la latence p50 s’est améliorée légèrement. Le p99 s’est aggravé. Les endpoints clients ont commencé à timeouter aux heures de pointe.
L’équipe a d’abord blâmé le réseau parce que, bien sûr, les graphiques de débit semblaient plus propres. Ensuite ils ont blâmé la base de données.
Le vrai problème était un piège classique de fréquence : la compression a déplacé du travail du réseau vers le CPU, et cela a concentré ce travail sur quelques threads.
Les threads les plus chauds passaient maintenant du temps dans les routines de compression et les copies mémoire, sensibles au comportement du cache.
Sous charge, ces threads ont perdu de la marge de boost et ont commencé à se disputer des verrous d’allocateur à cause d’un churn accru.
La correction a été ennuyeuse : désactiver la compression pour les petits payloads, limiter le niveau de compression, et batcher quand possible.
Ils ont aussi épinglé les workers lourds en compression à des cœurs spécifiques et veillé à ne pas sursouscrire les threads.
La compression est restée — juste pas partout, pas toujours, et pas au réglage maximal « parce que c’est là ».
Deuxième blague, parce que la réalité insiste : Rien ne dit « haute performance » comme ajouter plus de travail CPU pour réparer cette vilaine utilisation CPU.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée
Un détaillant exploitait un service lourd en stockage gérant des mises à jour d’inventaire. Leur équipe SRE avait l’habitude qui ressemblait à de la bureaucratie :
chaque trimestre, ils exécutaient un ensemble standardisé de vérifications de latence et de saturation sur chaque nœud de stockage et archivaient les résultats.
Personne n’aimait ça. Tout le monde voulait automatiser. Personne ne voulait s’en charger.
Pendant une saison de fêtes, ils ont vu la latence tail monter et une vague d’alertes « la base est lente ».
Le premier réflexe a été de scaler les pods applicatifs. Ça a aidé pendant environ quinze minutes puis a empiré en augmentant la concurrence I/O.
Les vérifications archivées ont été les héroïnes. Comparer l’iostat actuel et les logs SMART NVMe à la baseline trimestrielle a montré un disque avec un profil de température nouveau,
plus un petit mais croissant compte d’entrées d’erreur. Il ne tombait pas en panne de façon spectaculaire ; il défaillait poliment.
Parce qu’ils avaient des baselines et un runbook de remplacement pré-approuvé, ils ont drainé le nœud, remplacé le périphérique, et rétabli les performances sans drame.
L’entreprise n’a presque rien remarqué. C’est la vraie victoire : l’absence de réunion.
La leçon est peu sexy : gardez des baselines et des runbooks de remplacement. « Des CPU plus rapides » est un plan d’achat, pas un plan d’intervention.
Erreurs fréquentes : symptôme → cause racine → fix
Elles réapparaissent régulièrement dans des organisations intelligentes mais occupées.
Les schémas sont prévisibles, c’est pourquoi vous devriez les traiter comme de la dette opérationnelle.
1) Symptom: « CPU est à 40%, donc ce ne peut pas être le CPU »
Cause racine : un cœur est saturé ou un verrou sérialise le chemin critique ; le CPU global semble « correct ».
Fix : vérifiez le CPU par thread (top -H), la run queue (vmstat), échantillonnez les hotspots (perf top). Ensuite supprimez le point de sérialisation ou shardez.
2) Symptom: p99 spike pendant les pics de trafic, mais p50 stable
Cause racine : mise en file (pools de connexions, files disque, buffers NIC) ou pauses GC ; les clocks en rafale et le throttling peuvent amplifier cela.
Fix : trouvez la file : iostat -x, ss -s, logs GC, limites de concurrence de requêtes. Contrôlez la concurrence avant de scaler à l’aveugle.
3) Symptom: nouvelles instances « plus rapides » plus lentes que les anciennes
Cause racine : différences de latence mémoire/NUMA, fréquences soutenues plus basses sous power caps, ou attachements stockage/réseau différents.
Fix : exécutez des benchmarks en forme de SLO ; vérifiez fréquence effective, steal time et localité NUMA. Choisissez les instances par comportement soutenu, pas par pic marketing.
4) Symptom: iowait élevé, mais le vendeur de stockage dit que le NVMe est rapide
Cause racine : périphérique saturé, GC firmware, patterns de sync filesystem, ou un disque bruyant dans un pool.
Fix : vérifiez avec iostat -x, logs SMART, et latence par périphérique. Réduisez les écritures sync, étalez l’I/O, ou remplacez les périphériques suspects.
5) Symptom: timeouts réseau intermittents avec faible bande passante moyenne
Cause racine : micro-rafales provoquant des drops, bufferbloat, ou retransmits ; parfois pression softirq CPU.
Fix : vérifiez ip -s link, stats NIC, retransmits et softirq. Ajustez les files et le pacing ; n’ajoutez pas seulement de la bande passante.
6) Symptom: « Nous avons mis à niveau les CPU et rien n’a changé »
Cause racine : la charge est liée à la mémoire ou à l’I/O ; les cycles CPU n’étaient pas le facteur limitant.
Fix : mesurez les raisons des stalls (cache misses, fautes de page), await disque, et drops réseau. Dépensez l’argent sur le goulot, pas sur l’espoir.
7) Symptom: régression de performance après activation du « power saving » en datacenter
Cause racine : gouverneur/power caps réduisent les fenêtres de boost ; les workloads sensibles à la latence perdent de la marge.
Fix : alignez la politique plateforme avec les SLO ; séparez batch et workloads critiques en latence ; surveillez la fréquence effective et les événements de throttling.
8) Symptom: scaler augmente la latence
Cause racine : backends partagés saturent (stockage, BD, réseau) ou la contention augmente (verrous, thrash cache).
Fix : ajoutez de la capacité aux composants partagés, appliquez du backpressure, et limitez la concurrence. Le scale n’est pas un substitut à un modèle de files d’attente.
Listes de contrôle / plan pas à pas
Checklist A: Avant d’acheter des « CPU plus rapides »
- Collectez une semaine de latence p50/p95/p99 et de débit par endpoint.
- Confirmez si vous êtes CPU-bound, memory-bound, I/O-bound ou network-bound en utilisant
vmstat,iostat,mpstat, et un échantillon perf. - Identifiez les trois files principales et leurs points de saturation (run queue, file disque, pool de connexions).
- Mesurez la fréquence effective et les événements de throttling sous charge réelle (pas à l’idéal).
- Faites un A/B canary sur le type d’instance/CPU candidat avec le même attachement stockage et réseau.
- Décidez en vous basant sur le p99 et les taux d’erreur, pas sur l’utilisation CPU moyenne.
Checklist B: Quand le p99 est en feu (mode incident)
- Confirmez la portée : une AZ, une classe d’hôte, un endpoint, un tenant ?
- Exécutez
vmstat 1 5etmpstat 1 3: déterminez CPU vs iowait vs steal. - Exécutez
iostat -x 1 3: vérifiezawaitet%utilpar device. - Exécutez
ip -s linketss -s: vérifiez drops et churn de connexions. - Vérifiez les logs thermique/powercap (
dmesg). - Prenez un échantillon
perf topsur le PID chaud pour valider les hotspots CPU. - Appliquez la plus petite mitigation sûre : limitez la concurrence, déchargez la charge, réacheminez, videz les nœuds défaillants.
- Ce n’est qu’ensuite que vous tunez ou revenez sur des changements de code.
Checklist C: Concevoir pour « la fréquence est variable »
- Supposez que la performance effective par cœur fluctue. Construisez des SLO et de l’autoscaling avec marges.
- Minimisez les verrous globaux et les goulots mono-thread ; ils amplifient la variance de fréquence.
- Gardez les structures de données chaudes friendly cache ; traitez la latence mémoire comme une part de votre budget.
- Utilisez pooling de connexions et backpressure pour éviter l’explosion des files.
- Séparez batch et workloads critiques en latence sur des nœuds différents ou avec QoS stricte.
- Établissez des baselines de performance trimestrielles et après changements firmware/noyau.
FAQ
1) La course aux fréquences revient-elle réellement ?
Pas comme « tout le monde passe de 3GHz à 6GHz pour toujours ». Elle revient comme fréquence dynamique : clocks en rafale, boost par cœur,
et réglages au niveau plateforme où la fréquence est un bouton parmi d’autres.
2) Dois-je me préoccuper de la fréquence de base ou du boost lors d’un achat de serveurs ?
Intéressez-vous à la fréquence effective soutenue sous votre charge. Le boost est un instantané meilleur cas.
La fréquence de base est souvent conservative. Votre SLO vit dans le milieu désordonné.
3) Quelle est la raison la plus fréquente pour laquelle « CPU plus rapide » n’aide pas ?
Vous n’êtes pas CPU-bound. Vous attendez la mémoire, la latence de stockage, la mise en file réseau, ou la contention d’ordonnanceur/virtualisation.
L’upgrade CPU ne fait qu’accélérer l’attente.
4) Comment distinguer rapidement lié CPU vs lié mémoire ?
Commencez par vmstat (r vs wa) et un rapide perf top.
Si vous voyez beaucoup de temps dans des copies mémoire et des stalls causés par des cache-miss (ou si l’app est pointer-chase heavy), suspectez la latence mémoire et la localité.
5) Des GHz plus élevés aident-ils les bases de données ?
Parfois. Les bases de données ont souvent des composants mono-thread (writer de log, certains gestionnaires de verrous) où la performance par cœur compte.
Mais beaucoup de goulots BD sont la latence de stockage, le hit rate du cache buffer, ou la contention de verrous. Mesurez avant d’acheter.
6) Les GPU font-ils partie de la nouvelle course aux fréquences ?
Oui, et ils sont encore plus sensibles aux limites puissance et thermique. De plus, la performance GPU est fréquemment limitée par la bande passante mémoire,
la forme du kernel, et le transfert hôte- périphérique sur PCIe ou fabric — pas seulement l’horloge.
7) Dans le cloud, pourquoi la performance varie-t-elle même sur le même type d’instance ?
Temps CPU volé, gestion d’énergie hôte, voisins bruyants, et variabilité des chemins stockage/réseau attachés.
Surveillez %steal, les drops, et les métriques de latence stockage ; traitez « même type » comme « contrat similaire », pas comme matériel identique.
8) Si les clocks sont variables, dois-je désactiver le scaling de fréquence ?
Pas aveuglément. Désactiver le scaling peut augmenter la puissance et la chaleur, déclenchant parfois un throttling pire.
Pour des services sensibles à la latence, utilisez une politique alignée sur vos SLO et vérifiez les thermiques et la performance soutenue.
9) Quel est le modèle mental le plus utile pour le débogage de performance ?
Trouvez la file. Une fois que vous savez ce qui est en file — tâches CPU exécutables, requêtes disque, paquets réseau, attendes de verrou — vous savez contre quoi vous vous battez réellement.
Conclusion : que faire lundi matin
La course aux fréquences revient, mais ce n’est pas une droite et ce n’est pas un raccourci d’achat.
En production, la performance effective se négocie entre thermiques, limites de puissance, ordonnanceurs, localité mémoire, et variabilité d’I/O.
Vous ne gagnez pas en pourchassant les GHz. Vous gagnez en identifiant la file et en rétrécissant la queue.
Étapes pratiques :
- Choisissez un service critique et exécutez la checklist « mode incident » pendant une période calme. Sauvegardez la baseline.
- Ajoutez un panneau de dashboard pour
%steal,iowait,awaitdisque, drops NIC, et événements de throttling. - Faites un canary contrôlé comparant types d’instances sous trafic réel, jugé par p99 et taux d’erreur.
- Notez vos trois principaux points de sérialisation connus et planifiez-les comme des bugs, pas comme des « projets performance ».
- Ayez la conversation désagréable : si votre SLO requiert une performance consistante, traitez la puissance et le refroidissement comme partie de la plateforme, pas comme un après-coup.