Vos tableaux de bord sont au vert, votre SLO de latence est respecté, puis les achats vous annoncent que la mise à jour CPU « next‑gen » va glisser de deux trimestres. Soudain, ce plan « on attendra le prochain tick » ressemble à une histoire pour s’endormir en évitant le risque.
Pendant des années, la cadence tick‑tock d’Intel n’a pas seulement façonné les puces. Elle a structuré la façon dont les entreprises planifiaient la capacité, budgétaient les datacenters et justifiaient les décisions « on attend la génération suivante ». La cadence rendait la prévision presque scientifique. Puis la cadence a cassé, et une grande partie de cette « science » n’était que de l’arithmétique réconfortante.
Tick‑tock en un paragraphe
Le tick‑tock d’Intel était un rythme de développement produit : un « tick » signifiait une réduction du procédé de fabrication (même architecture de base, transistors plus petits), et un « tock » signifiait une nouvelle microarchitecture (nouveau design) sur un procédé éprouvé. À peu près chaque année, on obtenait soit un rétrécissement, soit une refonte. Pour les clients, cela créait l’illusion d’un métronome : gains prévisibles en performance par watt, cycles de renouvellement prévisibles, calendriers d’amortissement prévisibles, plans d’équipe prévisibles, tout était prévisible. Cette prévisibilité était réelle—jusqu’à ce qu’elle ne le soit plus.
Pourquoi les équipes d’exploitation aimaient tick‑tock (et pourquoi c’était dangereux)
Du point de vue SRE, le tick‑tock dépassait le marketing. C’était un primitif de planification. On pouvait construire des modèles de capacité trimestriels en supposant « le CPU gen N+1 fournit X % de débit en plus pour Y % de consommation en moins », puis convertir cela en nombre de baies et enveloppes électriques. On pouvait caler migrations, burn‑in matériel et rafraîchissements de parc comme dans une usine.
Le danger : la planification basée sur une cadence tend à devenir une planification fondée sur la foi. Quand vous construisez une dépendance métier sur le calendrier d’un fournisseur, vous transformez vos opérations en produit dérivé. Ça passe quand le fournisseur tient la cadence. Quand il dérape, votre taux d’incidents devient fonction de la lithographie de quelqu’un d’autre.
Tick‑tock encourageait aussi une mauvaise habitude spécifique : reporter le travail difficile. « On corrigera ça au prochain refresh » est un narcotique opérationnel. Ça donne l’impression d’être responsable—pourquoi optimiser ou repenser maintenant si les CPUs de l’année prochaine nous sauveront ? Puis l’année suivante n’arrive pas à l’heure, et il vous reste une charge qui n’a jamais appris à bien se comporter.
Une des raisons pour lesquelles le modèle a longtemps fonctionné est qu’il alignait les incitations. Intel avait une histoire claire à raconter. Les OEM disposaient de lancements produits prévisibles. Les entreprises avaient un calendrier pour accrocher leurs budgets. L’écosystème entier a convergé vers « amélioration générationnelle » comme solution par défaut aux problèmes de performance.
Blague n°1 : L’ère tick‑tock, c’était comme avoir un métronome pour votre budget. Puis la physique est arrivée et l’a débranché.
Faits intéressants et contexte historique (ce que les gens oublient)
- Tick‑tock a commencé comme outil de discipline. Ce n’était pas juste un slogan ; c’était une façon de forcer l’alternance des risques : risque de fabrication un cycle, risque de conception le suivant.
- Il a été étendu au‑delà du tick‑tock. Intel a fini par évoluer vers un modèle « process–architecture–optimization », reconnaissant que la simple alternance ne tenait pas.
- « 14nm » a duré plus d’une génération. Plusieurs familles et rafraîchissements CPU ont vécu sur du 14nm plus longtemps que prévu, étirant ce que signifiait « nouvelle génération » opérationnellement.
- Les retards du 10nm n’étaient pas que des glissements de planning. Ils reflétaient des défis de rendement et de complexité liés à la mise à l’échelle, au multi‑patterning et à l’atteinte simultanée d’objectifs (densité, fréquence, fuite).
- Les gains d’IPC n’ont jamais été garantis. Les changements de microarchitecture peuvent échanger performance mono‑coeur contre efficacité, durcissement de la sécurité ou plus de coeurs—utile, mais pas toujours adapté à vos charges.
- La puissance est devenue le plafond avant le calcul. Pour beaucoup de datacenters, l’ampérage et la capacité de refroidissement limitaient le débit réel plus que les seules spécifications CPU. Tick‑tock n’annule pas la thermodynamique.
- Les atténuations de sécurité ont changé la ligne de base de performance. Après 2018, les mitigations et mises à jour microcode ont compliqué les comparaisons « génération à génération » ; certains workloads paient un vrai surcoût.
- Les concurrents ont progressé quand Intel a trébuché. La résurgence d’AMD a fait que le calendrier d’Intel n’était plus celui de toute l’industrie.
- Le parallélisme logiciel est devenu le multiplicateur. À mesure que les gains par coeur ralentissaient, le débit total dépendait de plus en plus du nombre de coeurs et de la capacité du logiciel à s’échelle—souvent la partie la plus difficile.
Où ça a cassé : processus, physique et exécution
The uncomfortable truth: “shrink” stopped being the easy half
Aux débuts du tick‑tock, les rétrécissements de procédé livraient un paquet assez fiable : moins de consommation à performance similaire, ou plus de performance à consommation similaire. Ce n’était pas de la magie ; c’était de la géométrie, des améliorations de fuite et de meilleurs matériaux et implantations. Mais quand les nœuds sont devenus plus petits, tout est devenu plus difficile en même temps : patterning, variabilité, résistance des interconnexions et coût économique de chasser de petits défauts sur d’énormes plaquettes.
Les opérationnels adorent « nœud plus petit » parce que ça sonne comme un déjeuner gratuit. Ce ne l’a jamais été. Le déjeuner était payé par des outillages de fonderie toujours plus complexes, des rendements de plus en plus fragiles et beaucoup d’héroïsme d’ingénierie. Quand ce pipeline d’héroïsme se bouche—par la complexité, la maturité des outillages, des problèmes d’intégration—votre cadence échoue.
La défaillance de la cadence change les incitations en aval
Quand un fournisseur reporte un nœud de procédé, les clients se retrouvent dans un espace décisionnel étrange :
- Achetez‑vous encore la génération « actuelle », même si vous prévoyiez de la sauter ?
- Prolongez‑vous la vie du matériel ancien, en augmentant les taux de panne et la charge opérationnelle ?
- Changez‑vous de fournisseur ou de plateforme, en absorbant travail de qualification et risque ?
- Réarchitectez‑vous la charge pour qu’elle dépende moins du CPU ?
Tick‑tock masquait ces compromis. Son déclin les a exposés.
L’augmentation microarchitecturale dépend du workload, et ça a toujours été le cas
Une autre raison pour laquelle le récit tick‑tock a fini par se fissurer : l’idée que « la génération suivante est 20 % plus rapide » est tout au plus une médiane sur des benchmarks synthétiques ou sélectionnés. En production, votre performance peut être limitée par un canal mémoire, un point chaud de contention sur un verrou global, un choix d’ordonnanceur du noyau, une profondeur de file d’attente de stockage ou le réglage d’interruption d’une NIC. Les améliorations microarchitecturales ne réparent pas une mauvaise concurrence. Elles la font juste échouer plus vite.
« Optimization » est devenue une ligne de produit parce que le time‑to‑market comptait
Une fois que les glissements de cadence sont devenus la norme, Intel—comme toute grosse orga d’ingénierie—devait livrer quelque chose. Cela signifie souvent des optimisations itératives sur un procédé stable plutôt qu’une alternance nette tick/tock. Opérationnellement, ça change la façon de qualifier de nouveaux serveurs. Un « refresh » peut être un uplift modeste, pas un grand bond. Votre plan de test doit être assez sensible pour détecter des régressions petites mais significatives : jitter, latence de queue, comportement turbo sous limites cgroup, ou anomalies perf sous mitigations.
Idée paraphrasée (attribuée à James Hamilton) : « La fiabilité vient de la conception de systèmes qui tolèrent la défaillance, pas d’hypothèses que des composants ou des calendriers ne tomberont pas en panne. »
Comment le déclin du tick‑tock a changé le SRE et la planification de capacité
La planification de capacité est passée de « prévision d’augmentation » à « conception pour l’incertitude »
À l’ère du confort tick‑tock, on pouvait traiter l’amélioration CPU comme des intérêts sur un compte épargne. Dans le monde post‑cadence, l’amélioration est irrégulière. On peut obtenir un saut significatif grâce au nombre de coeurs un cycle, puis seulement des gains marginaux le suivant. Ou un uplift peut être effacé par des limites de puissance et des politiques turbo. La planification moderne de capacité nécessite donc des contingences : marge, options multi‑fournisseurs et travail d’efficacité au niveau des workloads.
Que faire : passez d’une planification sur une seule ligne « N+1 est plus rapide » à une planification par scénarios : meilleur cas, attendu, pire cas. Attachez à chaque scénario un plan d’atténuation (optimiser, scaler horizontalement, changer de type d’instance ou de fournisseur).
Les achats ont cessé d’être « acheter le suivant » et sont devenus une fonction fiabilité
Les équipes procurement demandaient autrefois un chiffre : « Combien de serveurs l’an prochain ? » Maintenant, la bonne réponse est souvent un arbre : « Si on a le CPU gen X au T2, on suit le plan A ; sinon, plan B avec un SKU différent ; si la contrainte est la puissance, plan C avec une autre densité. »
Ce n’est pas de l’indécision. C’est de la résilience. Votre chaîne d’approvisionnement fait désormais partie de votre système, que ça vous plaise ou non.
L’ingénierie de la performance est devenue plus honnête
Tick‑tock autorisait beaucoup de paresse en matière de performance. Le déclin a forcé les équipes à affronter les vrais goulots : complexité algorithmique, contention sur les verrous, localité mémoire, amplification I/O, et le fait que certaines charges coûtent simplement cher.
C’est douloureux. C’est aussi libérateur. Une fois que vous arrêtez d’attendre une génération magique de CPU, vous commencez à corriger le vrai problème.
Les mitigations de sécurité et microcode font désormais partie de la baseline
Autre changement opérationnel : la performance n’est plus « hardware + software », c’est « hardware + software + microcode + mitigations ». Votre suite de bench doit inclure des versions réalistes du noyau, du microcode et votre configuration de production réelle. Sinon vous achèterez une surprise coûteuse.
Trois mini‑histoires d’entreprise du terrain
Mini‑histoire n°1 : L’incident causé par une hypothèse erronée (« la prochaine génération nous sauvera »)
L’entreprise : un fournisseur SaaS de taille moyenne avec une charge en pics et une courbe de croissance régulière. La plateforme exécutait une couche de services Java, un cache de type Redis et une couche de métadonnées stockée. Leur plan de capacité supposait un uplift CPU majeur arrivant au T3. Ils n’en avaient besoin que pour les pics au 99e percentile qui survenaient lors de jobs batch clients.
L’hypothèse erronée était subtile : ils pensaient pouvoir « encaisser » les pics avec la marge existante jusqu’au refresh. Ils ont différé deux tâches : éliminer un verrou global dans le service métadonnées et réduire le CPU consommé par la sérialisation JSON.
Le refresh a glissé. Pas d’une semaine. Assez longtemps pour que la courbe de croissance les rattrape. Un vendredi soir, un client à jobs batch lourds a lancé un nouveau job, les pics sont apparus, la saturation CPU a dégénéré en files d’attente, la latence tail a explosé et les caches ont commencé à se vider. La couche métadonnées est entrée en spirale : timeouts entraînant des retries ; les retries amplifiant la charge ; le verrou global devenant plus chaud ; le CPU à 100 % et qui y restait.
Ils ont récupéré en déchargeant de la charge et en désactivant temporairement les jobs les plus lourds du client. La vraie correction a pris deux sprints : suppression du verrou et remplacement du chemin de sérialisation par un format binaire moins coûteux pour les appels internes. Après cela, le service tournait correctement sur les anciens CPUs. Le refresh est redevenu un luxe plutôt qu’un dispositif de survie.
La leçon : traitez les roadmaps fournisseurs comme des bulletins météo. Utiles, mais vous ne reportez pas la réparation du toit parce que la météo annonce du soleil.
Mini‑histoire n°2 : L’optimisation qui s’est retournée contre eux (« plus de coeurs va régler ça »)
L’entreprise : une plateforme analytique interne avec une grande flotte de nœuds compute. Leurs jobs étaient mixtes : certains facilement parallélisables, d’autres non. Ils ont monté la gamme vers un SKU à plus grand nombre de coeurs sur le même procédé, en espérant des gains linéaires de débit. Ils ont aussi relevé les limites CPU des containers pour « laisser respirer les jobs ».
Le débit s’est amélioré sur papier pour une partie des workloads. Puis une autre classe de jobs a commencé à manquer ses deadlines. L’enquête a montré une latence tail augmentée et une performance effective par coeur en baisse. Les CPUs avec plus de coeurs tournaient à des fréquences turbo all‑core plus basses sous charge soutenue, et le sous‑système mémoire devenait le goulot. Plus de coeurs impliquent plus de contention sur la bande passante mémoire et le cache, et certains jobs deviennent plus lents parce qu’ils sont sensibles à la vitesse par thread.
Pire, relever les limites CPU des containers a accru l’effet voisin bruyant. Quelques jobs agressifs ont consommé le LLC partagé et la bande passante mémoire, asphyxiant les autres. L’ordonnanceur a fait de son mieux, mais la physique n’était pas impressionnée. Les gens ont d’abord blâmé les nouveaux CPUs, puis Kubernetes, puis les uns les autres. Classique.
Ils se sont stabilisés en classifiant les workloads : les jobs sensibles par thread ont été épinglés à une autre pool de nœuds avec un SKU différent et des limites CPU plus strictes ; les jobs gourmands en bande passante ont vu leur nombre de threads ajusté ; et ils ont ajouté une surveillance de la bande passante mémoire dans l’admission control. L’« upgrade » a quand même aidé globalement, mais seulement après avoir aboli l’hypothèse simpliste « coeurs = vitesse ».
La leçon : le nombre de coeurs n’est pas une monnaie universelle. Votre workload paie en latence, bande passante, localité cache et overhead d’ordonnancement. Budgétez en conséquence.
Mini‑histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (« garder une pipeline de qualification »)
L’entreprise : un service adjacent aux paiements où les outages sont professionnellement embarrassants. Ils avaient vécu assez de transitions matérielles pour se méfier des rafraîchissements massifs. Leur pratique était peu glamour : garder un petit cluster de qualification qui exécute en permanence la prochaine combinaison matérielle et noyau prévue, sous une charge reproduisant la production.
Quand la cadence fournisseur a commencé à vaciller, ils n’ont pas paniqué. Ils avaient déjà un processus d’intake : nouvelles versions BIOS, nouveau microcode, nouveau noyau et nouveaux CPU SKU passaient dans ce cluster avec des tests reproductibles—histogrammes de latence, compteurs perf, latence stockage et comportement puissance/thermique.
Un cycle, ils ont découvert qu’une mise à jour BIOS changeait les limites de puissance et le comportement turbo, causant une augmentation mesurable de la latence tail sous charge bursty. Rien n’était « cassé », mais leur marge SLO avait fondu. Comme ils l’ont trouvé tôt, ils ont négocié une configuration BIOS différente et ajusté les règles de déploiement avant que le refresh n’atteigne la disponibilité générale.
Quand le planning du refresh a glissé, ils ont simplement continué à acheter un SKU connu et stable et sont restés dans les contraintes de puissance/refroidissement. Le pipeline ennuyeux a fait qu’ils ne misaient pas la production sur l’espoir. Ils misaient sur des données.
Blague n°2 : Leur cluster de qualification était si terne que personne ne voulait le présenter—jusqu’à ce qu’il évite un Sev‑1, à quel point il est devenu la pierre préférée de tout le monde.
Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième
Version on‑call. Vous n’écrivez pas une thèse ; vous essayez d’arrêter l’hémorragie et d’identifier la ressource limitante en quelques minutes.
Premier : saturation CPU ou mise à l’écart CPU ?
- Vérifier l’utilisation CPU vs file d’exécution : un CPU élevé avec une longue file d’exécution suggère une vraie saturation ; un CPU bas avec une latence élevée suggère du blocage (I/O, verrous, throttling).
- Vérifier le throttling : quotas cgroup, thermal throttling ou limites de puissance peuvent imiter des « CPUs lents ».
Second : le goulot est‑il mémoire, I/O ou contention ?
- Pression mémoire : rechercher reclaim, activité swap, fautes majeures. Le CPU peut être « occupé » à gérer des pages.
- Attente I/O et latence stockage : le queueing sur disques ou stockage réseau se manifeste par des threads exécutables en attente.
- Contention sur les verrous : temps système élevé, nombreux context switches, ou hotspots mutex applicatifs peuvent dominer.
Troisième : confirmer avec compteurs et flame graphs
- Perf top / perf record : trouver les fonctions chaudes et confirmer si vous êtes limité par le calcul ou bloqué sur la mémoire.
- Fréquence CPU et limites de puissance : vérifier le comportement réel des fréquences sous charge.
Quatrième : comparer à une baseline connue
Si vous avez une flotte mixte, comparez la même charge sur vieux vs nouveaux CPUs, même noyau, même microcode. La dérive générationnelle est souvent une dérive de configuration déguisée en différence siliconée.
Tâches pratiques : commandes, ce que la sortie signifie, et la décision que vous prenez
Ce sont les tâches « que fais‑je maintenant ? ». Elles sont écrites pour des serveurs Linux en environnement datacenter typique. Exécuter en root si nécessaire.
Tâche 1 : Identifier le modèle CPU et le niveau de microcode
cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|CPU\(s\)'
CPU(s): 64
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 2
Model name: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz
cr0x@server:~$ dmesg | grep -i microcode | tail -n 3
[ 0.412345] microcode: microcode updated early to revision 0x2000065, date = 2023-07-11
[ 0.412678] microcode: CPU0: patch_level=0x2000065
[ 0.413012] microcode: CPU1: patch_level=0x2000065
Sens : Vous savez exactement quel silicium et quel microcode vous benchmarkez. Le microcode affecte les mitigations et parfois la performance.
Décision : Si deux clusters diffèrent de microcode, cessez de les comparer comme équivalents. Alignez le microcode avant d’accuser la génération CPU.
Tâche 2 : Vérifier le comportement actuel de la fréquence CPU (turbo, signaux de throttling)
cr0x@server:~$ cat /proc/cpuinfo | awk -F: '/cpu MHz/{sum+=$2; n++} END{printf "avg MHz: %.0f\n", sum/n}'
avg MHz: 1895
Sens : La MHz moyenne est en dessous des attentes base/turbo sous charge ou en raison de politiques de puissance.
Décision : Si la performance est « pire que prévu », vérifiez le scaling de fréquence et les limites de puissance avant de réécrire le code.
Tâche 3 : Vérifier le gouverneur cpufreq (quand applicable)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Sens : Le système favorise l’efficacité énergétique ; les workloads sensibles à la latence peuvent en pâtir.
Décision : Pour les tiers sensibles à la latence, envisagez de mettre performance (après validation de la marge puissance/thermique).
Tâche 4 : Vérifier load average, file d’exécution et steal CPU
cr0x@server:~$ uptime
10:41:12 up 47 days, 3:18, 2 users, load average: 62.21, 58.03, 41.77
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server) 01/10/2026 _x86_64_ (64 CPU)
10:41:19 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
10:41:20 AM all 71.2 0.0 8.7 0.3 0.0 0.8 0.0 19.0
10:41:21 AM all 72.1 0.0 9.1 0.2 0.0 0.7 0.0 17.9
10:41:22 AM all 70.4 0.0 8.9 0.2 0.0 0.8 0.0 19.7
Sens : Load élevé avec %usr élevé suggère saturation CPU ; %iowait bas suggère que ce n’est pas I/O. Pas de steal indique que ce n’est pas un hyperviseur voisin bruyant.
Décision : Si %usr est élevé et la latence suit la charge, scale‑outez ou réduisez le coût CPU par requête ; ne perdez pas de temps à tuner les disques.
Tâche 5 : Identifier les principaux consommateurs CPU (triage rapide)
cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
PID COMMAND %CPU %MEM
23104 java 612.3 18.1
18422 envoy 155.7 1.2
9921 node 88.4 3.8
4137 postgres 62.1 6.4
Sens : Un processus consomme fortement plusieurs coeurs ; le goulot est probablement dans ce chemin de code ou sa configuration.
Décision : Concentrez le profiling sur le principal coupable ; ne touchez pas aux paramètres kernel au hasard « au cas où ».
Tâche 6 : Détecter le throttling cgroup (containers)
cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 178122938412
user_usec 162331112009
system_usec 15791826403
nr_periods 1831221
nr_throttled 421112
throttled_usec 11231398122
Sens : nr_throttled et throttled_usec sont élevés : la charge est throttlée par le quota CPU.
Décision : Si la latence corrèle avec le throttling, ajustez limites/requests CPU ou déplacez vers un pool sans quotas stricts.
Tâche 7 : Vérifier la pression mémoire et l’activité de reclaim
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
28 1 0 84212 90124 812344 0 0 12 45 9021 22133 71 10 18 1 0
31 0 0 79044 90124 810102 0 0 14 22 9104 23110 72 9 19 0 0
34 2 0 61012 90124 804991 0 0 11 31 9442 24998 69 12 17 2 0
35 3 0 33200 90124 799812 0 0 19 55 9901 27120 65 14 18 3 0
38 5 0 12044 90124 795103 0 0 21 61 10312 30002 61 16 18 5 0
Sens : La file d’exécution (r) est élevée ; la mémoire libre s’effondre ; un peu de blocage (b) et des context switches en hausse. Vous approchez d’une pression mémoire qui peut transformer le CPU en machine à pagination.
Décision : Si les fautes majeures / reclaim augmentent, réduisez l’empreinte mémoire ou ajoutez de la RAM ; n’assumez pas que « des CPUs plus rapides » résoudront une pression mémoire.
Tâche 8 : Vérifier explicitement swap et fautes majeures
cr0x@server:~$ sar -B 1 3
Linux 6.1.0 (server) 01/10/2026 _x86_64_ (64 CPU)
10:42:31 AM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
10:42:32 AM 0.00 62.00 9212.00 12.00 24120.00 0.00 0.00 0.00 0.00
10:42:33 AM 0.00 71.00 9440.00 15.00 25201.00 0.00 0.00 0.00 0.00
10:42:34 AM 0.00 58.00 9011.00 11.00 23210.00 0.00 0.00 0.00 0.00
Sens : Les fautes majeures ne sont pas négligeables ; si elles montent, vous verrez des pics de latence et du « gaspillage » CPU.
Décision : Traitez les fautes majeures comme une menace SLO ; investissez dans l’efficacité mémoire ou isolez le coupable.
Tâche 9 : Confirmer la latence stockage et le queueing
cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 01/10/2026 _x86_64_ (64 CPU)
Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s %util await r_await w_await
nvme0n1 12.0 48.0 1.2 9.8 0.0 22.0 94.1 18.4 4.1 22.0
Sens : Le disque est proche de la saturation (%util élevé) et l’attente moyenne est élevée ; votre « goulot CPU » peut être en réalité du queueing I/O.
Décision : Si le stockage est chaud, réduisez les writes synchrones, ajustez le batching, ajoutez des devices ou migrez les données chaudes vers des tiers plus rapides—n’achetez pas de CPUs supplémentaires.
Tâche 10 : Vérifier erreurs réseau et drops (source cachée de latence)
cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
RX: bytes packets errors dropped missed mcast
98341234123 81234123 0 10231 0 1123
TX: bytes packets errors dropped carrier collsns
77123123123 70123123 0 8221 0 0
Sens : Les packets dropped peuvent se traduire par des retransmissions, de la latence tail et un CPU qui fait de l’overhead dans la pile réseau.
Décision : Si les drops montent pendant les incidents, inspectez les queues NIC, les paramètres du driver et la congestion en amont. Les upgrades CPU ne résoudront pas la perte de paquets.
Tâche 11 : Vérifier la pression de l’ordonnanceur et les context‑switches
cr0x@server:~$ pidstat -w 1 3
Linux 6.1.0 (server) 01/10/2026 _x86_64_ (64 CPU)
10:43:22 AM UID PID cswch/s nvcswch/s Command
10:43:23 AM 0 23104 12010.0 22100.0 java
10:43:23 AM 0 18422 3100.0 9020.0 envoy
10:43:23 AM 0 4137 820.0 1100.0 postgres
Sens : Les context switches non volontaires élevés suggèrent que les threads sont préemptés—souvent à cause de contention CPU ou de verrous.
Décision : Si nvcswch/s est énorme, investiguez le nombre de threads, la contention sur les verrous et les quotas cgroup avant d’ajouter des nœuds.
Tâche 12 : Trouver les hotspots applicatifs avec perf (rapidement)
cr0x@server:~$ sudo perf top -p 23104
Samples: 1K of event 'cycles', 4000 Hz, Event count (approx.): 250000000
18.22% java libjvm.so [.] SpinPause
12.10% java libpthread-2.36.so [.] pthread_mutex_lock
9.44% java libjvm.so [.] Unsafe_Park
7.51% java libc-2.36.so [.] memcpy
Sens : Vous brûlez des cycles dans du spin et des mutex, pas dans du « travail utile ». C’est de la contention.
Décision : Corrigez la concurrence (sharding de verrous, réduire les sections critiques), ajustez les pools de threads ou réduisez l’état partagé. Les nouveaux CPUs ne régleront pas une fête de mutex.
Tâche 13 : Vérifier la topologie NUMA et le thrashing inter‑socket
cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-15 32-47
node 0 size: 192000 MB
node 0 free: 41000 MB
node 1 cpus: 16-31 48-63
node 1 size: 192000 MB
node 1 free: 12000 MB
Sens : La mémoire est déséquilibrée ; le node 1 est tendu. L’accès mémoire distant peut augmenter, dégradant la latence.
Décision : Si la latence tail corrèle avec un déséquilibre NUMA, épinglez processus/allocateurs ou rééquilibrez les workloads entre sockets.
Tâche 14 : Vérifier limites de puissance et indices de throttling thermique via les messages kernel
cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|therm' | tail -n 5
[183112.991201] powercap_intel_rapl: package-0 domain package locked by BIOS
[183114.102233] CPU0: Core temperature above threshold, cpu clock throttled
[183114.102241] CPU0: Package temperature/speed normal
Sens : Vous êtes littéralement limité par la chaleur. Ce n’est pas un « mauvais CPU », c’est une contrainte environnementale.
Décision : Corrigez le refroidissement, les réglages BIOS power, les courbes de ventilateurs ou le placement des workloads. Sinon vous achèterez des CPUs plus rapides pour les faire tourner moins vite.
Tâche 15 : Comparer l’état des mitigations du noyau (sensible à la performance)
cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; IBRS_FW; STIBP: conditional
Sens : Les mitigations sont activées ; elles peuvent changer la performance des workloads intensifs en syscall ou en context switches.
Décision : Ne comparez pas des benchmarks entre des flottes avec différents états de mitigations ; standardisez la politique et mesurez l’impact.
Erreurs courantes : symptôme → cause racine → correction
1) « Les nouveaux CPUs sont plus lents »
Symptôme : Après un refresh, le débit est plat ou pire ; la latence tail se dégrade sous charge.
Cause racine : Limites de puissance / réglages BIOS réduisent la fréquence soutenue ; plus grand nombre de coeurs abaisse le turbo all‑core ; le workload est sensible par thread.
Correction : Vérifiez les fréquences réelles sous charge production ; ajustez les profils power BIOS ; séparez workloads par pool per‑core vs throughput ; ajustez les nombres de threads.
2) « Le CPU est à 60 %, mais la latence est terrible »
Symptôme : Les CPUs ne sont pas saturés, mais la latence p99 explose.
Cause racine : Throttling cgroup, contention sur les verrous, reclaim mémoire ou queueing I/O provoquent du blocage plutôt qu’une saturation pure du CPU.
Correction : Vérifiez cpu.stat pour le throttling, hotspots perf, vmstat pour le reclaim et iostat await. Corrigez la ressource bloquante, pas la taille du CPU.
3) « On a attendu la génération suivante et on a raté notre SLO »
Symptôme : Projets différés en attendant un uplift matériel ; falaise de performance quand le refresh glisse.
Cause racine : La dépendance à la roadmap a servi de substitut au travail d’ingénierie ; pas de plan de secours.
Correction : Maintenez un plan pire‑cas : optimisez les chemins critiques maintenant, gardez une flotte de qualification et budgétez une marge.
4) « Le benchmark dit +25 %, la production dit +3 % »
Symptôme : Les résultats labo ne correspondent pas à la réalité.
Cause racine : Les benchmarks s’exécutent avec un noyau/microcode différents, des mitigations différentes, un I/O irréaliste ou sans patrons de contention.
Correction : Construisez des tests de charge production‑like incluant stockage/réseau, limites réalistes de containers, même noyau et microcode, et métriques de distribution de latence.
5) « Plus de coeurs a amélioré le débit mais augmenté le jitter »
Symptôme : La performance moyenne s’améliore ; p99/p999 se dégradent.
Cause racine : Contention voisin bruyant sur cache/bande passante mémoire ; overhead scheduler ; comportement GC modifié avec le nombre de coeurs.
Correction : Isolez les workloads sensibles à la latence ; appliquez contrôles CPU/bande passante mémoire quand possible ; ajustez GC et pools de threads pour la nouvelle topologie.
6) « La flotte est identique, mais la moitié des nœuds sont bizarres »
Symptôme : Même SKU, performances différentes, throttling intermittent.
Cause racine : Dérive BIOS, différences firmware, microcode différent, variance de refroidissement ou mauvais peuplement DIMM affectant les canaux mémoire.
Correction : Traitez le firmware comme de la configuration ; imposez un BIOS/firmware golden ; auditez la disposition DIMM ; suivez la télémétrie thermique ; mettez en quarantaine les outliers.
Listes de contrôle / plan étape par étape
Étape par étape : comment planifier un refresh quand la cadence est peu fiable
- Inventaire de la réalité. Enregistrez modèle CPU, microcode, noyau, BIOS, config mémoire, stockage et firmware NIC. Pas de « à peu près pareil ».
- Construire une taxonomie de workloads. Sensible par thread, batch throughput, lié à la bande passante mémoire, I/O bound, mixte. Assignez des propriétaires.
- Définir les métriques de succès. Pas « plus rapide ». Utilisez p50/p95/p99 de latence, coût par requête, watts par requête, taux de burn d’error budget et modes de défaillance.
- Établir une pool de qualification. Petite mais toujours active. Exécutez canaries ou replays de charge en continu.
- Standardiser microcode + mitigations pour les tests. Mesurez avec la politique production ; documentez les écarts.
- Faire A/B à enveloppes de puissance égales. Si un SKU est power‑limited dans vos racks, ça compte plus que la spec pico.
- Mesurer les contraintes « ennuyeuses ». Puissance rack, refroidissement, oversubscription top‑of‑rack, profondeurs de queues stockage et topologie NUMA.
- Avoir un plan de glissement. Si la next‑gen n’arrive pas, que commandez‑vous ? Quel travail d’optimisation accélérer ? Quelle gestion de la demande appliquer ?
- Déployer avec garde‑fous. Canary, puis 5 %, puis 25 %, puis le reste. Bloquez sur les SLOs et regressions, pas sur une date calendaire.
- Rédiger le postmortem même si tout s’est bien passé. Capturez ce qui vous a surpris ; c’est le registre des risques du prochain cycle.
Checklist : diagnostiquer « on attendait un uplift, on n’a rien eu »
- Confirmer version noyau identique et paramètres de boot identiques.
- Confirmer révision microcode et états de mitigation.
- Vérifier profil power BIOS, réglages turbo et power caps.
- Vérifier population des canaux mémoire ; contrôler NUMA.
- Comparer fréquence soutenue sous charge réelle, pas au repos.
- Mesurer latence I/O et drops réseau pendant les tests de charge.
- Profiler hotspots : verrous, appels système, memcpy, GC, fautes de page.
- Vérifier quotas CPU containers et compteurs de throttling.
- Relancer avec le même mix de requêtes ; confirmer que ce n’est pas une dérive de workload.
Checklist : réduire la dépendance à la roadmap (quoi faire ce trimestre)
- Identifier les 3 services principaux dont le plan de capacité suppose « next gen ».
- Pour chacun, lister les 3 principaux facteurs de coût CPU et une alternative architecturale.
- Implémenter une optimisation « victoire rapide » (sérialisation, cache, batching, vectorisation) et mesurer.
- Ajouter une garde stricte (limites de requêtes, backpressure, bornes de queue) pour éviter les tempêtes de retries.
- Créer une alternative fournisseur/instance pour chaque couche, même si vous ne l’utilisez jamais.
- Intégrer conformité firmware/microcode dans les checks de santé de la flotte.
FAQ
1) Le tick‑tock était‑il une vraie discipline d’ingénierie ou juste du marketing ?
Les deux. Il décrivait une alternance réelle des risques qui aidait l’exécution. Il est aussi devenu un raccourci marketing qui donnait au calendrier une impression de déterminisme exagérée.
2) Pourquoi le tick‑tock a‑t‑il cessé de fonctionner ?
Parce que les rétrécissements de procédé ont cessé d’être « routiniers ». La complexité, les défis de rendement et l’économie des nœuds avancés ont rendu le rythme annuel plus difficile à maintenir.
3) Un rétrécissement de procédé améliore‑t‑il toujours la performance ?
Non. Il améliore souvent le potentiel d’efficacité, mais la performance réelle dépend des objectifs de fréquence, des limites de puissance, de la marge thermique et des choix de conception. Dans les datacenters, la puissance et le refroidissement décident souvent de ce que vous obtenez réellement.
4) Si la cadence d’Intel est peu fiable, doit‑on éviter Intel ?
Ne cédez pas à l’idéologie. Faites de la gestion de risque. Qualifiez au moins une voie alternative (autre fournisseur, autre type d’instance ou autre classe matérielle). Ensuite, achetez ce qui répond à vos besoins avec le moins de risque opérationnel.
5) Comment les mitigations de sécurité se lient‑elles aux échecs du tick‑tock ?
Elles ne « causent » pas les retards de procédé, mais elles ont changé les attentes opérationnelles. Les comparaisons de performance entre générations sont devenues plus difficiles car la baseline inclut microcode et mitigations qui varient selon la plateforme et le temps.
6) Quel enseignement opérationnel pour les équipes SRE ?
Cessez de planifier autour d’un unique uplift promis. Construisez de la marge et des options, maintenez une pipeline de qualification et investissez dans l’efficacité des workloads pour que les refreshs matériels soient additionnels—pas vitaux.
7) « Plus de coeurs » est‑ce un pari sûr quand les gains par coeur ralentissent ?
Seulement pour les workloads qui s’échelonnent et qui ne sont pas limités par la bande passante mémoire. Pour les tiers sensibles à la latence, plus de coeurs peut signifier une fréquence par thread plus basse et plus de contention. Mesurez avant de vous engager.
8) Comment détecter qu’on est limité par la puissance ou la thermique en production ?
Recherchez une MHz plus basse que prévu sous charge, des logs kernel indiquant du throttling et une amélioration de la performance quand vous réduisez la concurrence. Si votre datacenter est au bord de la puissance/refroidissement, la fiche spec CPU n’est qu’une suggestion.
9) Qu’est‑ce qui a remplacé conceptuellement le tick‑tock pour les planificateurs ?
La planification par scénarios plus la qualification continue. Au lieu d’assumer une cadence fixe, supposez de la variance et construisez de la flexibilité opérationnelle : pools multi‑SKU, isolation des workloads et projets d’efficacité.
10) Quel est le changement le plus à fort levier si on est coincé sur une ancienne génération ?
Profiler et supprimer la contention. Verrous, retries et sérialisation inefficace gaspillent plus de CPU que la plupart des équipes n’osent l’admettre, et détruisent aussi la latence tail.
Conclusion : étapes pratiques suivantes
Tick‑tock a été un cadeau pour les opérations parce qu’il rendait l’avenir planifiable. Il a aussi formé une génération de planificateurs à externaliser leur gestion du risque à la cadence d’un fournisseur. Quand la cadence a cassé, elle n’a pas seulement mis en difficulté des roadmaps—elle a exposé des hypothèses fragiles dans les modèles de capacité, les pratiques de qualification et la culture d’ingénierie de la performance.
Faites ceci ensuite :
- Construisez (ou ranimez) une pool de qualification qui teste en continu le prochain hardware, noyau, BIOS et microcode ensemble.
- Réécrivez les plans de capacité en scénarios, pas en une seule ligne de prévision. Attachez une atténuation à chaque scénario.
- Adoptez une règle « preuve baseline » : si vous ne pouvez pas expliquer la performance via fréquence CPU, throttling, mitigations et compteurs de goulot, vous n’avez pas le droit d’accuser la génération CPU.
- Investissez maintenant dans l’efficacité des workloads—surtout la contention et le comportement mémoire—pour ne pas être otage du prochain « tick » qui peut ne jamais arriver.
Tick‑tock n’était jamais une loi de la nature. C’était une stratégie d’exécution. Concevez vos systèmes comme si chaque stratégie—la vôtre et celle de vos fournisseurs—finirait par rencontrer une date limite qu’elle ne pourrait pas tenir.