Pentium Pro : le processeur trop en avance sur son temps

Ce qu’était vraiment le Pentium Pro (et ce qu’il n’était pas)

Le Pentium Pro (microarchitecture P6) est arrivé sur un marché qui croyait que « Pentium » signifiait « rapide pour mon PC ».
Intel a utilisé un nom familier, mais c’était une bête différente : un CPU destiné aux systèmes d’exploitation 32 bits et
aux charges serveur, avec des choix architecturaux qui sembleraient ensuite évidents — juste pas en 1995.

De façon générale, le Pentium Pro a introduit une approche plus agressive et plus spéculative pour exécuter du code x86.
Il traduisait les instructions x86 complexes en micro-opérations internes plus simples, les ordonnançait hors d’ordre,
les exécutait sur plusieurs unités fonctionnelles, puis retirait les résultats dans l’ordre de façon à ce que l’extérieur voie
toujours du « x86 normal ». Ce n’est pas qu’un point de trivia ; c’est le modèle sur lequel Intel a itéré pendant des années.

Si vous êtes SRE, pensez-y comme un service qui accepte des requêtes humaines désordonnées (instructions x86),
les normalise dans un protocole interne propre (micro-opérations), parallélise le travail entre des travailleurs
(unités d’exécution), et s’assure ensuite que les réponses sont livrées dans l’ordre attendu (retrait en ordre).
C’est un pipeline interne pensé pour le débit, pas pour rendre chaque requête unique instantanée.

Ce qu’il n’était pas : une puce optimisée pour les applications 16 bits héritées, les hypothèses de l’ère DOS ou les cartes
grand public peu chères. Il pouvait exécuter ces choses, mais avec l’enthousiasme d’une plateforme cloud moderne à qui on
demande d’héberger un serveur de fax.

Trop en avance : le monde attendu vs. le monde réel

Le Pentium Pro attendait un monde 32 bits : Windows NT, OS/2, Unix et les premiers Linux. Il attendait des compilateurs
émettant du code relativement rationnel, et des éditeurs écrivant pour le mode protégé et des modèles mémoire plats.
Il attendait des acheteurs de serveurs prêts à payer pour la qualité de la plateforme, la mémoire ECC et un véritable refroidissement.

Le monde qu’il a obtenu — du moins sur le marché volumique des bureaux — était Windows 95 avec une longue traîne de code 16 bits
et de couches de compatibilité. Beaucoup de logiciels se comportaient encore comme en 1992 et en étaient fiers.
Les jeux et applications grand public étaient souvent réglés pour le Pentium (P5) et ses bizarreries, pas pour une microarchitecture
plus récente qui se préoccupait d’autres choses (prédiction de branchement, localité de cache, mixes d’instructions 32 bits).

Vous obtenez donc le paradoxe : un CPU qui peut être dramatiquement plus rapide pour la bonne charge, mais qui paraît « moyen »
ou même lent pour la mauvaise. En termes de production : vous pouvez construire un service haut débit qui performe sur des clients modernes,
puis le voir s’effondrer parce que la moitié de vos appelants parlent encore un protocole hérité qui contournent toutes vos optimisations.

La réputation du Pentium Pro en a souffert parce que les benchmarks qui intéressaient les gens n’étaient pas ceux qu’il
était conçu pour gagner. Ce n’est pas la première fois où la réalité de l’ingénierie perd face à la réalité marketing, et ce ne sera pas la dernière.

Microarchitecture qui ressemble à un CPU moderne

Si vous avez appris les bases du CPU sur des puces plus récentes, le Pentium Pro paraît familier. Ce n’est pas de la nostalgie ; c’est de la filiation.
Voici ce qui importait en pratique.

Exécution hors d’ordre : pas un simple label

Le Pentium Pro pouvait réordonner l’exécution des instructions pour garder les unités fonctionnelles occupées en attendant des événements plus lents
(comme des défauts de cache). Sur des designs en ordre, une instruction bloquée peut bloquer tout ce qui suit. Sur les designs hors d’ordre,
le CPU tente de trouver du travail indépendant à exécuter.

Traduction pour les opérateurs : l’exécution hors d’ordre rend les performances moins « en dents de scie » sous des charges mixtes,
mais elle rend l’analyse des performances plus centrée sur le comportement mémoire et la prédictibilité des branches.
Si vos données ne sont pas en cache, le CPU passera quand même beaucoup de temps à attendre — simplement de façon plus élaborée.

Micro-opérations : le contrat interne

Les instructions x86 peuvent être complexes ; certaines font plusieurs choses. Le Pentium Pro décode ces instructions en micro-opérations plus simples,
plus faciles à ordonnancer et à exécuter en parallèle. C’est une des raisons pour lesquelles la puce pouvait exceller pour des patterns propres de code 32 bits :
la pipeline de décodage et d’ordonnancement était pensée pour cela.

Spéculation et prédiction de branchement : parier, mais avec justificatifs

L’exécution spéculative — exécuter avant que les résultats soient confirmés — était une caractéristique majeure. Mais elle ne rapporte que si votre
prédiction de branchement est correcte. En cas d’erreur, vous jetez du travail et remplissez à nouveau la pipeline. Sur le Pentium Pro,
une charge très branchée et mal prédite pouvait rendre la puce étonnamment « lente pour ses MHz », parce que la pipeline n’était pas courte.

Le SMP n’était pas une réflexion après coup

Les serveurs Pentium Pro dual-CPU et même quatre-CPU existaient vraiment, pas seulement en tant que projet de laboratoire.
Cela importait pour NT et les bases de données où ajouter des CPU pouvait produire des gains tangibles — à condition que la contention sur les verrous
et la bande passante mémoire ne deviennent pas le nouveau plafond.

Idée paraphrasée, attribuée : Les systèmes deviennent plus fiables quand nous supprimons les étapes manuelles et traitons les opérations comme une discipline. — John Allspaw (idée paraphrasée)

Le pari du cache : L2 sur package et la réalité coûteuse

Le cache L2 du Pentium Pro fait partie de sa mythologie. Intel a mis les puces de cache L2 dans le même package que le CPU,
fonctionnant à la vitesse du cœur. C’était un vrai choix performance quand la mémoire principale était lente et que les défauts de cache faisaient mal.
Cela rendait aussi la pièce coûteuse et compliquée à fabriquer.

Ce n’était pas un « cache intégré sur die » comme dans les générations suivantes. C’était toujours de la SRAM séparée, mais co-localisée dans le
même package, reliée par un bus dédié. Vous obteniez une latence et une bande passante excellentes comparées aux designs de L2 sur carte mère de l’époque.
Vous obteniez aussi un problème de rendement de packaging : si le die CPU ou les puces de cache avaient un défaut, le module entier devenait perdu
ou devait être vendu en configuration inférieure.

Du côté opérationnel, c’est une histoire classique de « rapprocher les données chaudes du calcul ». Le Pentium Pro l’a fait en silicium et en céramique.
Nous le faisons avec des couches de cache, des index en mémoire et une ordonnancement conscient de la localité. Même stratégie, costume différent.

Blague 1/2 : Le packaging du Pentium Pro était si chic qu’il venait presque avec un petit smoking — puis vous demandait de payer le voiturier.

Où il brillait : NT, bases de données et SMP

Mettez le Pentium Pro sous Windows NT 4.0, ou un Unix, ou une distribution Linux de l’époque, et il pouvait ressembler à
un CPU différent de celui qui faisait tourner Windows 95. Il appréciait le code 32 bits, les espaces d’adresses plats et les charges
pouvant tirer parti de sa pipeline plus profonde et de son ordonnancement plus fort.

Les serveurs de bases de données bénéficiaient du cache L2 et de l’exécution hors d’ordre qui lissait les mixes d’instructions.
Les serveurs web — surtout une fois que l’on commençait à faire du TLS réel ou du contenu dynamique — avaient aussi des chemins de code qui
correspondaient mieux à l’approche P6. Et les machines SMP avaient du sens quand le scaling vertical était encore normal et que les éditeurs
facturaient par socket ou par classe de CPU d’une manière qui encourageait le « bigger iron ».

Mais ne l’idéalisons pas. L’échelle SMP était souvent limitée par :

• Contention sur les verrous dans les noyaux et les moteurs de bases de données.
• Bande passante mémoire et overhead de cohérence de cache.
• Gestion des interruptions et qualité des pilotes I/O.

Le Pentium Pro pouvait vous donner plus de calcul, mais il ne pouvait pas corriger un logiciel qui sérialisait le travail avec un mutex géant.
Ce n’est pas un problème de CPU ; c’est une dette de conception.

Où il peinait : code 16 bits, Win95 et la « réalité desktop »

Le talon d’Achille du Pentium Pro dans la narration populaire fut la performance du code 16 bits. Pas parce qu’il ne pouvait pas
exécuter des instructions 16 bits, mais parce que son optimisation n’était pas centrée là-dessus. Windows 95 et beaucoup d’apps grand public
traînaient encore des composants 16 bits et des shim de compatibilité, et le résultat pouvait être décevant.

En termes concrets, beaucoup de charges de bureau avaient des mixes d’instructions et des schémas mémoire qui ne tiraient pas autant
parti des forces du Pentium Pro. Certaines déclenchaient même ses faiblesses : plus de bizarreries de segmentation, davantage de chemins d’appel
hérités, moins de localité de cache propre.

La leçon pour les architectes systèmes est ennuyeuse et brutale : optimisez pour la charge que vous avez réellement, pas pour celle que vous
souhaiteriez avoir. Le Pentium Pro était un excellent CPU pour l’avenir. Le problème est que les clients payaient dans le présent.

Faits intéressants et contexte historique (brefs et concrets)

• Socket 8 : le Pentium Pro utilisait le Socket 8, distinct des sockets desktop mainstream de l’époque.
• L2 sur package à la vitesse du cœur : son cache L2 tournait à la vitesse du CPU, inhabituel et coûteux à l’époque.
• Filiation P6 : la microarchitecture P6 a influencé les Pentium II/III et orienté la direction de conception d’Intel.
• Esprit 32 bits : il était optimisé pour des OS 32 bits comme Windows NT plutôt que pour le monde mixte de Win95.
• Ère SMP : des serveurs Pentium Pro 2-way et 4-way étaient courants dans les déploiements milieu d’entreprise.
• Pertinence PAE : l’époque recouvre les premières discussions sur Physical Address Extension pour des empreintes RAM plus importantes.
• Gros package, grande carte : le packaging en module et les chipsets serveurs ont poussé le coût de la plateforme à la hausse.
• Le compilateur comptait : de meilleurs compilateurs et une génération de code 32 bits pouvaient améliorer sensiblement les performances observées.

Trois mini-récits du monde corporate

Mini-récit 1 : Un incident causé par une mauvaise hypothèse

Une organisation financière avec laquelle j’ai travaillé a hérité d’un « appliance de reporting legacy ». C’est ce qu’il y avait sur l’étiquette.
En réalité, c’était un serveur beige avec deux Pentium Pro, une carte RAID antérieure au concept de télémétrie, et une machine Windows NT
exécutant des rapports très lourds en ODBC. La machine vivait sous le bureau de quelqu’un parce qu’elle « avait besoin d’un accès physique »
une fois par trimestre. Bien sûr.

L’incident a commencé par un rapport lent. Puis les rapports ont expiré. Puis l’arriéré des jobs batch a grossi jusqu’à ce que les tableaux de bord
du matin soient vides. L’ingénieur en on-call a regardé l’utilisation CPU (flottant autour de 50 %) et a décidé que ça ne pouvait pas être le CPU.
Ils ont blâmé les disques et ont lancé une reconstruction RAID risquée parce que « ça doit être du I/O ».

La mauvaise hypothèse était de traiter l’utilisation CPU agrégée comme un proxy direct de la capacité CPU. Sur ces systèmes, le job
tournait en mono-thread, très branché, avec beaucoup de défauts de cache et un verrou chaud autour d’un appel au driver ODBC.
Un CPU était saturé ; l’autre était essentiellement inactif. Le CPU système semblait correct. Pas la latence.

Une fois que nous avons séparé la saturation par cœur du pourcentage CPU global (et que nous avons arrêté de toucher au RAID pendant l’incident),
la correction fut banale : placer le job batch dans la fenêtre la moins contestée, réécrire un rapport pour éviter le pire scan de table,
et accepter que la machine devait être traitée comme un système mono-cœur pour ce chemin. L’équipe l’a ensuite migré, mais la leçon est restée :
« CPU 50 % » est parfois juste « un cœur qui hurle dans le vide ».

Mini-récit 2 : Une optimisation qui s’est retournée contre nous

Dans une autre entreprise, quelqu’un a essayé d’« accélérer » une application web d’époque Pentium Pro en activant une compression agressive
et du caching côté application. L’idée était moderne : réduire le I/O réseau et améliorer les hit rates. L’implémentation n’était pas moderne :
une bibliothèque de compression maison compilée avec des flags bizarres et déployée sans profiling.

Le CPU était bon pour certaines charges serveur 32 bits, certes, mais la compression n’est pas gratuite sur du vieux silicium.
Le chemin de code ajoutait des branches, des boucles dépendantes des données et une pile de copies mémoire qui détruisait la localité de cache.
Les requêtes sont devenues plus lentes, pas plus rapides. La latence P99 a doublé sous charge, tandis que le CPU moyen ne semblait pas dramatique
parce que le système passait plus de temps bloqué sur la mémoire et moins à effectuer des retraits propres.

Le mouvement suivant de l’équipe fut pire : augmenter la concurrence des workers pour « utiliser le CPU idle ». Cela a amplifié la contention
sur l’allocateur et le sous-système de logging. La latence s’est encore dégradée et le comportement tail est devenu chaotique.

Le rollback fut la vraie optimisation : supprimer la compression, garder le caching simple, et se concentrer sur la réduction des copies mémoire
et des appels systèmes. Le Pentium Pro récompensait les chemins de code propres et prévisibles. Il punissait les astuces « intelligentes »
qui supposaient que les cycles CPU étaient interchangeables entre architectures.

Mini-récit 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une petite entreprise de fabrication avait un serveur NT basé sur Pentium Pro qui contrôlait un outil d’ordonnancement et un partage de fichiers.
Ce n’était pas glamour, mais c’était critique : s’il tombait, l’usine ralentissait en quelques heures. La direction ne finançait pas le remplacement
parce que « ça marche encore ».

Le responsable IT a fait quelque chose de profondément pas excitant : il a établi un rituel de vérification hebdomadaire et un test de restauration mensuel.
Les logs étaient exportés vers une machine séparée. Les sauvegardes étaient vérifiées par restauration sur du matériel de secours (oui, du matériel de secours —
parce que pour cette époque, virtualiser n’était pas toujours une option). Ils ont documenté les paramètres BIOS, les ID SCSI et les versions exactes
des drivers connues bonnes.

Un après-midi, le serveur a commencé à émettre des erreurs de parité intermittentes puis a refusé de démarrer. Les disques allaient bien ; la carte mère non.
Parce que l’équipe avait pratiqué la restauration et disposait d’une chaîne de sauvegarde validée, ils ont basculé sur le châssis de secours,
restauré le système et étaient opérationnels avant le prochain changement d’équipe.

Personne n’a reçu d’ovation. C’est la preuve que c’était bien fait. La pratique n’était pas héroïque ; elle était routinière. Et elle a fonctionné
parce qu’elle ne nécessitait pas de créativité en pleine crise.

Playbook de diagnostic rapide : trouver le goulot vite

Quand un système « semble lent », la première tâche n’est pas l’optimisation. C’est la classification. Décidez quel type de lenteur vous avez,
puis choisissez l’outil adapté. Voici un flux de triage rapide qui fonctionne sur Linux moderne et qui est conceptuellement applicable aux
systèmes de l’époque Pentium Pro aussi (ajustez les outils disponibles en conséquence).

1) Est-ce le CPU, des stalls mémoire ou de la contention sur la file d’exécution ?

• Vérifiez la charge moyenne (load average) vs. les cœurs CPU. Une charge élevée avec un CPU faible peut signifier attente I/O, contention de verrous ou backlog de tâches prêtes.
• Vérifiez l’utilisation par cœur, pas l’agrégé.
• Vérifiez les changements de contexte et les interruptions ; un I/O bruyant peut se faire passer pour un problème CPU.

2) Est-ce la latence stockage ou la saturation du débit ?

• Regardez l’utilisation du périphérique et le temps d’attente moyen.
• Différenciez « la file est pleine » de « le périphérique est lent » ou de « le système de fichiers fait un travail supplémentaire ».

3) Est-ce la pression mémoire ?

• Vérifiez l’activité de pagination et de swap.
• Vérifiez le comportement de reclaim et de compaction ; les vieilles machines avaient souvent des marges mémoire serrées.

4) Est-ce un verrou chaud ou un goulot mono-thread ?

• Identifiez le processus/thread le plus chaud.
• Recherchez des symptômes de contention sur les verrous : charge élevée, CPU modéré, beaucoup de processus en sommeil dans des waits noyau.

5) Ce n’est qu’ensuite : micro-optimisations

• Localité de cache, branchiness et nombre d’appels système comptent sur les puces de classe P6.
• Mais ne faites pas d’optimisations à l’aveugle. Mesurez d’abord, changez une chose, mesurez encore.

Tâches pratiques : commandes, sorties et décisions

Ces tâches supposent Linux sur x86 (moderne ou rétro). L’objectif n’est pas que une machine Pentium Pro ait tous les outils ;
l’objectif est l’habitude opérationnelle : observer → interpréter → décider.

Tâche 1 : Confirmer le modèle CPU et les capacités de base

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Architecture|Flags'
Architecture:                         i686
CPU(s):                               2
Model name:                           Intel Pentium Pro (Family 6 Model 1 Stepping 9)
Thread(s) per core:                   1
Core(s) per socket:                   1
Flags:                                fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx

Ce que ça signifie : Vous êtes sur du x86 32 bits (i686). Deux CPU, pas de SMT. Les flags montrent ce que le noyau peut utiliser.

Décision : Traitez le « %CPU » avec précaution ; beaucoup d’apps sont mono-thread. Planifiez la capacité par cœur, pas par machine.

Tâche 2 : Vérifier l’alignement du noyau et de l’espace utilisateur

cr0x@server:~$ uname -a
Linux server 5.15.0-91-generic #101-Ubuntu SMP Thu Nov 16 14:22:28 UTC 2023 i686 GNU/Linux

Ce que ça signifie : Noyau/espace utilisateur 32 bits. Sur Pentium Pro, c’est typique et aligné avec le hardware.

Décision : Si vous avez besoin de >3GB de RAM, vous entrez en territoire PAE ; sinon, gardez la simplicité pour la stabilité.

Tâche 3 : Déterminer si vous êtes saturé CPU ou simplement « occupé »

cr0x@server:~$ uptime
 12:41:22 up 23 days,  4:12,  2 users,  load average: 3.92, 3.51, 3.10

Ce que ça signifie : Load ~4 sur un système 2-CPU suggère un backlog de tâches prêtes ou des tâches bloquées.

Décision : Vérifiez la file d’exécution, l’iowait et l’usage par CPU. Ne devinez pas « disque » tout de suite.

Tâche 4 : Regarder la répartition CPU incluant l’iowait

cr0x@server:~$ mpstat -P ALL 1 3
Linux 5.15.0-91-generic (server)  01/09/2026  _i686_  (2 CPU)

12:41:31 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
12:41:32 PM  all   42.00 0.00 8.00 30.00   0.00  1.00   0.00   0.00   0.00   19.00
12:41:32 PM    0   85.00 0.00 10.00  2.00  0.00  1.00   0.00   0.00   0.00    2.00
12:41:32 PM    1    5.00 0.00  6.00 58.00  0.00  1.00   0.00   0.00   0.00   30.00

Ce que ça signifie : CPU0 est saturé en temps utilisateur ; CPU1 attend souvent de l’I/O. L’agrégé masque le déséquilibre.

Décision : Enquêter à la fois sur un hotspot mono-thread et sur la latence stockage. Vous avez peut-être deux problèmes.

Tâche 5 : Identifier les plus gros consommateurs CPU (et s’ils sont mono-thread)

cr0x@server:~$ ps -eo pid,comm,pcpu,pmem,stat --sort=-pcpu | head
  PID COMMAND         %CPU %MEM STAT
 2441 reportgen       98.7  6.2 R
 1120 mysqld          22.1 18.4 S
  911 rsyslogd         3.2  0.6 S

Ce que ça signifie : Un processus consomme pratiquement un cœur entier. C’est votre piège « CPU seulement 50 % ».

Décision : Profiler ou optimiser reportgen, ou paralléliser si c’est sûr. Ne touchez pas d’abord aux disques.

Tâche 6 : Vérifier l’usage CPU par thread pour repérer un thread chaud

cr0x@server:~$ top -H -b -n 1 | head -n 20
top - 12:41:58 up 23 days,  4:13,  2 users,  load average: 3.84, 3.48, 3.11
Threads:  93 total,   2 running,  91 sleeping,   0 stopped,   0 zombie
%Cpu0  : 96.0 us,  2.0 sy,  0.0 ni,  2.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  6.0 us,  6.0 sy,  0.0 ni, 30.0 id, 58.0 wa,  0.0 hi,  0.0 si,  0.0 st

Ce que ça signifie : Confirme qu’un CPU est bound par le calcul tandis que l’autre est fortement en attente I/O.

Décision : Séparez le pipeline calcul de celui I/O. S’ils sont couplés, vous poursuivrez des fantômes.

Tâche 7 : Vérifier la pression mémoire et le swapping

cr0x@server:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:            512         420          18           6          73          41
Swap:          1024         610         414

Ce que ça signifie : Le swap est activement utilisé ; la mémoire disponible est minuscule. Cela peut amplifier l’iowait.

Décision : Réduire l’empreinte mémoire, ajouter de la RAM si possible, ou déplacer la charge. Tuner le CPU n’aidera pas si vous paginez.

Tâche 8 : Confirmer l’activité de pagination (pas seulement l’occupation du swap)

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
 3  1 624000  18000   6000  61000  12   34   120   260  420  980 42  8 19 31  0
 4  1 624120  17500   5900  60800   8   40   110   240  410 1020 44  7 18 31  0

Ce que ça signifie : Des valeurs non nulles pour si/so indiquent un swap in/out actif. C’est du poison pour la latence.

Décision : Corrigez la pression mémoire d’abord : réduisez la concurrence, diminuez les caches, ou arrêtez le coupable mémoire.

Tâche 9 : Identifier la latence disque et la saturation

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-91-generic (server)  01/09/2026  _i686_  (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          41.7    0.0     8.1    30.2     0.0     20.0

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
sda              18.0    40.0   240.0   820.0    0.0     2.0   98.0  65.4

Ce que ça signifie : %util proche de 100 % avec un await élevé signifie que le disque est saturé et lent à répondre.

Décision : Réduisez les écritures, batcher les I/O, déplacez les données chaudes sur un stockage plus rapide ou ajoutez des plateaux. Ne « ajoutez pas juste des threads ».

Tâche 10 : Trouver quel processus réalise les I/O

cr0x@server:~$ pidstat -d 1 3
Linux 5.15.0-91-generic (server)  01/09/2026  _i686_  (2 CPU)

12:43:01 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
12:43:02 PM     0       911      0.00    180.00      0.00  rsyslogd
12:43:02 PM   999      1120     40.00    520.00     80.00  mysqld

Ce que ça signifie : La base de données et le logging poussent les écritures. kB_ccwr/s suggère des écritures en cache ensuite flushées.

Décision : Ajustez prudemment le comportement de flush de la base de données ; envisagez de déplacer les logs sur un disque séparé pour éviter le thrash de têtes.

Tâche 11 : Vérifier l’espace système de fichiers et la pression sur les inodes

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        18G   17G  0.6G  97% /

Ce que ça signifie : Système de fichiers root à 97 %. Beaucoup de systèmes se dégradent fortement quand ils sont presque pleins (fragmentation, risques ENOSPC).

Décision : Libérez de l’espace immédiatement ; déplacez les logs, faites des rotations ou augmentez le filesystem. Prévenez l’ENOSPC avant que cela devienne une panne.

Tâche 12 : Confirmer si le noyau passe du temps dans les interruptions

cr0x@server:~$ pidstat -w 1 3
Linux 5.15.0-91-generic (server)  01/09/2026  _i686_  (2 CPU)

12:44:11 PM   UID       PID   cswch/s nvcswch/s  Command
12:44:12 PM     0         0    820.00   120.00   kswapd0
12:44:12 PM   999      1120    410.00   350.00   mysqld

Ce que ça signifie : Nombre élevé de changements de contexte, plus l’intervention de kswapd0, suggère pression mémoire et churn de scheduling.

Décision : Réduisez les threads exécutables et corrigez la pression mémoire ; sinon le CPU passera son temps à coordonner la misère.

Tâche 13 : Repérer des problèmes réseau qui ressemblent à une « lenteur CPU »

cr0x@server:~$ ss -s
Total: 256
TCP:   198 (estab 120, closed 52, orphaned 0, timewait 52)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       6         4         2
TCP       146       110       36
INET      152       114       38
FRAG      0         0         0

Ce que ça signifie : De nombreuses sessions TCP établies. Ce n’est pas une preuve décisive, mais cela situe le contexte.

Décision : Si la latence est reprochée, corrélez avec des retransmissions et des erreurs NIC ensuite.

Tâche 14 : Vérifier les erreurs et drops NIC

cr0x@server:~$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped overrun mcast
      987654321 1234567  0       120     0       0
    TX:  bytes  packets  errors  dropped carrier collsns
      543219876 1122334  0       45      0       0

Ce que ça signifie : Des drops non nuls peuvent provoquer des retries et de la latence tail. Les vieux drivers/matériels rendent cela courant.

Décision : Corrigez la couche physique ou la configuration du driver avant d’optimiser le code applicatif pour une « lenteur mystérieuse ».

Blague 2/2 : Si votre machine Pentium Pro perd des paquets, ce n’est pas une « optimisation réseau » — c’est votre serveur qui demande poliment la retraite.

Erreurs courantes : symptômes → cause racine → correctif

1) « Le CPU est seulement à 50 % mais tout est lent »

Symptôme : CPU agrégé modéré ; latence élevée ; load average élevé.

Cause racine : Goulot mono-thread sur un CPU, ou contention sur des verrous rendant un cœur chaud et les autres inactifs.

Correctif : Mesurez l’usage par cœur/par thread ; réduisez la sérialisation ; parallélisez en sécurité ; ou acceptez la capacité mono-cœur et planifiez autour.

2) « Ajouter des threads a empiré les choses »

Symptôme : débit plat ou en baisse ; changements de contexte en pic ; latence tail en hausse.

Cause racine : Contention sur les verrous, contention de l’allocateur ou saturation des files I/O ; l’exécution hors d’ordre ne sauve pas un troupeau furieux.

Correctif : Limitez la concurrence ; utilisez le batching ; séparez I/O et travail CPU ; profilez les hotspots avant d’augmenter les threads.

3) « Le disque est utilisé à 100 %, il faut plus de cache dans l’app »

Symptôme : %util et await élevés ; les caches applicatifs grossissent ; le swapping commence ; la performance s’écroule.

Cause racine : L’expansion du cache provoque pression mémoire et pagination, ce qui augmente le I/O disque et aggrave la latence.

Correctif : Dimensionnez correctement les caches ; priorisez la RAM pour le page cache OS ; ajoutez de la RAM ou réduisez le working set ; déplacez logs/temp hors du disque chaud.

4) « On va benchmarker avec une charge desktop pour choisir un CPU serveur »

Symptôme : le choix CPU semble « mauvais » dans les benchmarks populaires ; la charge serveur réelle est ensuite en désaccord.

Cause racine : Mix d’instructions inadapté (16 bits vs 32 bits), différences de localité de cache ou différences d’ordonnanceur OS.

Correctif : Benchmarquez la charge réelle ou un synthétique fidèle ; incluez OS, système de fichiers et modèle de concurrence.

5) « Le SMP va tout régler »

Symptôme : Ajouter un second CPU apporte peu de gain, puis rendement décroissant.

Cause racine : Verrous partagés, limites de bande passante mémoire, overhead de cohérence de cache ou sections critiques mono-thread.

Correctif : Identifiez les régions sérialisées ; réduisez l’état partagé ; pinnez les IRQ si nécessaire ; envisagez du scale-out si l’app ne sait pas scale-up.

6) « C’est stable donc ne touchez pas » (jusqu’à ce que ça ne le soit plus)

Symptôme : Système ancien qui tourne pendant des années ; puis une petite panne matérielle provoque une longue indisponibilité.

Cause racine : Pas de tests de restauration, pas de plan de pièces de rechange, pas de configs connues documentées.

Correctif : Pratiquez les restaurations ; capturez les configs ; maintenez une pièce de secours froide ; exportez logs/métriques hors de la machine.

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

Étape par étape : évaluer si un système de classe Pentium Pro est le goulot

1. Définir le SLO : choisissez une métrique de latence visible par l’utilisateur et une métrique de débit.
2. Mesurer le CPU par cœur : confirmez si vous avez un plafond mono-thread.
3. Mesurer l’iowait et le disk await : classifiez la lenteur comme calcul vs stockage vs mémoire.
4. Vérifier la pression mémoire : toute activité de swap soutenue est un signal d’alarme.
5. Trouver les principaux coupables : processus CPU top, processus I/O top, processus mémoire top.
6. Confirmer la marge du système de fichiers : gardez de l’espace libre bien au-dessus des seuils « panique ».
7. Réduire le rayon d’explosion : limitez la concurrence, planifiez les batchs, isolez les voisins bruyants.
8. Faire un seul changement à la fois : et re-mesurez.
9. Noter le connu bon : version noyau, versions de drivers, réglages BIOS, configs de service.
10. Planifier la migration : si la charge compte, le plan de sortie compte plus que le plan de tuning.

Checklist opérationnelle : pratiques ennuyeuses qui gardent les vieux systèmes vivants

• Revue hebdomadaire des logs (erreurs, alertes disque, remplissage des systèmes de fichiers).
• Test de restauration mensuel vers du matériel de secours ou un émulateur fidèle.
• Pièces critiques de rechange (alimentation, disques, contrôleur si possible).
• Documenter les jumpers/paramètres BIOS et les paramètres de boot du noyau.
• Conserver les configs en contrôle de version (même si la machine ne peut pas exécuter git).
• Séparer les logs des données si possible ; le logging est un tueur discret de disques.
• Établir une fenêtre de gel : pas d’« expériences de performance » pendant les runs critiques.

Checklist décisionnelle : quand arrêter de tuner et commencer à migrer

• Vous swappez en charge normale et vous ne pouvez pas ajouter de RAM.
• Un cœur est le plafond et l’app ne peut pas être parallélisée en toute sécurité.
• Le disk await reste élevé après avoir éliminé l’amplification d’écritures évidente.
• Des erreurs matérielles apparaissent (parité, événements ECC, drops NIC) et les pièces de rechange sont incertaines.
• Tout changement nécessite du folklore plutôt que de la documentation.

FAQ

Le Pentium Pro était-il un échec ?

Commercialement sur les desktops mainstream, il n’a pas répondu aux attentes par rapport au coût. Architecturally et pour les serveurs,
ce fut un succès qui a orienté la direction pendant des années.

Pourquoi a-t-il mal performé sur certaines charges Windows 95 ?

Windows 95 contenait beaucoup d’héritage 16 bits et des comportements de compatibilité. Les choix de conception du Pentium Pro favorisaient
le code 32 bits propre et des mixes d’instructions différents, donc certains chemins desktop ne s’y adaptaient pas bien.

Qu’est-ce qui rendait son cache L2 spécial ?

Les puces de cache L2 vivaient dans le même package que le CPU et tournaient à la vitesse du cœur, réduisant la latence comparé au cache
sur carte mère. C’était rapide et onéreux.

Le Pentium Pro supportait-il bien les systèmes multi-CPU ?

Oui, pour son époque c’était une plateforme SMP solide. Mais le scaling réel dépendait toujours de la contention sur les verrous et
des sous-systèmes mémoire/I/O.

Quelle est la leçon moderne du problème « trop en avance » du Pentium Pro ?

Alignez les cibles de conception avec les charges réelles. Si vos utilisateurs exécutent des chemins hérités, votre architecture sophistiquée
peut rester non rentable tant que l’écosystème n’a pas rattrapé son retard.

Si je diagnostique un « serveur lent », qu’est-ce que je dois vérifier en premier ?

La saturation par cœur et l’iowait. Ensuite la pression mémoire (activité swap). Puis la latence disque (await),
puis la contention sur verrous et les hotspots mono-thread.

Pourquoi la load average peut-elle être élevée alors que l’utilisation CPU ne l’est pas ?

La load inclut les tâches en attente d’I/O ou bloquées en sommeil non interruptible. Une load élevée avec un CPU modéré signifie souvent
latence I/O, pagination ou contention sur verrous.

« Plus de threads » est-il un correctif sûr sur de vieux CPU ?

En général non. Plus de threads peut amplifier la contention et la mise en file des I/O. Cadençonnez la concurrence sur base de mesures,
pas d’espoirs.

Quelle est la meilleure pratique unique pour garder des systèmes anciens fiables ?

Des tests de restauration réguliers vers du matériel connu bon (ou un environnement équivalent), plus la documentation complète
de la chaîne de boot et des drivers. Des backups sans pratique de restauration sont de l’optimisme, pas de la résilience.

Conclusion : prochaines étapes pratiques

Le Pentium Pro n’était pas « mauvais ». Il était spécifique. Il a parié sur un futur centré 32 bits et serveurs, et a mis l’exécution hors d’ordre
et le cache rapide sous les projecteurs. L’écosystème a fini par rattraper — juste pas assez vite pour que la narration desktop soit clémente.

Si vous opérez des systèmes (anciens ou nouveaux), volez les bonnes leçons :

• Benchmarkez la réalité, pas la mythologie. Votre charge décide ce que signifie « rapide ».
• Diagnostiquez avant d’optimiser. Classez la lenteur en CPU, I/O, pression mémoire ou contention.
• Surveillez par cœur et par thread. Les métriques agrégées cachent la vérité.
• Privilégiez le travail de fiabilité ennuyeux. Tests de restauration et documentation battent l’héroïsme.
• Sachez quand migrer. Certains goulots sont économiques, pas techniques.

Si vous faites encore tourner des machines proches du Pentium Pro en production, traitez-les comme un array de stockage legacy :
elles sont stables jusqu’à ce qu’elles ne le soient plus, et le plan de remplacement fait partie du plan de disponibilité.