Choisir un processeur pour cinq ans : achetez en fonction de la charge de travail, pas du logo

Le principe de base : la charge de travail d’abord, le logo ensuite

Un processeur n’est pas un symbole de statut. C’est un contrat : vous vous engagez sur un équilibre précis de cœurs, fréquence,
cache, canaux mémoire, lignes PCIe, limites d’énergie et particularités de la plateforme. Sur cinq ans, ce contrat va soit
garder vos systèmes ennuyeux (dans le bon sens) soit transformer chaque conversation d’évolution en négociation budgétaire.

Achetez en répondant à ces questions avec des preuves :

• Qu’est-ce qui sature en premier ? Cycles CPU, bande passante mémoire, cache, I/O ou réseau ?
• Quel est le SLO critique ? Débit, latence p99, temps de complétion de job, ou coût par unité ?
• Quel est le modèle de concurrence ? Boucle chaude mono-thread, beaucoup de threads indépendants, ou fork/join ?
• Quelle est la « rafale » de la charge ? Peut-on exploiter le turbo/boost, ou vit-on en charge soutenue sur tous les cœurs ?
• Quoi d’autre tournera dessus ? Sidecars, agents, chiffrement, compression, scrubbing, sauvegardes, observabilité.

Ensuite, sélectionnez une plateforme (CPU + carte mère + mémoire + paramètres BIOS par défaut + alimentation/refroidissement) qui sert ces réponses.
Pas l’inverse.

Blague n°1 : Si votre processus de sélection du CPU commence par « mon ami dit », votre prochaine panne se conclura par « mon ami avait tort ».

Faits rapides et histoire qui comptent vraiment

Quelques points concrets — historiques et techniques — qui vous aident à raisonner pourquoi l’achat de CPU moderne paraît étrange :

1. Les fréquences d’horloge ont cessé de croître linéairement au milieu des années 2000 à cause de la densité de puissance et de la dissipation ; l’industrie a basculé massivement vers le multicœur.
2. Les fréquences « Turbo »/boost ont changé la logique d’achat : des pics courts peuvent paraître incroyables dans les benchmarks mais s’effondrer en charge soutenue sur tous les cœurs.
3. Hyper-threading/SMT n’est pas « 2x cœurs » ; c’est un tour d’utilisation qui aide certaines charges et en pénalise d’autres, surtout en cas de contention.
4. NUMA est la taxe silencieuse sur la performance serveur depuis des décennies : la mémoire locale est rapide ; la mémoire distante est « plutôt rapide jusqu’à ce que ce ne soit plus le cas ».
5. Les tailles de cache ont gonflé parce que la mémoire n’a pas suivi ; la latence vers la DRAM reste chère, et beaucoup de charges se retrouvent liées à la latence mémoire.
6. AES-NI et extensions similaires ont rendu le chiffrement assez bon marché pour être « activé par défaut », déplaçant les goulots ailleurs.
7. Les mitigations de spéculation (post-2018) ont rendu les détails microarchitecturaux importants en production ; les niveaux de correctifs peuvent changer les profils de performance.
8. Le nombre de lignes PCIe est devenu une métrique de capacité à part entière alors que NVMe, GPU et smart NICs sont devenus normaux dans des serveurs « usage général ».

Rien de tout cela ne vous dit quelle marque acheter. Cela explique pourquoi un benchmark à un chiffre ne décrit jamais votre futur.

Formes de charge : ce que votre CPU fait réellement

1) Services sensibles à la latence (p95/p99)

APIs web, authentification, enchères publicitaires, données de marché, paiements : la métrique métier est la latence tail. Ces charges ont souvent
de petites boucles chaudes, beaucoup de branchements, et des défauts de cache fréquents causés par de grands ensembles de travail ou le churn d’allocateur.

Ce que vous voulez :

• Forte performance mono-thread (pas seulement un pic turbo sur un cœur, mais soutenue sous charge réaliste).
• Hiérarchie de cache large et efficace ; moins de défauts de cache à l’échelle bat « plus de cœurs » pour la latence tail.
• Comportement de fréquence prédictible sous limites thermiques et d’énergie.
• Une stratégie NUMA claire : épinglez les processus critiques, gardez la mémoire locale, évitez les bavardages inter-socket.

2) Charges orientées débit (batch, ETL, rendu, calcul hors ligne)

Si le temps de complétion compte plus que la latence d’une requête, vous pouvez souvent ajouter des cœurs — jusqu’à ce que la bande passante mémoire ou l’I/O devienne le mur.
Les compilateurs, fermes de build, jobs ETL et certaines analyses aiment le parallélisme, mais seulement s’ils ne se battent pas pour les canaux mémoire.

Ce que vous voulez :

• Plus de cœurs physiques et suffisamment de bande passante mémoire pour les alimenter.
• Performance soutenue sur tous les cœurs sous limites d’énergie, pas des fréquences marketing en rafales.
• Assez de lignes PCIe pour le stockage et le réseau que vous ajouterez inévitablement en cours de cycle.

3) Hôtes de virtualisation et conteneurs (le « mélange »)

Hyperviseurs et nœuds Kubernetes exécutent un zoo : certaines choses sont sensibles à la latence, d’autres liées au CPU, et beaucoup sont bruyantes.
Votre choix de CPU doit minimiser le rayon d’explosion de ce bruit.

Ce que vous voulez :

• Assez de cœurs pour la consolidation, mais pas tellement que vous ne puissiez pas garder la localité par socket sous contrôle.
• Bonne capacité mémoire et canaux ; la surallocation mémoire se transforme en swap, et le swap se transforme en angoisse existentielle.
• Stabilité de plateforme : paramètres BIOS prédictibles, microcode stable, et comportement IOMMU propre pour le passthrough si besoin.

4) Serveurs de stockage (oui, le CPU compte beaucoup)

Les piles de stockage mangent du CPU de façons peu glamour : checksums, compression, parité RAID, chiffrement, déduplication (si vous êtes courageux),
et opérations de métadonnées. ZFS, Ceph, mdraid, LVM, dm-crypt — ce n’est pas gratuit.

Ce que vous voulez :

• Assez de cœurs pour le travail en arrière-plan (scrub, rebalance, compaction) tout en servant l’I/O au premier plan.
• Un sous-système mémoire solide ; l’I/O riche en métadonnées devient lié à la latence mémoire.
• Lignes et topologie PCIe adaptées à votre configuration HBA/NVMe ; « ça rentre dans le slot » n’est pas la même chose que « ça performe ».

5) Calcul spécialisé (transcodage, ML, crypto, compression)

Ce sont les plus faciles à réussir et les plus faciles à foirer. Bien fait : mesurez les instructions utilisées et choisissez la meilleure voie d’accélération
(GPU, Quick Sync, AVX-512, etc.). Mal fait : supposez que la jolie extension vectorielle du CPU est un gain garanti.

Ce que vous voulez :

• Support du jeu d’instructions que votre logiciel utilise réellement (et pour lequel il est compilé).
• Thermiques et alimentation capables de soutenir les charges vectorielles (elles peuvent fortement sous-cadencer).
• Assez d’I/O pour nourrir la bête (NVMe pour les jeux de données, réseau rapide, etc.).

Caractéristiques du CPU qui font la différence (et celles qui ne le font pas)

Cœurs vs fréquence : arrêtez de traiter ça comme un choix binaire

Le nombre de cœurs aide quand vous avez du travail parallèle qui peut rester occupé sans se battre pour des ressources partagées.
La fréquence aide quand un petit nombre de threads dominent la latence ou quand la contention de verrous fait que « plus de threads » n’est souvent que plus de contention.
Sur cinq ans, votre charge va dériver. Mais elle ne basculera généralement pas de « boucle chaude mono-thread » à « parfaitement parallèle ».

L’approche pratique est de classer votre charge par parallélisme effectif :

• 1–4 threads chauds : priorité à la forte performance par cœur et au cache, et gardez la plateforme fraîche.
• 8–32 threads utiles : équilibre fréquence et cœurs, surveillez la bande passante mémoire.
• 64+ threads utiles : cœurs et canaux mémoire dominent ; la topologie et le NUMA deviennent la falaise cachée.

Le cache vaut souvent plus que ce que vous budgétez

Beaucoup de services en production sont « limités CPU » uniquement parce qu’ils sont bloqués sur la mémoire. Si vous voyez un CPI élevé, un IPC faible, et beaucoup de défauts de cache,
un CPU avec plus de cache (ou un meilleur comportement de cache) peut surpasser une puce à fréquence supérieure. C’est la façon la moins sexy de gagner en performance et la plus reproductible.

Canaux mémoire, fréquence et capacité : le limiteur silencieux

Si votre ensemble de travail ne tient pas dans le cache, vous êtes maintenant dans le business de la mémoire. Plus de cœurs sans assez de bande passante mémoire devient
« idling coûteux ». De plus, la capacité mémoire est une fonctionnalité de performance : rester hors du swap et éviter le thrash du page cache bat presque toute mise à niveau CPU.

NUMA et topologie : la performance que vous perdez sans le remarquer

Sur les systèmes double-socket (et même sur certains designs single-socket complexes), la localité mémoire compte. L’accès à la mémoire distante peut ajouter de la latence,
réduire la bande passante et augmenter la variance — visible surtout au p99.

Si vous passez en multi-socket, prévoyez du temps pour :

• Planification NUMA-aware (systemd CPUAffinity, Kubernetes CPU Manager, épinglage de processus DB).
• Valider que vos NICs et périphériques NVMe sont attachés au socket qui exécute la charge.
• Mesurer avec du trafic réel, pas des tests synthétiques qui restent accidentellement dans un seul nœud NUMA.

Lignes PCIe et topologie I/O : le piège dans les serveurs « usage général »

Vous pouvez acheter un CPU avec beaucoup de calcul puis l’étrangler avec l’I/O : trop peu de lignes PCIe, root complexes sursouscrits,
ou des disques NVMe attachés à un switch qui partage la bande passante d’une manière que vous n’aviez pas modélisée. Sur cinq ans, vous ajouterez des NICs, plus de NVMe,
peut-être un GPU, peut-être un DPU. Choisissez une plateforme avec de la marge.

Limites d’alimentation et refroidissement : la performance soutenue est la seule performance

Les CPU n’« ont » pas une fréquence ; ils la négocient avec la physique. Si votre châssis, vos ventilateurs ou la température d’entrée du datacenter sont marginaux,
votre SKU coûteux se transforme en SKU moins performant sous charge. Cela apparaît comme des « benchmarks étrangement incohérents » et plus tard comme « pourquoi la latence a régressé ? »

La marque n’est pas une stratégie

Achetez la pièce qui gagne sur vos métriques, sur votre compilateur/runtime, dans votre enveloppe d’énergie, avec votre chaîne d’approvisionnement. Puis validez.
C’est tout. Le logo, c’est pour la facture.

Blague n°2 : Le meilleur CPU est celui qui ne vous oblige pas à apprendre un nouveau portail fournisseur à 3 h du matin.

Planifier sur cinq ans : ce qui change, ce qui ne change pas

Cinq ans, c’est assez long pour que votre charge évolue et assez court pour que vous exécutiez encore des héritages embarrassants.
La sélection du CPU doit survivre à :

• Mises à jour logicielles qui changent les caractéristiques de performance (nouveau comportement JIT, nouveaux paramètres du moteur de stockage, nouveau scheduler du noyau).
• Régimes de correctifs de sécurité qui peuvent affecter la performance microarchitecturale.
• Nouveaux agents d’observabilité qui « ont juste besoin d’un peu de CPU ». Ils en ont tous besoin.
• Croissance des tailles de jeux de données qui transforme des charges favorables au cache en charges liées à la latence mémoire.
• Dérive de la plateforme : mises à jour BIOS, changements de microcode, et fonctionnalités firmware comme les paramètres de gestion d’énergie.

Achetez de la marge dans la bonne dimension

La marge n’est pas « 50 % de cœurs en plus ». La marge, c’est :

• Capacité mémoire pour pouvoir croître sans swap.
• Bande passante mémoire pour que des cœurs additionnels ne restent pas bloqués.
• Lignes PCIe pour l’expansion sans sursouscription I/O.
• Marge thermique pour que la charge soutenue ne déclenche pas une sous-fréquence.
• Une famille de SKU que vous pouvez encore sourcer à l’année 3 sans supplier.

Préférez les plateformes ennuyeuses quand la disponibilité est le produit

Les plateformes de pointe vont bien quand vous avez un labo, de la capacité de repli et un plan de rollback. Si vous dirigez une équipe légère,
préférez le combo CPU/plateforme avec un firmware prédictible, un support noyau mature et une compatibilité NIC/HBA connue.
Vous n’êtes pas payé en nouveauté.

Une citation, parce que c’est toujours le meilleur conseil ops

L’espoir n’est pas une stratégie. — James Cameron

Elle s’applique embarrassément bien à la planification de capacité et à l’achat de CPU.

Trois mini-histoires d’entreprise du terrain

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a migré sa couche API sur de nouveaux serveurs qui semblaient parfaits sur le papier : plus de cœurs, génération plus récente,
meilleurs scores synthétiques. La charge était un service Java avec un chemin d’authentification chaud et une pile de petites allocations.
Il avait été stable pendant des années.

En quelques jours, la latence p99 a commencé à grimper. Pas la latence moyenne. Pas l’utilisation CPU. Juste le p99, en rafales alignées sur les pics de trafic.
L’équipe a supposé un tuning GC. Ils ont ajusté les tailles de heap, changé de collecteur, roulé en avant puis en arrière. Les pics ont persisté.

La mauvaise hypothèse était que « plus de cœurs » améliore automatiquement la latence tail. En réalité, la nouvelle plateforme avait une topologie NUMA différente,
et leur ordonnanceur de conteneurs plaçait joyeusement le processus sur un socket tandis que les allocations mémoire venaient d’un autre. Ajoutez un peu de contention sur les verrous
et vous obtenez une loterie de latence.

La correction n’a pas été héroïque. Ils ont épinglé les ensembles CPU et la politique mémoire pour les pods critiques, ajusté l’affinité IRQ pour que les files NIC soient
locales au compute, et validé avec des compteurs perf. Les pics p99 ont disparu. Le CPU n’était pas mauvais. L’hypothèse l’était.

Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux

Une équipe de stockage opérant un objet store sur ZFS a décidé qu’ils étaient « lourds en CPU », d’après top qui montrait beaucoup de temps système pendant les pics d’ingestion.
Quelqu’un a proposé d’activer une compression agressive partout et de compter sur les « CPU modernes » pour rendre ça gratuit. Ils l’ont déployé progressivement.

L’ingestion s’est améliorée initialement. Le dashboard paraissait mieux. Puis la fenêtre de scrub hebdomadaire a commencé à chevaucher les heures d’affaires parce que
les scrubs prenaient plus de temps. La latence en lecture est devenue plus bruyante, et quelques clients se sont plaints de timeouts pendant la maintenance de fond.

La compression n’était pas le méchant ; la compression sans limite l’était. Le système jonglait maintenant entre compression au premier plan, checksums de scrub en arrière-plan,
et interruptions réseau sur les mêmes cœurs. Ils avaient accidentellement déplacé le goulot du disque vers l’ordonnancement CPU et la pression sur le cache.

Le rollback a été partiel : ils ont gardé la compression pour les données froides et ajusté recordsize et niveau de compression pour les buckets chauds.
Plus important, ils ont réservé des cœurs pour la maintenance stockage et isolé le traitement des interruptions. La performance est revenue, et les fenêtres de scrub sont redevenues
prévisibles. La leçon : « le CPU est bon marché » est une phrase dangereuse quand vous avez aussi besoin de déterminisme pour la maintenance.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers avait une habitude qui paraissait douloureusement conservatrice : avant d’approuver une nouvelle plateforme CPU, ils faisaient une semaine de canary
en production avec du trafic miroir et des seuils SLO stricts. Les achats détestaient ça. Les ingénieurs râlaient parfois.
Ça ralentissait « l’innovation ». Ça évitait aussi les pannes.

Lors d’un cycle de renouvellement, un nouveau modèle de serveur a passé les benchmarks de base et les tests unitaires mais montrait des pertes de paquets intermittentes sous charge soutenue.
Les pertes étaient assez rares pour que des tests courts les manquent. Le canary les a attrapées parce qu’il a tourné assez longtemps pour atteindre les thermiques réels et les motifs réels des files NIC.

Ils ont travaillé avec le fournisseur et trouvé une interaction firmware + réglage BIOS de gestion d’énergie qui causait de brefs pics de latence dans le traitement des interruptions.
Une mise à jour firmware et un changement de réglage BIOS ont résolu le problème. Aucun client ne l’a vu. Aucun post-mortem n’a été nécessaire.

La pratique n’était pas glamour : long canary, critères d’acceptation ennuyeux, et refus de faire confiance à un unique benchmark.
Voilà à quoi ressemble la « reliability engineering » quand elle fonctionne.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches de terrain que vous pouvez exécuter sur un serveur candidat (ou existant) pour comprendre quel type de CPU vous faut.
Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision que vous en tirez.

Task 1: Identify CPU model, cores, threads, and sockets

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
Model name:                           AMD EPYC 7543 32-Core Processor
NUMA node(s):                         1
L3 cache:                             256 MiB

Ce que cela signifie : Vous connaissez maintenant votre base : 32 cœurs physiques, SMT activé, socket unique, et gros cache L3.

Décision : Si vous avez besoin de latence prédictible, le socket unique simplifie souvent le NUMA. Si votre charge est orientée débit, 32 cœurs peuvent être parfaits — ou limités par la bande passante mémoire. Ne devinez pas ; mesurez.

Task 2: Check CPU frequency behavior under load (governor and scaling)

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1500 MHz and 3700 MHz.
                  The governor "performance" may decide which speed to use
  current CPU frequency: 3692 MHz (asserted by call to hardware)

Ce que cela signifie : Vous n’êtes probablement pas bloqué sur un gouverneur basse consommation. Il y a une marge de fréquence jusqu’à ~3.7 GHz.

Décision : Pour les nœuds sensibles à la latence, utilisez performance et validez les fréquences soutenues sous charge réelle. Si la fréquence s’effondre sous charge, vous avez besoin d’un meilleur refroidissement/limites d’alimentation ou d’un SKU différent.

Task 3: See if you’re CPU-saturated or just “busy”

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 	01/12/2026 	_x86_64_	(64 CPU)

12:00:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:00:02 PM  all   62.10   0.00  10.40    0.20  0.10   1.30    0.00  25.90
12:00:02 PM   0   95.00   0.00   4.00    0.00  0.00   0.00    0.00   1.00
12:00:02 PM   1   10.00   0.00   1.00    0.00  0.00   0.00    0.00  89.00

Ce que cela signifie : Globalement il y a de la marge, mais CPU0 est chaud. C’est un hotspot d’ordonnancement ou d’interruption, pas un « besoin de plus de cœurs ».

Décision : Avant d’acheter un CPU plus gros, corrigez l’épinglage/l’affinité IRQ. Si %idle est proche de zéro sur tous les CPUs et que la charge suit la demande, vous avez peut-être réellement besoin de plus de calcul.

Task 4: Check run queue pressure (are you waiting on CPU?)

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
 8  0      0 802312  11232 9212440    0    0     0    12 5821 9902 64 11 25  0  0
12  0      0 801900  11232 9212600    0    0     0     0 6001 11022 72 12 16  0  0

Ce que cela signifie : r est entre 8 et 12 tâches exécutables. Si cela dépasse constamment le nombre de cœurs, vous êtes saturé CPU. Ici, c’est en dessous de 64 threads mais pourrait être au-dessus des cœurs physiques sur des systèmes plus petits.

Décision : Si r est systématiquement élevé et que la latence augmente, vous avez besoin de plus de cœurs ou d’un meilleur parallélisme. Si wa augmente, vous êtes bloqué sur l’I/O, pas le CPU.

Task 5: Determine if memory bandwidth/latency is the limit

cr0x@server:~$ perf stat -a -e cycles,instructions,cache-misses,LLC-load-misses -I 1000 sleep 3
#           time             counts unit events
     1.000349290    3,210,442,991      cycles
     1.000349290    2,120,112,884      instructions
     1.000349290       45,332,100      cache-misses
     1.000349290       12,501,883      LLC-load-misses

     2.000719401    3,188,102,112      cycles
     2.000719401    2,098,554,001      instructions
     2.000719401       46,110,220      cache-misses
     2.000719401       12,980,004      LLC-load-misses

Ce que cela signifie : Le nombre d’instructions par cycle est autour de 0,65 (2.1B / 3.2B), et les défauts LLC sont significatifs. Ça suggère des stalls mémoire.

Décision : Si votre service est lié aux stalls mémoire, choisissez des CPU avec un meilleur comportement de cache et investissez dans les canaux/vitesse de mémoire. « Plus de GHz » ne résoudra pas les défauts de cache.

Task 6: Check NUMA layout and distances

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 0 size: 257837 MB
node 0 free: 210112 MB
node 1 cpus: 32-63
node 1 size: 257838 MB
node 1 free: 211004 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Ce que cela signifie : Deux nœuds NUMA avec un coût d’accès distant ~2x local (distance 21 vs 10). C’est assez normal, mais ça se verra au p99 si vous l’ignorez.

Décision : Si vous exécutez des services sensibles à la latence, préférez le socket unique ou appliquez la localité NUMA. Si vous devez aller en dual-socket, planifiez l’épinglage et la politique mémoire dès le départ.

Task 7: Map PCIe devices to NUMA nodes (NICs, NVMe, HBAs)

cr0x@server:~$ lspci -vv | grep -E "Ethernet|Non-Volatile|NUMA"
3b:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
	NUMA node: 1
41:00.0 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5]
	NUMA node: 0

Ce que cela signifie : Votre NIC est locale au nœud 0, NVMe au nœud 1. Si votre chemin I/O traverse les sockets, vous venez d’acheter de la variance de latence.

Décision : Alignez les charges avec leurs périphériques I/O (épingler le calcul près du NIC/NVMe) ou déplacez le matériel. Pour de nouveaux achats, choisissez des plateformes avec assez de lignes pour éviter des placements gênants.

Task 8: Identify interrupt hotspots (often mistaken for “CPU needs upgrade”)

cr0x@server:~$ cat /proc/interrupts | head -n 8
           CPU0       CPU1       CPU2       CPU3
  24:  99211231          0          0          0   PCI-MSI 524288-edge      mlx5_comp0@pci:0000:41:00.0
  25:         0   98122010          0          0   PCI-MSI 524289-edge      mlx5_comp1@pci:0000:41:00.0
  26:         0          0   99100110          0   PCI-MSI 524290-edge      mlx5_comp2@pci:0000:41:00.0
  27:         0          0          0   98911220   PCI-MSI 524291-edge      mlx5_comp3@pci:0000:41:00.0

Ce que cela signifie : Les interruptions sont bien réparties ici ; dans beaucoup de systèmes elles ne le sont pas, et un CPU se fait marteler.

Décision : Si les interruptions s’accumulent sur un CPU, corrigez l’affinité IRQ et les paramètres de file avant de changer de CPU. La latence tail s’améliore énormément avec une distribution correcte des interruptions.

Task 9: Check for throttling and thermal limits

cr0x@server:~$ dmesg | grep -iE "thrott|thermal|powercap" | tail -n 5
[ 8921.112233] intel_rapl_common: Found RAPL domain package
[ 9122.445566] CPU0: Core temperature above threshold, cpu clock throttled (total events = 3)
[ 9122.445700] CPU0: Package temperature/speed normal

Ce que cela signifie : Vous subissez des throttlings occasionnels. C’est une variabilité de performance que vous ressentirez au p99.

Décision : Si le throttling apparaît sous charge normale, corrigez le refroidissement, les courbes de ventilateur, le contact du heatsink, ou les limites d’alimentation. Si vous ne pouvez pas, n’achetez pas le SKU haut de gamme qui performe seulement en laboratoire idéal.

Task 10: Validate virtualization overhead and steal time

cr0x@server:~$ mpstat 1 3 | tail -n 3
12:10:02 PM  all  40.00   0.00   8.00   0.00   0.00   0.50   7.50  44.00
12:10:03 PM  all  42.00   0.00   9.00   0.00   0.00   0.40   8.20  40.40
12:10:04 PM  all  41.50   0.00   8.80   0.00   0.00   0.60   8.10  41.00

Ce que cela signifie : %steal autour de 8% indique que votre VM attend parce que l’hyperviseur est sursouscrit ou que des voisins bruyants existent.

Décision : Ne « corrigez » pas le steal time en augmentant le CPU invité. Corrigez la sursouscription hôte, réservez du CPU, ou déplacez les charges. Pour l’achat, assurez-vous que les hôtes ont assez de cœurs réels pour vos objectifs de consolidation.

Task 11: Determine if storage is stealing your cycles (ZFS example)

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        7.21T  3.12T    980  4.20K  112M  610M
  raidz2    7.21T  3.12T    980  4.20K  112M  610M
    nvme0n1     -      -    120    520  14.0M 72.0M
    nvme1n1     -      -    118    525  13.8M 72.5M
    nvme2n1     -      -    121    515  14.2M 71.2M
    nvme3n1     -      -    119    518  13.9M 71.8M

Ce que cela signifie : Vous poussez 610 MB/s en écritures avec 4.2K ops/s. Si le CPU est aussi élevé, le checksumming/compression/parité peut être le limiteur, pas les disques.

Décision : Pour les serveurs de stockage, favorisez des CPU avec assez de cœurs pour la maintenance et les services de données, et assurez-vous que la mémoire est abondante. Si le débit d’écriture plafonne avec le CPU saturé, vous avez besoin de plus de CPU ou de choix RAID/compression différents.

Task 12: Measure network processing load (softirq pressure)

cr0x@server:~$ sar -n DEV 1 3
Linux 6.5.0 (server) 	01/12/2026 	_x86_64_	(64 CPU)

12:15:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s
12:15:02 PM      eth0   120000    118500   980000    910000
12:15:03 PM      eth0   121200    119100   990500    915200

Ce que cela signifie : Très fort taux de paquets. C’est du travail CPU (softirq, interruptions), pas seulement de la bande passante réseau.

Décision : Si le taux de paquets est élevé, choisissez des CPU avec une forte performance par cœur et assurez la configuration correcte des files NIC/affinité IRQ. Parfois, moins de cœurs plus rapides battent plus de cœurs plus lents pour les charges orientées paquets.

Task 13: Check context switching and scheduler churn

cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0 (server) 	01/12/2026 	_x86_64_	(64 CPU)

12:18:01 PM   UID       PID   cswch/s nvcswch/s  Command
12:18:02 PM     0      1221    1200.00    300.00  kubelet
12:18:02 PM   999      3456   22000.00   9000.00  java

Ce que cela signifie : Nombre élevé de context switches volontaires et involontaires. C’est souvent de la contention sur des verrous, trop de threads, ou de l’ordonnancement bruyant.

Décision : Avant d’ajouter des cœurs, réduisez le nombre de threads, ajustez les runtimes, ou isolez les charges. Si vous ne pouvez pas, préférez une meilleure performance par cœur et moins de migrations inter-NUMA.

Task 14: Confirm kernel sees correct mitigations (performance can shift)

cr0x@server:~$ grep -E "Mitigation|Vulnerable" /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; STIBP: disabled; RSB filling

Ce que cela signifie : Vous ne pouvez pas ignorer les mitigations de sécurité ; elles influencent les charges riches en appels système et en changements de contexte.

Décision : Pour les services intensifs en syscalls, mesurez la performance avec les mitigations réelles que vous exécuterez en production. Ne benchmarkez pas une configuration noyau de labo que vous n’allez pas déployer.

Playbook de diagnostic rapide : trouver le goulot vite

Quand quelque chose est lent et que tout le monde commence à se disputer sur les CPU, vous avez besoin d’un playbook court qui coupe le bruit.
Cette séquence est conçue pour le triage en production : outils minimaux, signal maximal.

Première étape : décidez si vous êtes CPU-bound, IO-bound, ou en attente d’autre chose

• Exécutez mpstat pour voir idle, iowait et steal time.
• Exécutez vmstat pour voir la file exécutable r et l’attente wa.
• Vérifiez la charge moyenne avec uptime, mais ne la prenez pas pour vérité — prenez-la comme fumée.

Si %idle est bas et r est élevé, vous êtes probablement CPU-bound.
Si %iowait est élevé ou des processus bloqués apparaissent, vous êtes IO-bound.
Si %steal est élevé dans des VM, vous êtes dépouillé par l’hyperviseur.

Deuxième étape : classez la douleur CPU (calcul vs mémoire vs ordonnanceur)

• Utilisez perf stat pour IPC et défauts de cache. IPC faible + beaucoup de défauts suggère des stalls mémoire.
• Utilisez pidstat -w pour les changements de contexte. Beaucoup de switches suggèrent de la contention ou trop de threads.
• Vérifiez NUMA avec numactl --hardware et le placement des périphériques avec lspci.

Troisième étape : cherchez les pièges spécifiques à la plateforme

• Throttling dans dmesg (thermique/powercap).
• Déséquilibre d’interruptions dans /proc/interrupts.
• Mauvais gouverneur de fréquence dans cpupower frequency-info.
• Steal time de virtualisation : corrigez le dimensionnement hôte, pas les CPUs invités.

Quatrième étape : décidez quoi changer

• Si c’est CPU-saturé et que ça suit la demande : ajoutez des cœurs ou scindez le service.
• Si c’est stalls mémoire : priorisez le cache/les canaux mémoire ; envisagez moins de cœurs plus rapides plutôt que beaucoup de cœurs lents.
• Si c’est NUMA/topologie : épinglez, alignez les périphériques, ou préférez le socket unique pour les couches latence.
• Si c’est thermique/énergie : corrigez le refroidissement ou cessez d’acheter des SKU que vous ne pouvez pas soutenir.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: p99 latency regresses after “upgrade”

Cause racine : Accès mémoire NUMA distant, IRQs sur le mauvais socket, ou instabilité de fréquence sous charge.

Correction : Épinglez processus et mémoire, alignez NIC/NVMe sur le même nœud NUMA, définissez le gouverneur approprié, et vérifiez qu’il n’y a pas d’événements de throttling.

2) Symptom: CPU usage is high, but throughput doesn’t improve with more cores

Cause racine : Limite de bande passante mémoire, contention de verrous, ou thrash de cache. Plus de cœurs augmentent la contention et les stalls.

Correction : Mesurez IPC et défauts de cache, réduisez le nombre de threads, shardez ou partitionnez le travail, ou choisissez un CPU avec un meilleur cache/sous-système mémoire au lieu de plus de cœurs.

3) Symptom: “Random” spikes during peak traffic

Cause racine : Tempêtes d’interruptions, voisins bruyants (steal VM), tâches en arrière-plan (scrub, compaction), ou throttling thermique.

Correction : Isolez des cœurs pour IRQs et travail en arrière-plan, réservez du CPU, exécutez de longs canaries, et auditez les thermiques sous charge soutenue.

4) Symptom: Load average is high, but CPU is not busy

Cause racine : Tâches bloquées en I/O, latence de stockage, ou attentes noyau ; la charge moyenne compte les tâches exécutables et non-interruptibles.

Correction : Vérifiez %iowait, les stats de stockage, et les processus bloqués. Mettez à niveau le stockage ou corrigez le chemin I/O ; n’achetez pas des CPUs pour compenser des disques lents.

5) Symptom: Storage server can’t hit expected NVMe speeds

Cause racine : Sursouscription de la topologie PCIe, mauvais branchement de slot, root complex partagé, ou overhead CPU pour checksums/parité/chiffrement.

Correction : Validez le placement PCIe, assurez-vous d’assez de lignes, mesurez le coût CPU des fonctionnalités de stockage, et réservez du CPU pour la maintenance en arrière-plan.

6) Symptom: Benchmark looks great, production looks mediocre

Cause racine : Le benchmark utilise un seul thread, tient dans le cache, ou tourne 30 secondes. La production tourne des jours et manque le cache toute la journée.

Correction : Benchmarkez avec des jeux de données, la concurrence et la durée de run réalistes. Utilisez des canaries de production et des portes SLO.

7) Symptom: Performance changes after firmware/microcode update

Cause racine : Changements de valeurs par défaut de gestion d’énergie, comportement des mitigations, ou interactions avec l’ordonnanceur.

Correction : Traitez le firmware comme une release : testez, mesurez, épinglez les paramètres BIOS, et documentez la configuration « connue bonne » pour votre flotte.

Listes de contrôle / plan étape par étape

Étape par étape : choisir le bon CPU pour un horizon de cinq ans

1. Notez le véritable mix de charges. Incluez les tâches en arrière-plan (sauvegardes, scrubs, compaction, agents d’observabilité).
2. Définissez les métriques de succès. Débit, latence p99, coût par requête, temps de complétion. Choisissez deux, pas dix.
3. Capturez les preuves du goulot actuel. Utilisez mpstat, vmstat, perf stat, NUMA et le mapping I/O.
4. Classez la forme de la charge. Sensible à la latence vs débit vs virtualisation mixte vs stockage intensif.
5. Choisissez d’abord les contraintes de plateforme. Socket unique vs dual, canaux/capacité mémoire, lignes PCIe, plan NIC/HBA, puissance et refroidissement du rack.
6. Sélectionnez 2–3 SKU candidats. Un « sûr », un « performance », un « optimisé coût ».
7. Exécutez des benchmarks réalistes. Même paramètres noyau, mêmes mitigations, même taille de dataset, même durée d’exécution.
8. Faites un canary en production. Miroir du trafic, durée suffisante pour atteindre les thermiques et cycles de maintenance.
9. Verrouillez les paramètres BIOS et firmware. Documentez-les. Rendez-les reproductibles sur toute la flotte.
10. Décidez avec une justification écrite. Incluez ce que vous optimisez, ce que vous sacrifiez, et les preuves.

Checklist : ne vous faites pas surprendre à l’année 3

• Emplacements mémoire libres pour l’extension, pas remplis dès le jour 1 sauf si nécessaire.
• Marge de lignes PCIe pour ajouter NVMe ou NICs plus rapides plus tard.
• Marge de refroidissement testée en charge soutenue dans votre châssis réel.
• Capacité de repli pour la maintenance en arrière-plan (scrubs, compaction, indexation, sauvegardes).
• Vérification de la chaîne d’approvisionnement : pouvez-vous acheter la même plateforme plus tard ?
• Préparation des outils opérationnels : pouvez-vous observer l’utilisation par cœur, le throttling et les problèmes NUMA ?

Checklist : paramètres de plateforme à standardiser (pour éviter la dérive de performance)

• Gouverneur CPU / profil d’alimentation
• Politique SMT (on/off) par classe de charge
• Politique d’équilibrage NUMA et stratégie d’épinglage
• Affinité IRQ et configuration des files NIC
• Stratégie d’épinglage des versions de microcode et firmware
• Politique de mitigations noyau cohérente avec la posture de sécurité

FAQ

1) Dois-je acheter le plus grand nombre de cœurs possible pour « préparer l’avenir » ?

Non. Achetez le bon mélange. Un nombre élevé de cœurs sans bande passante mémoire ni efficacité de cache rend souvent le p99 pire et le coût plus élevé.
Préparer l’avenir, c’est généralement capacité mémoire + marge PCIe + performance soutenue prévisible.

2) Le socket unique est-il toujours préférable au dual-socket ?

Pour les couches sensibles à la latence, le socket unique est souvent plus facile à bien exploiter car vous réduisez la complexité NUMA.
Pour le calcul orienté débit ou des besoins massifs en mémoire, le dual-socket peut être correct — si vous vous engagez à des opérations conscientes de NUMA.

3) Dois-je activer SMT/Hyper-Threading ?

Ça dépend. SMT peut améliorer le débit pour certaines charges mixtes. Il peut aussi augmenter la contention et la gigue pour les services sensibles à la latence tail.
Testez les deux modes sur une charge réaliste ; choisissez par rôle de cluster, pas comme règle universelle.

4) Comment savoir si ma charge est liée à la latence mémoire ?

IPC faible, beaucoup de défauts de cache/LLC, et mauvaise montée en charge avec plus de cœurs sont des signes classiques. Utilisez perf stat pour vérifier instructions vs cycles et défauts de cache,
et validez avec des tailles de dataset correspondant à la production.

5) Les benchmarks synthétiques sont-ils inutiles ?

Pas inutiles — dangereux quand utilisés seuls. Ils servent à détecter des régressions évidentes et des défauts matériels.
Ils prédisent mal la latence tail, les effets NUMA, les problèmes de topologie I/O et le comportement thermique soutenu.

6) Qu’est-ce qui compte le plus pour les hôtes de virtualisation : cœurs ou fréquence ?

Les deux, mais ne négligez pas la mémoire. La consolidation a besoin de cœurs ; les locataires bruyants et l’overhead réseau/stockage punissent souvent une faible performance par cœur.
Pour des charges mixtes, vous voulez généralement un CPU équilibré plus une forte capacité et bande passante mémoire.

7) Si nous utilisons ZFS ou Ceph, devons-nous prioriser le CPU plus que d’habitude ?

Oui. Les fonctionnalités modernes de stockage consomment du CPU : checksums, compression, chiffrement, parité, et maintenance en arrière-plan.
Priorisez aussi la mémoire (ARC, métadonnées, cache) et la topologie PCIe pour que vos disques rapides ne soient pas limités en amont.

8) Quand est-il rationnel de payer pour des pièces « top bin » ?

Quand vous êtes contraint par la latence d’un petit nombre de threads chauds, et que vous pouvez garder le CPU assez refroidi pour soutenir des horloges élevées.
Si votre châssis ou datacenter ne peut pas le soutenir, la prime revient surtout à la physique.

9) Comment penser à la consommation d’énergie sur cinq ans ?

L’énergie n’est pas que du coût ; c’est aussi la stabilité de performance. Une plateforme toujours au bord de ses limites de puissance/thermiques sera bruyante.
Choisissez un CPU qui délivre la performance requise dans la réalité de votre puissance et refroidissement rack, pas dans une brochure.

10) Quel est le plus grand indice que nous choisissons des CPUs par logo ?

Quand l’évaluation s’arrête à « ce benchmark est plus élevé », sans préciser quelle métrique vous optimisez (p99 vs débit) et sans plan de canary.
Si vous ne pouvez pas décrire votre goulot avec des mesures, vous magasinez émotionnellement.

Prochaines étapes réalisables cette semaine

Si vous voulez une décision CPU que vous ne regretterez pas pendant cinq ans, faites le travail ingrat maintenant :

1. Profilez un hôte représentatif en utilisant les commandes ci-dessus et notez ce qui vous limite réellement.
2. Décidez votre métrique principale : latence p99, débit, ou coût par unité. Choisissez une primaire et une secondaire.
3. Construisez une liste de 2–3 CPU candidats et incluez les contraintes de plateforme : canaux mémoire, lignes PCIe, et refroidissement.
4. Exécutez un test long (heures, pas minutes). Incluez la maintenance en arrière-plan (scrub, sauvegardes, compaction) dans la fenêtre de test.
5. Canary en production avec trafic miroir et un switch de rollback. Ennuyeux, oui. Efficace, absolument.
6. Documentez la décision avec des preuves : ce que vous avez mesuré, ce que vous avez choisi, et ce que vous n’avez délibérément pas optimisé.

L’objectif n’est pas de choisir le « meilleur » CPU. L’objectif est de choisir le processeur qui rendra vos workloads ennuyeux à exploiter, pour longtemps.