Pentium II / III : l’âge d’or où la fréquence avait encore du sens

Vous vous souvenez de la sensation : un collègue dit « on peut juste acheter un processeur plus rapide », et vous entendez presque le ticket d’achat se remplir tout seul.
En 2026, cette phrase est souvent un piège. Les systèmes modernes sont un comité de goulets d’étranglement : latence mémoire, défauts de cache,
topologie NUMA, files d’attente de stockage, surcharge de virtualisation, throttling thermique, et une douzaine de gouverneurs cachés qui ignorent poliment vos intentions.

Mais à l’époque du Pentium II / Pentium III, on pouvait souvent pointer un nombre en MHz et — dans une certaine mesure — prédire les résultats. Pas parce qu’Intel était magique,
mais parce que les contraintes de la machine étaient lisibles. Les goulets d’étranglement étaient bruyants, linéaires, et fréquemment réparables avec un tournevis, un réglage du BIOS,
ou le simple acte d’acheter la bonne RAM.

Pourquoi la fréquence « avait du sens » sur Pentium II/III

Dire « les MHz importaient » ne signifie pas « les MHz étaient la vérité ». Cela signifie que le modèle de performance du système avait moins de degrés de liberté.
Vous aviez un CPU monocœur avec une relation relativement directe entre fréquence et débit, un front-side bus (FSB) facile à saturer et donc facile à reconnaître, et un stockage
suffisamment lent pour que tout le monde sache qu’il était lent.

Les Pentium II et Pentium III vivaient dans un monde où :

• La plupart des charges serveurs étaient mono-thread ou faiblement threadées, donc la vitesse d’un seul cœur faisait la une.
• Les CPU ne changeaient pas constamment de fréquence en réponse aux enveloppes thermiques et aux objectifs d’énergie.
• Les tailles et différences de vitesse des caches étaient importantes et visibles — parfois douloureusement.
• Le sous-système mémoire était plus simple : pas de NUMA en escargot, pas de course aux canaux mémoire par socket, moins de couches d’abstraction.

Cette simplicité n’est pas de la nostalgie. C’est un avantage diagnostique. Si vous apprenez à raisonner sur les goulets d’étranglement du Pentium II/III,
vous deviendrez meilleur pour diagnostiquer les plus modernes et plus désordonnés — parce que vous cesserez de deviner et commencerez à mesurer le chemin : CPU → cache → mémoire → bus → disque → réseau.

Une citation, car elle fait encore mouche de la bonne façon. La maxime bien connue de Gene Kim sur la fiabilité est souvent citée ; voici une idée paraphrasée :
Éliminez le travail ingrat en rendant le travail visible, répétable et mesurable ; les actions héroïques sont un mode d’échec, pas une stratégie. — Gene Kim (idée paraphrasée)

9 faits qui expliquent l’époque

• Slot 1 n’était pas de la mode, c’était de la logistique : le Pentium II était livré dans une cartouche (SECC) avec des puces de cache sur le module, pas sur la carte mère.
• Le cache L2 tournait souvent à la moitié de la fréquence du cœur : Beaucoup de Pentium II avaient un L2 externe à 1/2 de la fréquence CPU, ce qui rendait le comportement du cache visible par les humains.
• Pentium III « Coppermine » a apporté le L2 sur puce : L’intégration d’un L2 à pleine vitesse a été une grande raison pour laquelle « même nombre de MHz » pouvait encore signifier « processeur plus rapide ».
• Le FSB était un chiffre public que l’on pouvait saturer : Les choix 66/100/133 MHz du FSB étaient de vraies décisions d’architecture, pas de la fine impression marketing.
• AGP a changé la réactivité des postes : Déplacer la partie graphique hors du PCI vers l’AGP a réduit la contention et rendu la « réactivité du bureau » mesurable d’une nouvelle manière.
• SSE est arrivé et comptait pour certains codes : Le SSE du Pentium III pouvait vraiment accélérer le multimédia et certains calculs scientifiques — si le logiciel l’utilisait.
• La SDRAM PC100/PC133 faisait de la mémoire un choix de SKU : Vous pouviez acheter la mauvaise RAM et passer l’année suivante à prétendre que le système d’exploitation était « gonflé ».
• Les modes DMA IDE étaient une falaise de performance : Un disque mal configuré tombant en PIO pouvait transformer une montée en gamme CPU en générateur de plaintes.
• Les thermiques étaient plus simples mais présentes : Les ventilateurs tombaient en panne, les radiateurs se desserraient, et « ça plante aléatoirement » signifiait souvent « ça cuit ».

La visite d’architecture pratique : ce qui vous limitait réellement

1) Le cœur CPU : l’IPC avant que ce soit un mot à la mode

Les Pentium II et III étaient des cœurs out-of-order avec une prédiction de branche décente pour l’époque, mais vous pouviez encore les raisonner ainsi :
« Combien d’instructions utiles par cycle mon workload retire-t-il, et qu’est-ce qui le bloque ? »
Le mot clé est « retire ». Vous pouvez tourner à 1 GHz et ne rien faire d’utile si vous passez votre vie à attendre la mémoire.

Ce qui rendait la fréquence signifiante, c’est que beaucoup de charges communes se trouvaient dans la zone « suffisamment liées au calcul » :
compression, certaines requêtes de base de données avec index chauds, petits services en C, et la charge bureautique générale où l’ensemble de travail n’était pas énorme.
Vous observiez des améliorations qui suivaient l’augmentation des fréquences parce que le cœur n’était pas en permanence affamé.

2) Cache : le professeur le plus bruyant du bâtiment

À cette époque, le cache était un coup de théâtre que l’on ressentait. Grand ensemble de travail ? La performance chutait brutalement.
Petit ensemble de travail ? Le CPU ressemblait à un super-héros.

La conception du Pentium II avec L2 hors puce souvent à demi-vitesse rendait cela brutalement évident :
le cache n’était pas une fonctionnalité magique. C’était un composant de performance de première classe.
Quand le Pentium III Coppermine a déplacé le L2 sur puce et à pleine vitesse, il n’a pas juste « amélioré la performance ».
Il a changé la forme de la performance. La latence a chuté, la bande passante a augmenté, et les charges avec des accès mémoire répétés ont eu un vrai gain.

Si vous avez déjà vu un service moderne se dégrader parce que son ensemble de travail ne tient plus dans le LLC, vous avez déjà vécu la même histoire — juste avec des graphiques plus sophistiqués.

3) Front-side bus : le couloir partagé où tout le monde se bat

Le FSB était le couloir partagé entre le CPU et le northbridge (contrôleur mémoire et amis). Le CPU pouvait être rapide ;
le couloir pouvait rester étroit. C’est pourquoi 100→133 MHz sur le FSB n’était pas une erreur d’arrondi — c’était un changement structurel sur la rapidité à laquelle le CPU pouvait être alimenté.

Les systèmes modernes cachent cela derrière des contrôleurs mémoire intégrés et plusieurs canaux, mais le concept persiste :
il existe toujours un « couloir ». Aujourd’hui, cela peut être une limite de canal mémoire, un lien NUMA, un root complex PCIe,
ou une profondeur de file d’attente du contrôleur de stockage que tout le monde prétend infinie jusqu’à ce qu’elle ne le soit plus.

4) Stockage et E/S : quand le disque avouait honnêtement qu’il était lent

Les disques de la fin des années 90 n’étaient pas subtils. Si votre charge touchait le disque, vous le saviez. Le noyau le savait. Les utilisateurs le savaient.
Cette franchise était éducative : elle vous obligeait à reconnaître les E/S comme une ressource de première classe, pas une pensée après coup.

Quand les gens disent « les systèmes étaient plus rapides à l’époque », ce qu’ils veulent souvent dire est : « le profil de performance était cohérent ».
La latence disque était toujours affreuse, mais affreusement prévisible. Aujourd’hui, les SSD sont assez rapides pour masquer les fautes de conception jusqu’à ce qu’ils ne le puissent plus.
Alors vous obtenez des queues de latence qui ressemblent à un sismographe pendant un petit apocalypse.

Blague n°1 : À l’époque du Pentium II, « migrer vers le cloud » signifiait déplacer la tour beige loin de la fenêtre pour que la pluie n’atteigne pas le modem.

Charges de travail qui évoluaient avec les MHz — et celles qui n’en bénéficiaient pas

Bien évolué : boucles serrées, petits ensembles de travail, branches prévisibles

Si vous aviez une charge CPU-bound avec des données qui restaient chaudes dans le cache, les augmentations de MHz ressemblaient à une vraie productivité.
Pensez à : compilations classiques, petites charges web, et certains noyaux numériques.
Le SSE du Pentium III vous a aussi donné un véritable second axe : certains codes devenaient plus rapides sans augmenter les MHz,
mais seulement si le code était écrit ou compilé pour utiliser le SSE.

Ne s’améliorait pas : charges liées à la mémoire, au bus et aux E/S

Le FSB et le sous-système mémoire pouvaient absolument vous clouer. Certaines mises à niveau étaient comme mettre un moteur plus gros dans une voiture avec le frein à main à moitié serré :
vous obteniez plus de bruit, plus de chaleur, et exactement le même temps de trajet.

Les charges liées au disque étaient l’exemple classique. Vous pouviez doubler la fréquence CPU et continuer à attendre des recherches.
Votre travail en tant qu’opérateur était d’arrêter de confondre « utilisation CPU » avec « le CPU est le goulet d’étranglement ».

La règle empirique « la fréquence avait du sens » (avec un avertissement)

Voici la version utile en opérationnel :

• Si le CPU est presque saturé et que la charge n’est pas bloquée sur des E/S ou la mémoire, des horloges plus rapides aident.
• Si le CPU est peu utilisé mais la latence est élevée, la fréquence est une distraction — mesurez les files d’attente et les stalls.
• Si le CPU est haut mais que l’iowait est également élevé, vous brûlez probablement des cycles en attendant.

L’étiquette d’avertissement : même à cette époque, le cache et le FSB pouvaient invalider une comparaison naïve de MHz.
Ce n’est pas une contradiction. C’est le point : la performance est une pipeline, et les MHz ne décrivent qu’une étape.

Trois mini-histoires d’entreprise tirées du terrain

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

Une entreprise de taille moyenne faisait tourner un système de saisie de commandes interne sur une paire de serveurs x86 vieillissants. Le service était « correct » jusqu’à la fin du mois, quand
les utilisateurs se plaignaient que l’enregistrement d’une commande prenait 20–40 secondes. L’équipe ops fit la chose habituelle : regarda le CPU et vit qu’il n’était qu’à 30–40 %.
Ils supposèrent que la base de données était « sous-utilisée » et décidèrent qu’une montée en gamme CPU serait bon marché et sûre.

Les nouvelles machines arrivèrent avec des CPU plus rapides mais la même disposition disque copiée. La fin du mois arriva, et les tickets revinrent — mêmes symptômes, timings légèrement différents.
L’équipe fit ensuite la seconde mauvaise hypothèse : « peut-être que c’est le réseau ». Ils changèrent des switches. Rien ne changea.

Un ingénieur plus têtu finit par profiler correctement le système et remarqua que le processus DB se bloquait par courtes rafales,
et que la file d’attente de stockage faisait des pics. Le vrai coupable était une requête de rapport mal indexée qui se déclenchait en fin de mois et pilait le disque.
Le CPU n’était pas inactif parce qu’il n’y avait rien à calculer ; il était inactif parce que le processus attendait.

La réparation n’était pas héroïque : ajouter le bon index, déplacer le job de rapport hors-pointe, et séparer données et logs sur des disques différents.
L’amélioration de performance fut spectaculaire, et l’upgrade CPU était… correcte, mais sans importance.

La leçon : « CPU faible » ne veut pas dire « le CPU n’est pas impliqué ». Cela signifie que votre charge est bloquée ailleurs. Mesurez d’abord cet « ailleurs ».

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

Une équipe gérant un serveur d’application legacy tenta d’améliorer les temps de réponse en activant un réglage agressif du writeback du système de fichiers.
L’idée semblait plausible : bufferiser plus d’écritures, les regrouper, réduire le churn disque. Ils ont tweaké des paramètres kernel et célébré
lorsque des benchmarks synthétiques s’améliorèrent.

La production ne s’est pas souciée de leurs benchmarks synthétiques. Sous trafic réel, l’appli produisait des logs par rafales.
Le système a commencé à accumuler des pages dirty plus vite qu’il ne pouvait les flush, puis est arrivé un orage de writeback.
Les latences ont explosé. Les utilisateurs ont subi des timeouts. Le CPU paraissait occupé pendant l’orage, mais il travaillait au kernel — threads de flush, reclaim, et ordonnancement I/O.

Ils sont revenus en arrière sur le tuning et se sont stabilisés, mais l’incident a laissé une cicatrice : leur « optimisation » avait déplacé la douleur,
créant moins de petites pauses constantes mais une énorme pause périodique, exactement ce que remarquent les utilisateurs.

La leçon : les optimisations qui lissent les graphiques peuvent aggraver la latence tail. Si vous réglez le buffering, vous réglez quand vous payez vos factures — pas si vous les payez.

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

Une autre entreprise gérait une ferme de build interne qui compilait de grands projets C/C++ pendant la nuit. Rien de glamour. Un soir, les temps de build ont doublé,
et l’on-call a été paginé parce que les jobs en aval rataient leurs fenêtres.

L’on-call n’a pas commencé par des théories. Il a commencé par son runbook ennuyeux : vérifier la mise à l’échelle de fréquence CPU, vérifier la santé disque, vérifier les erreurs mémoire,
vérifier les changements récents. Il s’est avéré qu’une mise à jour firmware avait réinitialisé les réglages BIOS et réactivé un mode power conservateur.
Les CPU étaient bloqués sur un état de fréquence plus bas sous charge. Personne ne l’avait remarqué car les machines « fonctionnaient », juste plus lentes.

Parce qu’ils avaient une base de référence (durées de build précédentes, comportement de fréquence CPU antérieur, et une copie stockée des réglages BIOS attendus),
ils ont rétabli le profil BIOS et restauré la performance en moins d’une heure. Pas d’échange hardware. Pas de « réconception du pipeline ».

La leçon : les baselines ennuyeuses battent les suppositions excitantes. L’outil de performance le plus fiable, ce sont les chiffres connus d’hier.

Blague n°2 : Faire des benchmarks sans contexte production, c’est comme minuter un exercice d’évacuation pour prouver que votre immeuble ne prend pas feu.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ces tâches sont écrites pour Linux parce que c’est là que se trouve la plupart de la mémoire musculaire SRE, mais le modèle mental se transpose proprement à tout OS :
identifier la saturation, les files et les stalls. Chaque tâche inclut une commande réaliste, une sortie exemple, ce que cela signifie, et la décision à prendre.

Task 1: Confirm CPU model, MHz, and flags (SSE matters historically)

cr0x@server:~$ lscpu | egrep 'Model name|CPU MHz|Flags|L1d|L2|L3|Socket|Core'
Model name:                           Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU MHz:                              2394.454
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc
L1d cache:                            32K
L2 cache:                             256K
L3 cache:                             35M
Socket(s):                            2
Core(s) per socket:                   14

Ce que cela signifie : Vous avez l’identité du CPU et la topologie des caches. Historiquement, la présence/absence de SSE changeait la performance pour certains workloads.

Décision : Si une charge prétend utiliser le SIMD, vérifiez les flags. Si les caches sont petits par rapport à l’ensemble de travail, attendez-vous à des miss et à des stalls mémoire.

Task 2: Check if CPUs are throttling or stuck at low frequency

cr0x@server:~$ sudo cpupower frequency-info | egrep 'driver|governor|current policy|current CPU frequency'
  driver: intel_pstate
  current policy: frequency should be within 1200 MHz and 3000 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Ce que cela signifie : Sous charge, vous pouvez être toujours bloqué à une faible fréquence. « powersave » avec intel_pstate peut être acceptable, mais « asserted » à 1200 MHz est suspect si vous êtes lent.

Décision : Si la performance a régressé après des changements firmware/BIOS, testez temporairement avec le governor « performance » et comparez.

Task 3: See if the system is CPU-bound, I/O-bound, or waiting (vmstat)

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
 2  0      0 812344  65284 9321440    0    0   112   398  812 2211 22  6 67  5  0
 6  1      0 799120  65284 9329900    0    0   124  4120  910 3102 28  7 44 21  0
 5  2      0 792884  65284 9321024    0    0    96  3856  901 2904 24  6 40 30  0
 3  0      0 806220  65284 9334500    0    0    88   512  780 2401 20  5 73  2  0
 7  3      0 790004  65284 9320044    0    0   144  4096  950 3200 26  7 39 28  0

Ce que cela signifie : Le champ « wa » (iowait) monte à 21–30 %. « b » processus bloqués >0. C’est une pression I/O classique.

Décision : Arrêtez de parler d’upgrade CPU. Allez voir les métriques disque et système de fichiers (iostat, pidstat, profondeurs de file de stockage).

Task 4: Identify disk saturation and latency (iostat)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          21.3    0.0     6.2    18.9     0.0    53.6

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  r_await  w_await
nvme0n1         120.0   980.0  6400.0 52000.0    0.0    0.0   98.7   14.2     2.1     15.7
sdb               0.0   220.0     0.0  8800.0    0.0   40.0   96.1   42.8     0.0     42.8

Ce que cela signifie : Deux périphériques sont près de 100 % d’utilisation. « await » est élevé sur sdb (42,8 ms). C’est une latence visible par l’utilisateur.

Décision : Si c’est un volume de logs ou de base de données, séparez les chemins d’écriture chauds, corrigez les paramètres de sync, ou migrez vers un stockage plus rapide avant d’ajuster les threads applicatifs.

Task 5: Find which process is causing I/O wait (pidstat)

cr0x@server:~$ pidstat -d 1 5
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

03:10:11 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
03:10:12 PM  1001     18422      0.00  18240.00      0.00     120  postgres
03:10:12 PM     0      1223      0.00   6400.00      0.00      80  systemd-journald
03:10:12 PM  1002     22019    512.00    128.00      0.00      10  nginx

Ce que cela signifie : Postgres et journald sont de gros écrivains. iodelay est élevé.

Décision : Si journald bruite beaucoup, limitez son débit ou déplacez les logs. Pour Postgres, vérifiez checkpoints, emplacement WAL, et comportement fsync.

Task 6: Measure context switches and run queue pressure (pidstat -w)

cr0x@server:~$ pidstat -w 1 3
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

03:11:02 PM   UID       PID   cswch/s nvcswch/s  Command
03:11:03 PM  1001     18422    220.00    980.00  postgres
03:11:03 PM  1003     19110  12000.00  31000.00  java

Ce que cela signifie : Java effectue beaucoup de context switches. Cela peut venir d’une contention sur des locks, trop de threads, ou du comportement du GC.

Décision : Le tuning des threads peut aider, mais seulement après avoir vérifié si le CPU est réellement saturé ou bloqué.

Task 7: Confirm memory pressure and major faults (sar)

cr0x@server:~$ sar -B 1 3
Linux 6.5.0-18-generic (server) 	01/09/2026 	_x86_64_	(56 CPU)

03:11:40 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
03:11:41 PM      0.00    8200.00  24000.00     12.00  18000.00   4200.00      0.00   4100.00     97.6
03:11:42 PM      0.00    7900.00  23000.00     10.00  17500.00   3800.00      0.00   3700.00     97.4
03:11:43 PM      0.00    8600.00  25000.00     15.00  19000.00   4500.00      0.00   4400.00     97.8

Ce que cela signifie : Des fautes majeures existent (majflt/s ~10–15). C’est lent. Cela peut indiquer une pression mémoire ou un churn de pages mappées sur fichier.

Décision : Si la latence compte, réduisez le sur-engagement mémoire, ajustez les caches, ou ajoutez de la RAM. Ne « optimisez le code » pendant qu’il y a du paging.

Task 8: Check swap usage and whether swapping is active

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        92Gi       1.2Gi       2.4Gi        32Gi        28Gi
Swap:          8.0Gi       3.1Gi       4.9Gi

Ce que cela signifie : Le swap est utilisé. Pas toujours fatal, mais si swap-in/out continue sous charge, attendez-vous à des pics de latence.

Décision : Corrélez avec les champs « si/so » de vmstat. Si actif, réduisez l’empreinte mémoire, ajoutez de la RAM, ou rééquilibrez les workloads.

Task 9: Verify filesystem mount options (sync penalties are real)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /var/lib/postgresql
/var/lib/postgresql /dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro,data=ordered

Ce que cela signifie : ext4 en mode ordered, relatime. Rien d’évidemment imprudent comme « sync » ou des débats « noatime »-au-lieu-de-données.

Décision : Si vous voyez « sync » sur un volume de données occupé, retirez-le à moins d’apprécier payer une taxe de latence à chaque écriture.

Task 10: Inspect block layer queueing and scheduler

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Ce que cela signifie : « none » est actif. Sur NVMe, c’est souvent acceptable ; sur des SATA HDD, le choix du scheduler peut compter davantage.

Décision : Si vous êtes sur un média rotatif avec des workloads mixtes, envisagez mq-deadline/bfq (testez prudemment). Sur NVMe, concentrez-vous d’abord sur les patterns applicatifs et la profondeur de file.

Task 11: Catch CPU stall reasons quickly (perf stat)

cr0x@server:~$ sudo perf stat -p 18422 -- sleep 10
 Performance counter stats for process id '18422':

        12,004.12 msec task-clock                       #    1.200 CPUs utilized
     3,812,332,100      cycles                          #    3.175 GHz
     2,104,221,900      instructions                    #    0.55  insn per cycle
        44,110,220      branches
         1,102,114      branch-misses                   #    2.50% of all branches

      10.003941915 seconds time elapsed

Ce que cela signifie : L’IPC est 0,55. C’est faible pour beaucoup de workloads, indiquant souvent des stalls (mémoire, locks, I/O). Ce n’est pas une preuve, mais un indice fort.

Décision : Si l’IPC est faible et l’iowait élevé, suivez les I/O. Si l’IPC est faible et l’iowait faible, cherchez les misses mémoire/cache ou la contention sur les locks.

Task 12: Identify top latency syscalls (strace summary)

cr0x@server:~$ sudo strace -ttT -p 18422 -f -o /tmp/trace.log -s 80 -qq -e trace=%file,%network,%process,%memory -c -w -q sleep 5
% time     seconds  usecs/call     calls    errors syscall
 42.18    0.812345        2201       369           fsync
 25.02    0.481002          92      5200      120  openat
 18.11    0.348771         301      1158           pwrite64
  7.44    0.143201          55      2600           recvfrom
  7.25    0.139001          61      2250           futex
------ ----------- ----------- --------- --------- ----------------
100.00    1.924320                   12735       240 total

Ce que cela signifie : fsync domine le temps. C’est de la latence de stockage, des barrières d’écriture, ou un comportement de type WAL.

Décision : Si fsync domine, vous avez besoin d’écritures durables plus rapides (dispositif séparé, meilleur stockage, stratégie de batch) plutôt que « plus de CPU ».

Task 13: Validate network isn’t the silent bottleneck (ss)

cr0x@server:~$ ss -s
Total: 1320 (kernel 0)
TCP:   1180 (estab 640, closed 420, orphaned 0, timewait 390)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  48        44        4
TCP	  760       702       58
INET	  808       746       62
FRAG	  0         0         0

Ce que cela signifie : Beaucoup de timewait peut indiquer des clients churny ou des keepalives mal réglés, mais rien ici ne crie « perte de paquets » en soi.

Décision : Si la latence est « aléatoire », suivez avec les stats d’interface et les retransmissions (tâche suivante).

Task 14: Check retransmits and NIC drops (ip -s link)

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
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456       0     1200       0    220
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  2345678       0        0       0       0

Ce que cela signifie : RX a 1200 paquets dropped. Cela peut être un débordement de ring buffer, un problème de driver, ou simplement des rafales dépassant la capacité.

Décision : Si les drops corrèlent avec des pics de latence, ajustez les anneaux NIC/interrupt moderation ou corrigez l’excès d’arythmie en amont.

Task 15: Confirm thermal or hardware errors aren’t faking “performance issues”

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|mce|edac|error' | tail -n 8
[Thu Jan  9 14:58:12 2026] mce: [Hardware Error]: CPU 3: Machine Check: 0 Bank 6: b200000000070005
[Thu Jan  9 14:58:12 2026] mce: [Hardware Error]: TSC 0 ADDR fef1c140 MISC d012000100000000 SYND 4d000000 IPID 600b000000000
[Thu Jan  9 14:58:12 2026] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:32)

Ce que cela signifie : Erreurs ECC correctibles et MCE. Les problèmes de performance peuvent venir de retries, throttling, ou d’une défaillance matérielle imminente.

Décision : Escaladez pour remplacement matériel ou migrez les workloads. Ne « tunez » pas une machine en fin de vie.

Mode d’emploi pour diagnostic rapide : quoi vérifier en premier/deuxième/troisième

C’est la partie que vous imprimez et scotchez près de votre moniteur. L’objectif est la vitesse avec exactitude : identifiez quel sous-système est saturé,
puis choisissez la mesure suivante qui confirme ou élimine votre hypothèse principale.

Premier : classer le problème (secondes)

• Est-ce le débit ou la latence ? « Les jobs mettent plus de temps » vs « les requêtes timeout ». Modes d’échec différents.
• Est-ce global ou isolé ? Un hôte, une AZ, un tenant, un shard, un endpoint.
• Est-ce nouveau ou cyclique ? Les régressions sentent la config/les releases. Les cycles sentent les jobs batch et les limites de capacité.

Second : vérifier saturation et attente (1–2 minutes)

• CPU : vmstat 1 et mpstat -P ALL 1. Cherchez la pression sur la file d’exécution et les pics de temps système.
• Disque : iostat -xz 1. Cherchez %util proche de 100% et await en hausse.
• Mémoire : free -h, sar -B. Cherchez des fautes majeures, du churn de swap.
• Réseau : ss -s, ip -s link. Cherchez des drops, retransmits, churn de connexions.

Troisième : attribuer la charge (5–15 minutes)

• Quel processus ? pidstat -d, pidstat -u, top ou htop.
• Quel pattern d’appel système ? strace -c pour repérer des fsync storms, openat churn, ou la contention futex.
• Quelle micro-cause ? perf stat (indice IPC) et traçage ciblé (si nécessaire).

Quatrième : décider si la fréquence compte ici (la leçon Pentium II/III appliquée)

• Si le goulet est lié au calcul avec un IPC correct et des attentes minimales, des horloges/coeurs plus rapides aident.
• Si le goulet est iowait ou de la mise en file, des horloges plus rapides brûlent surtout de l’électricité en attendant plus vite.
• Si le goulet est des stalls mémoire, corrigez la localité, le caching, ou la bande passante/latence mémoire — pas les MHz.

Erreurs courantes : symptôme → cause profonde → correctif

1) « Le CPU n’est qu’à 40%, donc il ne peut pas être le problème »

Symptôme : Pics de latence, faible utilisation CPU, utilisateurs se plaignent « c’est lent ».

Cause profonde : La charge est bloquée (disque, réseau, locks), donc le CPU reste inactif.

Correctif : Mesurez iowait et files : vmstat, iostat, pidstat -d. Corrigez le vrai goulet (index, stockage, contention).

2) « On va régler la performance en augmentant les tailles de tampon »

Symptôme : La latence moyenne s’améliore, la latence tail s’aggrave ; des stalls périodiques apparaissent.

Cause profonde : Vous avez créé un comportement de flush/reclaim par rafales (orage de writeback, orage GC, orage de checkpoints).

Correctif : Tirez vers la prévisibilité : limitez les ratios dirty, lissez les checkpoints, bridez les producteurs, et validez avec p95/p99 pas seulement les moyennes.

3) « Les comparaisons de MHz entre CPU sont justes »

Symptôme : Un nouveau CPU à la même GHz est plus rapide/plus lent que prévu.

Cause profonde : Différences d’IPC, changements de hiérarchie de cache, différences du sous-système mémoire, comportement turbo.

Correctif : Comparez avec des benchmarks spécifiques au workload et des compteurs : perf stat et métriques SLO applicatives.

4) « Le disque est rapide maintenant, donc on ne se soucie plus des patterns d’E/S »

Symptôme : Les SSD montrent un %util élevé, la latence grimpe sous la concurrence.

Cause profonde : Saturation de profondeur de file, workloads sync-heavy, amplification d’écriture, petites écritures aléatoires.

Correctif : Séparez WAL/logs, regroupez les écritures, choisissez les bonnes options de montage, et dimensionnez en IOPS pas seulement en capacité.

5) « Le système est lent après un changement, donc c’est le code »

Symptôme : Régression après maintenance, patch ou reboot.

Cause profonde : Réinitialisation du BIOS, changement de governor, changement de driver, changement de politique de cache RAID.

Correctif : Vérifiez la politique de fréquence, les logs kernel, les paramètres de stockage, et comparez avec la baseline avant de blâmer l’appli.

6) « Si on ajoute des threads, on ajoute du débit »

Symptôme : Le CPU monte, le débit plafonne, la latence s’aggrave.

Cause profonde : Contention sur locks, bouncing de lignes de cache, surcharge due aux context switches.

Correctif : Mesurez les changements de contexte et les locks ; réduisez le nombre de threads, shardez le travail, ou changez le modèle de concurrence.

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

Checklist A: Quand quelqu’un propose « achetons juste un CPU plus rapide »

1. Demandez la métrique qui échoue : p95 latence, débit, temps de file, ou temps CPU.
2. Exécutez vmstat 1 10 et notez : file d’exécution (r), bloqué (b), iowait (wa).
3. Exécutez iostat -xz 1 5 et enregistrez : %util, await, et mix lecture/écriture.
4. Exécutez pidstat -u 1 5 et pidstat -d 1 5 pour identifier les processus en tête.
5. Si CPU-bound : confirmez le comportement de fréquence avec cpupower frequency-info.
6. Si memory-bound : confirmez les fautes majeures avec sar -B et vérifiez l’activité swap.
7. Ce n’est qu’ensuite que vous discutez de changement de SKU CPU, et seulement avec des benchmarks de workload.

Checklist B: Changements de tuning « rapides mais fragiles » (ne les déployez pas à l’aveugle)

1. Définissez le succès avec des métriques tail (p95/p99) et les taux d’erreur.
2. Canaryez le changement sur un seul nœud ou petit shard.
3. Validez que vous n’avez pas échangé de petites pauses constantes contre des grosses pauses périodiques.
4. Capturez avant/après : fréquence CPU, iostat await, et histogrammes de latence applicative.
5. Ayez un rollback qui tient en une commande ou un toggle de config.

Checklist C: Régressions après reboot/maintenance

1. Vérifiez la politique CPU : cpupower frequency-info.
2. Vérifiez dmesg pour les erreurs hardware : dmesg -T | egrep -i 'mce|edac|thermal|error'.
3. Vérifiez que les options de montage et les noms de périphériques n’ont pas changé : findmnt, lsblk.
4. Confirmez que le lien NIC a négocié correctement (vitesse/duplex) : ethtool eth0 (si disponible).
5. Comparez aux tableaux de bord de baseline ou aux sorties de runbook stockées.

FAQ

1) Les MHz ont-ils jamais été une bonne mesure de performance ?

C’était une mesure approximative quand les architectures étaient similaires, le mono-cœur dominant, et les goulets stables.
Même alors, les différences de cache et de FSB pouvaient casser la comparaison.

2) Pourquoi les Pentium II/III donnaient l’impression d’une performance « linéaire » ?

Moins d’éléments mobiles : moins de boosting dynamique, topologie mémoire plus simple, moins de services d’arrière-plan, et des workloads souvent liés au calcul ou évidemment liés au disque.
Le goulet du système était plus facile à identifier, donc les upgrades paraissaient plus prévisibles.

3) Quel est l’équivalent moderne de l’ancien goulet du front-side bus ?

Choisissez votre poison : canaux mémoire, interconnexions NUMA, contention sur le LLC partagé, goulot root PCIe, ou profondeur de file du stockage.
Le schéma est le même : un chemin partagé se sature, les files s’accumulent, la latence grimpe.

4) Le SSE sur Pentium III a-t-il changé l’histoire « les MHz signifient la performance » ?

Oui, mais seulement pour les workloads compilés ou écrits pour l’utiliser. Le SIMD peut rendre un « même MHz » bien plus rapide, d’où l’importance des jeux d’instructions encore aujourd’hui.

5) Si les fréquences n’ont plus autant d’importance maintenant, sur quoi dois-je me concentrer ?

Regardez la latence end-to-end, le queueing, et les raisons d’attente : iowait, await disque, file d’exécution, fautes majeures, et IPC.
Puis mesurez le temps CPU par requête et le temps passé à attendre.

6) Comment savoir si je suis memory-bound ?

Signes courants : IPC faible, taux de miss de cache élevé (avec un profilage plus profond), et performance qui ne s’améliore pas en ajoutant du CPU.
Surveillez aussi les fautes majeures et l’activité swap ; le paging peut se faire passer pour une « lenteur CPU ».

7) Quelle est la manière la plus simple d’éviter le cargo-cultisme de la performance ?

Faites une baseline avant les changements : enregistrez iostat await, vmstat wa, la politique de fréquence CPU, et p95/p99 applicatif.
Si vous ne pouvez pas comparer avant/après, vous ne faites que recueillir des impressions.

8) Y a-t-il des leçons du Pentium II/III qui s’appliquent directement aux SRE aujourd’hui ?

Trois grandes leçons : (1) la localité de cache compte, (2) les chemins/bus partagés deviennent toujours des goulets, (3) mesurez les attentes et les files avant d’acheter plus de CPU.
Cette époque était une salle de cours avec moins de distractions.

9) Si je suis sur du matériel moderne, pourquoi devrais-je me préoccuper de cette ancienne époque ?

Parce que ça vous force à penser en pipelines plutôt qu’en slogans. « CPU plus rapide » est un slogan. « Ce workload est bloqué sur la latence fsync » est un diagnostic.
L’ère Pentium a formé des personnes à voir la différence.

Prochaines étapes pratiques

Si vous voulez tirer quelque chose d’opérationnellement utile de l’époque « les horloges avaient du sens » du Pentium II/III, retenez ceci :
la performance est la somme d’une pipeline, et les horloges ne sont qu’une vanne. Votre travail est de trouver la vanne qui est réellement fermée.

1. Adoptez le mode d’emploi de diagnostic rapide et exécutez-le avant de proposer des changements matériels.
2. Commencez à collecter un petit bundle de baseline par service : vmstat, iostat, politique de fréquence CPU, et p95 de latence.
3. Quand vous suspectez le CPU, validez avec IPC et métriques d’attente — pas seulement l’utilisation.
4. Quand vous suspectez le disque, prouvez-le avec await/%util et des preuves par syscall (patterns fsync/pwrite).
5. Rendez les changements de tuning ennuyeux : canary, mesurez les tails, rollbackez rapidement.

Les années Pentium II/III n’étaient pas meilleures parce que les machines étaient « plus simples ». Elles l’étaient parce que les conséquences étaient plus claires.
Construisez des systèmes où les conséquences redeviennent claires : mesurez, attribuez, et corrigez le goulet que vous pouvez nommer.