386 : le moment où le PC a commencé à se comporter comme un serveur

Ce qui a changé avec le 386 (et pourquoi l’exploitation devrait s’en soucier)

L’histoire populaire dit « le 32 bits est arrivé ». Vrai, mais superficiel. Du point de vue de l’exploitation, le 386 a compté parce qu’il a fait cesser l’architecture PC de vous mentir.
Avant cela, les PC étaient souvent des environnements mono‑tâche, mono‑utilisateur prétendant être des ordinateurs généralistes. Le 386 a rendu pratique l’exécution d’un OS qui faisait respecter des frontières : entre processus, entre espace utilisateur et noyau, et entre
« ce programme est bogué » et « toute la machine est maintenant un presse‑papier ».

L’ère 8086/286 pouvait activer le mode protégé, mais c’était gênant et suffisamment incompatible pour que beaucoup de systèmes réels restent en real mode
pour la compatibilité. Le 386 a fait du mode protégé un endroit où l’on pouvait réellement vivre. Il a aussi rendu la pagination pratique et évolutive pour les
charges de travail PC. La pagination n’est pas seulement une fonctionnalité mémoire ; c’est un contrat opérationnel : la machine peut sur‑souscrire la mémoire et survivre, au prix
d’I/O et de latence. C’est un mouvement de serveur.

Le pivot opérationnel : de « l’application possède la machine » à « l’OS possède la machine »

Sur les premiers PC, l’application faisait souvent la loi. Elle accédait directement au matériel. Elle supposait pouvoir écrire n’importe où en mémoire. Elle traitait l’OS
comme un bibliothécaire poli qui allait chercher des fichiers sur demande. Ce modèle s’effondre dès que vous avez besoin d’isolation multi‑utilisateurs, de services en arrière‑plan,
ou de quoi que ce soit ressemblant à de la fiabilité.

Le 386 a introduit un environnement d’exécution où l’OS pouvait faire respecter des règles sans passer son temps à s’excuser pour la compatibilité.
Quand l’OS peut faire appliquer des règles, vous pouvez exécuter plusieurs services sans supposer qu’ils se comporteront. Ça ressemble à des « serveurs modernes »,
parce que c’est le début de cette mentalité sur du matériel grand public.

Une citation à garder scotchée au‑dessus de la console, attribuée à James Hamilton : « Everything fails, all the time. » Ce n’est pas du cynisme ; c’est
un budget d’exploitation. Si vous l’acceptez, vous concevez des systèmes qui échouent de manière contenue. Les protections du 386 ont aidé à contenir les échecs.

Comportements serveur du 386 : isolation, pagination, multitâche et réalité I/O

1) Le mode protégé que les gens ont réellement utilisé

Le 386 n’a pas inventé le mode protégé, mais il l’a rendu habitable. L’espace d’adressage s’est agrandi, le modèle de segmentation est devenu moins contraignant une fois combiné à la pagination, et les performances étaient suffisantes pour des charges réelles. Pour l’exploitation, le résultat pratique
était simple : vous pouviez avoir plus d’une chose importante en cours, et l’un d’eux pouvait planter sans prendre les autres en otage.

Cela a changé le travail. Soudain « le maintenir en marche » était plus que « ne frappez pas le bureau ». Vous aviez des démons, de l’émission, des jobs batch, des utilisateurs,
des permissions, et finalement des piles réseau qui n’assumaient plus un seul programme au premier plan.

2) Pagination : la première fois qu’un PC pouvait faire semblant d’avoir plus de RAM (et parfois s’en tirer)

La pagination n’est pas de la magie de la mémoire ; c’est de la douleur différée. Mais c’est une douleur contrôlée, et la douleur contrôlée est ce sur quoi vit l’exploitation.
Avec la pagination, vous pouvez exécuter une charge qui ne tient pas complètement en RAM. Sans pagination, vous ne pouvez tout simplement pas.

Le matériel de pagination du 386 (une vraie histoire de MMU, pas un bricolage logiciel) a permis aux systèmes d’exploitation d’implémenter la pagination à la demande et l’échange de pages d’une manière comparable aux mini‑ordinateurs et serveurs Unix. C’est le moment où « le disque est lent » devient une affirmation mesurable plutôt qu’une impression.

Blague n°1 : La pagination, c’est comme mettre vos chaussettes dans le tiroir de la cuisine — techniquement vous avez plus d’espace, mais vous détesterez votre vie chaque matin.

3) Anneaux et privilèges : espace utilisateur vs espace noyau cesse d’être philosophique

Le modèle de privilèges x86 (anneaux 0–3) est devenu opérationnellement significatif quand les OS grand public l’ont utilisé de manière cohérente. Les transitions d’anneau, les appels système,
les pilotes noyau et les processus utilisateur ont chacun des responsabilités plus claires. Cela a réduit le modèle « un mauvais pointeur fait exploser le système » qui dominait l’ère DOS.

Cela a aussi créé une toute nouvelle classe de défaillance : les bogues en mode noyau. Quand l’OS devient le patron, les bogues dans le patron font plus mal.
Vous pouvez redémarrer un processus. Redémarrer le noyau s’appelle « reboot », et un reboot en production est une réunion.

4) Mode virtual 8086 : compatibilité sans vivre dans le passé

Le 386 a introduit le mode virtual 8086 (v86), permettant aux OS en mode protégé d’exécuter des programmes DOS en mode real dans des machines virtuelles isolées.
Cela compte parce que c’est le compromis architectural qui a permis aux entreprises d’adopter un comportement « façon serveur » sans abandonner leur parc logiciel du jour au lendemain.

Opérationnellement, v86 est l’ancêtre de la pratique « confinement des charges héritées » : isoler ce que vous ne pouvez pas réécrire, réduire le rayon d’explosion,
et continuer. Ça vous semble familier ? Les conteneurs n’ont pas inventé l’idée ; ils l’ont rendue plus conviviale.

5) Le modèle mémoire plat devient plausible : les développeurs arrêtent de penser en segments (pour la plupart)

La segmentation n’a pas disparu, mais le 386 a rendu le modèle mémoire plat pratique. Pour les équipes d’ingénierie, cela signifiait moins de modèles de pointeurs étranges
et moins d’astuces mémoire. Pour l’exploitation, cela signifiait moins de plantages enracinés dans des modèles mémoire qui ressemblaient à une déclaration d’impôt.

Cela a aussi facilité l’arrivée d’Unix et d’OS de type Unix sur du matériel PC grand public d’une manière qui ne ressemblait pas à un projet scientifique.

6) I/O : toujours le vilain, maintenant avec de meilleures excuses

Le 386 n’a pas magiquement résolu les I/O des PC. Les premiers disques et contrôleurs PC étaient encore lents, et l’architecture de bus n’était pas conçue pour un débit multi‑utilisateur soutenu.
Ce qui a changé, c’est votre capacité à mesurer le goulot. Avec le multitâche et la pagination, vous pouviez voir la contention :
attente CPU, file d’attente disque, changements de contexte et pression mémoire.

Quand une machine peut exécuter plusieurs tâches, elle peut aussi accumuler plusieurs déceptions en même temps. C’est aussi une caractéristique serveur.

Faits historiques importants en production

• Le 386 a été le premier CPU x86 32 bits largement adopté, apportant des registres 32 bits et un espace d’adressage linéaire de 4 GiB — énorme par rapport aux normes PC.
• Il a introduit la pagination sur x86 d’une manière que les systèmes d’exploitation grand public pouvaient utiliser pour la mémoire virtuelle et l’isolation des processus.
• Le mode virtual 8086 est arrivé avec le 386, permettant aux applications DOS de fonctionner sous superviseurs en mode protégé avec isolation.
• Le 386DX avait un bus de données 32 bits ; le 386SX moins cher utilisait un bus externe 16 bits, ce qui signifiait souvent des débits mémoire et I/O sensiblement inférieurs.
• OS/2 2.0 ciblait le matériel de classe 386 pour offrir des fonctionnalités 32 bits et un meilleur multitâche que DOS/Windows de l’époque.
• Les systèmes 386 ont aidé à normaliser Unix sur du matériel grand public via des ports précoces et la faisabilité générale des OS multi‑utilisateurs sur PC.
• L’ère 386 a accéléré la demande pour de meilleurs systèmes de fichiers et gestion de disque, parce que la pagination et les charges multi‑utilisateurs ont exposé brutalement la fragmentation et la latence de recherche.
• Elle a rendu l’« uptime » culturellement pertinent sur les PC : une fois que les PC exécutaient des services en continu, redémarrer a cessé d’être routinier et est devenu risqué.

Les modes de défaillance rendus visibles par le 386

La pression mémoire devient un problème de performance, pas seulement un plantage

Dans un monde mono‑tâche, « plus de mémoire » est un arrêt franc. Dans un monde paginé et multitâche, « faible mémoire » est un spectre. La machine ralentit,
la latence explose, et finalement vous entrez dans le thrashing de swap : le système effectue plus d’I/O disque pour déplacer des pages que de travail utile.
Félicitations, vous avez découvert le premier incident serveur véritablement ennuyeux : celui où rien n’est en panne, mais tout le monde est furieux.

Inversion de priorité et surprises d’ordonnancement

Le multitâche implique des décisions d’ordonnancement. L’ordonnancement signifie que votre charge « rapide » peut devenir lente si elle concurrence la mauvaise tâche au mauvais moment.
Jobs batch, sauvegardes, indexation, spools d’impression — tâches classiques de serveur de bureau — peuvent affamer le travail interactif si vous ne les gérez pas.
Le 386 n’a pas inventé cela, mais il l’a rendu courant sur les PC.

La qualité des pilotes devient une dépendance de fiabilité

Quand vous déplacez l’accès matériel derrière l’OS, les pilotes deviennent les gardiens. C’est sain, mais cela centralise le risque.
Un pilote NIC instable sur un poste est ennuyeux. Sur un PC faisant serveur, c’est une panne.

Les disques deviennent le point de défaillance silencieux unique

Les premiers « serveurs » PC étaient souvent un disque unique, peut‑être deux si quelqu’un se sentait sophistiqué. La pagination a rendu les disques encore plus critiques.
Si le disque est lent, toute la machine est lente. Si le disque échoue, la machine n’est plus « lente », c’est une histoire à raconter dans un postmortem.

Blague n°2 : RAID n’est pas une sauvegarde, mais c’est une excellente manière de perdre vos données deux fois avec confiance.

Trois mini‑histoires d’entreprise de l’ère « PC serveur »

Mini‑histoire 1 : Un incident causé par une fausse hypothèse (la pagination est « gratuite »)

Une entreprise de taille moyenne exécutait un service de fichiers et d’impression sur un PC tour qui était devenu progressivement « le serveur du bureau ». C’était une machine de classe 386
mise à niveau avec plus de RAM (pour l’époque), et l’équipe a migré une petite application basée sur une base de données dessus parce que « ça a de la mémoire virtuelle ».
L’hypothèse : la pagination couvrirait les pics, et les performances se dégraderaient en douceur.

Le premier mois fut calme. Puis le traitement de fin de trimestre est arrivé. Les utilisateurs ont râlé que l’impression prenait des minutes et que l’interface de la base de données « gelait ».
La machine n’était pas techniquement en panne. Elle se contentait de fixer le vide tandis que la LED disque restait allumée comme un indicateur de regret.

L’agent d’astreinte a vérifié le CPU et a trouvé une charge étonnamment basse. Le réseau allait bien. La file d’attente disque était énorme. Le serveur était entré en swap thrash :
l’ensemble de travail dépassait la RAM suffisamment pour que le système évince et recharge sans cesse les mêmes pages. L’équipe avait traité le swap comme un filet de sécurité.
En réalité, le swap est une falaise avec une belle rambarde.

La correction n’était pas ingénieuse. Ils ont réduit la concurrence pendant les fenêtres batch, ajouté de la RAM et — surtout — déplacé la base de données vers une machine avec
des disques plus rapides et séparé le spool d’impression de la charge DB. Ils ont aussi commencé à mesurer la pression mémoire comme métrique de capacité de première classe.
La leçon : la mémoire virtuelle est un mécanisme, pas un plan.

Mini‑histoire 2 : Une optimisation qui s’est retournée contre eux (le « tuning » disque comme auto‑sabotage)

Une autre équipe exploitait un serveur de développement partagé sur un système 386 avec un OS de type Unix. Les développeurs se plaignaient des compilations lentes.
Quelqu’un a décidé que le problème venait de « trop de logs » et de « trop de syncs ». Ils ont ajusté les options de montage du système de fichiers pour la vitesse,
réduit les barrières d’écriture (pour l’époque, l’équivalent de quelques réglages) et désactivé certains flushs périodiques.

Les compilations sont devenues plus rapides. On a célébré. Puis un incident électrique est survenu — bref, pas dramatique. Le serveur est revenu avec un système de fichiers qui
montait en grande partie, mais avec des métadonnées corrompues dans quelques répertoires critiques. Les dégâts étaient sélectifs : certains fichiers étaient intacts, d’autres partiellement écrits.
C’était le pire type de défaillance parce que ça ressemblait au succès jusqu’à ce qu’on touche aux parties cassées.

La récupération a pris des jours pour reconstruire à partir des sauvegardes disponibles, plus une séance d’archéologie « qui a changé les montages ». La motivation initiale était raisonnable : réduire l’overhead d’I/O.
L’erreur était de ne pas comprendre ce qui était sacrifié : la cohérence en cas de crash.

Le changement permanent fut une politique : tout réglage de performance affectant la durabilité nécessite une déclaration de risque écrite et un plan de rollback.
Ils ont aussi séparé les artefacts de build sur un système de fichiers scratch où la vitesse importait plus que la persistance, en gardant le code source et les répertoires personnels
sur des réglages plus sûrs. Des builds plus rapides, c’est bien. Récupérer un arbre corrompu n’est pas une qualité de caractère souhaitable.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (bases de capacité)

Un service financier exécutait une petite application métier plus des partages de fichiers sur un PC 386, plus tard mis à niveau mais toujours contraint.
L’agent d’exploitation — méthodique et peu à la mode — tenait des notes hebdomadaires : espace disque libre, utilisation du swap, charge moyenne, et une brève description
de ce qu’était un « normal » en fin de mois.

Une semaine, les utilisateurs ont signalé une lenteur intermittente vers l’heure du déjeuner. Pas de plantages. Pas d’erreurs évidentes.
Les notes de base ont montré une augmentation progressive de l’utilisation disque et une légère mais constante hausse de l’activité de swap‑in. C’était nouveau.
Ce n’était pas assez dramatique pour déclencher des alarmes, parce qu’il n’y avait pas de bonnes alarmes.

Parce qu’ils avaient des bases, ils n’ont pas deviné. Ils ont vérifié quels répertoires croissaient et ont trouvé un job d’export modifié pour conserver des fichiers intermédiaires supplémentaires.
L’espace disque n’était pas encore épuisé, mais la fragmentation et la pression de recherche augmentaient, et le swap commençait à concurrencer l’I/O des exports.

Ils ont corrigé le job pour qu’il nettoie après lui, déplacé les exports sur un disque séparé et programmé le travail lourd hors des heures d’ouverture.
Personne en dehors de l’exploitation n’a remarqué l’intervention. C’est le but. La pratique ennuyeuse — suivre des bases — a empêché l’incident au ralenti.
Les outils sophistiqués sont optionnels ; savoir ce qu’est le « normal » ne l’est pas.

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

Ce sont des commandes Linux modernes parce que vous pouvez les exécuter aujourd’hui, et les questions sous‑jacentes sont les mêmes que celles que l’ère 386 nous a forcés à poser :
est‑ce le CPU, la mémoire, le disque ou l’ordonnancement ? Chaque tâche inclut la décision à prendre selon la sortie.

Task 1: Identify the machine and kernel (don’t debug the wrong platform)

cr0x@server:~$ uname -a
Linux server 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

What it means: Kernel version and architecture. If you thought you were on x86_64 but you’re not, every performance assumption changes.

Decision: Confirm expected kernel and arch before comparing to baselines or applying tuning guides.

Task 2: Check CPU topology and virtualization hints

cr0x@server:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core|Socket|Virtualization'
CPU(s):                               8
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Core(s) per socket:                   4
Socket(s):                            1
Virtualization:                       VT-x

What it means: How much parallelism you can expect and whether SMT might skew CPU saturation symptoms.

Decision: If a workload scales poorly, you may cap threads or pin CPU; if it’s VM-hosted, check noisy neighbors.

Task 3: Quick load and “is it pegged” view

cr0x@server:~$ uptime
 12:41:07 up 37 days,  3:12,  2 users,  load average: 7.92, 7.85, 7.10

What it means: Load average near or above CPU count suggests contention, but load includes uninterruptible I/O waits.

Decision: If load is high, immediately check whether it’s CPU or I/O wait (next tasks).

Task 4: See CPU saturation versus I/O wait

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0-21-generic (server) 	01/09/2026 	_x86_64_	(8 CPU)

12:41:12 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
12:41:13 AM  all   22.10    0.00    4.55   38.60    0.00    0.40    0.00    0.00    0.00   34.35
12:41:14 AM  all   19.80    0.00    4.20   41.10    0.00    0.45    0.00    0.00    0.00   34.45
12:41:15 AM  all   20.30    0.00    4.10   39.90    0.00    0.50    0.00    0.00    0.00   35.20

What it means: High %iowait means CPUs are mostly waiting on storage. That’s “server acting like a server” behavior: the CPU is idle but the system is busy.

Decision: If %iowait is high, stop tuning CPU and go straight to disk and memory pressure checks.

Task 5: Memory pressure and swapping in one glance

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  2  81264  48216  61240 418920   12   48   980  2100  820 1430 18  4 34 40  0
 2  3  81312  47540  61240 417800   20   56  1100  2500  790 1510 20  4 33 43  0
 1  3  81356  47020  61244 417500   18   60  1050  2400  800 1490 19  4 34 43  0
 2  2  81400  46900  61248 417200   16   52   990  2250  780 1470 18  4 35 43  0

What it means: si/so non-zero indicates swap activity; b indicates blocked processes; wa indicates I/O wait.

Decision: If swap-in/out persists, you’re in memory pressure. Reduce working set, add RAM, or fix runaway caches.

Task 6: What’s using memory (and is it file cache or anonymous RSS)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           15Gi       12Gi       110Mi       1.2Gi       2.9Gi       1.1Gi
Swap:         4.0Gi       1.2Gi       2.8Gi

What it means: “Available” is the key number. Low available with swap usage suggests true pressure, not just cache.

Decision: If available is consistently low, plan capacity changes or reduce memory-hungry services.

Task 7: Per-process memory and CPU offenders

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem,rss,vsz --sort=-rss | head
 2143 java        180.2  42.1 6702100 8123400
 1880 postgres     35.0   6.3 1002400 1402100
 3012 node         22.4   4.9  780120 1023000
 1122 rsyslogd      2.1   0.6   92000  180000

What it means: RSS shows actual resident memory; VSZ shows virtual size. Big RSS + swap = performance risk.

Decision: If one process dominates RSS, validate its limits, leaks, and whether it belongs on this host.

Task 8: Storage device health and queueing

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.04    0.00    4.22   40.11    0.00   35.63

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz  rareq-sz wareq-sz  svctm  %util
nvme0n1         85.0   120.0  6800.0  9200.0     2.0     8.0   2.30   6.25   8.10  14.30   2.90     80.0     76.7   0.25  98.50

What it means: %util near 100% plus high await indicates the disk is the bottleneck.

Decision: If disk is saturated, reduce I/O concurrency, move workloads, or upgrade storage. Don’t “optimize CPU.”

Task 9: Find which processes are generating I/O

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 45.23 M/s | Total DISK WRITE: 62.10 M/s
PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
2143 be/4  app      12.00 M/s  35.00 M/s   12.50 %  85.00%  java -jar service.jar
1880 be/4  postgres 18.00 M/s  10.00 M/s    0.00 %  40.00%  postgres: writer process
3012 be/4  app       9.00 M/s   8.00 M/s    0.00 %  22.00%  node server.js

What it means: IO> shows tasks spending time waiting on I/O; SWAPIN shows memory pressure contributing to I/O.

Decision: If a single service dominates I/O, review query patterns, logging, and temp file behavior.

Task 10: Confirm filesystem space and inode pressure

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  220G  201G   8.5G  97% /
tmpfs           7.8G  1.2G   6.6G  16% /run

cr0x@server:~$ df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p2  14576640 14210000  366640   98% /

What it means: Near-full disks cause fragmentation, allocation stalls, and failures. Inodes can fill before bytes do.

Decision: If either bytes or inodes exceed ~85–90% on a busy server, plan cleanup and capacity expansion immediately.

Task 11: Identify top directories consuming space

cr0x@server:~$ sudo du -xhd1 / | sort -h
0	/bin
1.3G	/boot
4.2G	/etc
12G	/home
28G	/var
155G	/usr
201G	/

What it means: Fast attribution: which tree is growing.

Decision: If /var is large, check logs, spool, databases. If /home is large, enforce quotas or move data.

Task 12: Check log growth and rotation status

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 8.0G in the file system.

What it means: Journals eating disk is common in “PC turned server” situations—logging was an afterthought until it wasn’t.

Decision: If logs are uncontrolled, set retention, rotate properly, and ship logs off-host if you need history.

Task 13: Spot network saturation or retransmits (the “it’s slow” classic)

cr0x@server:~$ sar -n DEV 1 3
Linux 6.5.0-21-generic (server) 	01/09/2026 	_x86_64_	(8 CPU)

12:42:10 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
12:42:11 AM      eth0    8200.00   7900.00  92000.00  88000.00      0.00      0.00     10.00     92.00

What it means: Interface utilization near saturation can look like application slowness.

Decision: If %ifutil is consistently high, upgrade link speed, add NICs, or reduce chatter (compression, batching).

Task 14: Confirm TCP issues (retransmits and backlog pressure)

cr0x@server:~$ netstat -s | egrep -i 'retransmit|listen|overflow' | head
      1832 segments retransmitted
      0 times the listen queue of a socket overflowed
      0 SYNs to LISTEN sockets ignored

What it means: Retransmits indicate network quality or congestion issues; listen queue overflow indicates accept loop issues.

Decision: High retransmits: inspect network path, duplex, MTU, congestion. Overflows: tune app accept rate or backlog.

Task 15: Check kernel pressure indicators (modern “server-ness”)

cr0x@server:~$ cat /proc/pressure/memory
some avg10=28.50 avg60=25.10 avg300=22.05 total=987654321
full avg10=3.10 avg60=2.80 avg300=2.20 total=45678901

What it means: PSI shows time spent stalled on memory pressure. “full” means all tasks are stalled.

Decision: If PSI memory “full” is non-trivial, treat as capacity emergency: reduce load, add memory, or move workloads.

Task 16: Check for disk errors (don’t “tune” around failing hardware)

cr0x@server:~$ dmesg -T | egrep -i 'error|timeout|reset|I/O' | tail
[Thu Jan  9 00:12:14 2026] nvme nvme0: I/O 512 QID 7 timeout, aborting
[Thu Jan  9 00:12:14 2026] nvme nvme0: Abort status: 0x371
[Thu Jan  9 00:12:15 2026] nvme nvme0: resetting controller

What it means: Timeouts and resets are not performance tuning opportunities; they’re hardware incidents.

Decision: Stop. Reduce load, migrate data, replace hardware, and validate firmware. Performance will not out-argue physics.

Méthode de diagnostic rapide : trouver le goulot vite

Quand un PC se comporte comme un serveur, il échoue comme un serveur : contention, files d’attente et dégradation lente. Votre travail est de localiser la file.
Faites‑le dans l’ordre. Ne jouez pas au freestyle.

Première étape : décider si c’est CPU ou attente

• Vérifier la charge : uptime. Une charge élevée ne prouve pas la saturation CPU.
• Vérifier la répartition CPU : mpstat 1 3. Si %iowait est élevé, ce n’est pas un problème CPU.

Interprétation : Un %usr/%sys élevé avec peu d’idle suggère le CPU. Un %iowait élevé suggère stockage ou swap.

Deuxième étape : décider si la pression mémoire crée de l’I/O

• Vérifier le swapping : vmstat 1 5 pour si/so.
• Vérifier la mémoire « available » : free -h.
• Vérifier PSI (si disponible) : cat /proc/pressure/memory.

Interprétation : Une activité de swap persistante ou des stalls « full » signifient qu’il faut réduire l’ensemble de travail ou ajouter de la RAM. Le tuning du stockage ne résoudra pas cela.

Troisième étape : prouver si le stockage est saturé ou juste lent

• Vérifier l’utilisation et l’await du périphérique : iostat -xz 1 3.
• Attribuer l’I/O aux processus : iotop -o.
• Valider la santé du disque : dmesg -T pour resets/timeouts.

Interprétation : Un %util élevé et un await élevé signifient de la file d’attente ; un await élevé avec util modéré peut indiquer des problèmes de firmware, du throttling ou un backend partagé.

Quatrième étape : vérifier le réseau seulement après avoir éliminé CPU/mémoire/stockage

• Utilisation interface : sar -n DEV 1 3.
• Retransmissions : netstat -s.

Interprétation : Si les retransmissions augmentent, corrigez le chemin ; n’essayez pas d’« optimiser » votre appli pour survivre à la perte de paquets.

Cinquième étape : confirmer la mise en file côté application

• Processus principaux : ps, top pour CPU ou RSS hors contrôle.
• Métriques/logs applicatives : latence des requêtes, profondeur des files, requêtes lentes DB.

Interprétation : Une fois que les ressources système semblent saines, le goulot est généralement à l’intérieur des verrous, pools et mécanismes de backpressure de l’application.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le CPU est bas mais tout est lent » → attente I/O ou thrash de swap → mesurer et réduire l’I/O

Symptôme : Les utilisateurs signalent de la lenteur ; le CPU est en grande partie idle ; la charge moyenne est élevée.

Cause racine : %iowait élevé dû à la saturation du stockage ou à la pression mémoire entraînant du swap.

Correctif : Utiliser mpstat, vmstat, iostat, iotop. Réduire les tâches I/O lourdes pendant les pics, ajouter de la RAM, déplacer bases/logs sur des disques plus rapides, limiter la concurrence.

2) « Le reboot règle le problème pour un temps » → fuite mémoire ou explosion de cache → isoler et limiter

Symptôme : Les performances se dégradent sur plusieurs jours ; un reboot restaure la vitesse.

Cause racine : RSS croissant (fuite), caches sans limites, ou fuite de descripteurs de fichiers provoquant des défaillances secondaires.

Correctif : Suivre le RSS via ps et métriques de service ; appliquer des limites (systemd, cgroups), corriger la fuite, redémarrer le service à intervalles planifiés comme mesure transitoire.

3) « Le disque est à 97 % et des choses étranges arrivent » → pression de l’allocateur et fragmentation → libérer de l’espace et séparer les charges

Symptôme : Erreurs applicatives aléatoires, écritures lentes, échec de rotation des logs.

Cause racine : Faible espace libre ou exhaustion d’inodes ; les opérations sur les métadonnées deviennent coûteuses ; les écritures échouent.

Correctif : Nettoyer, augmenter la capacité et garder les systèmes de fichiers occupés en dessous d’environ 80–85 %. Déplacer les données volatiles (spool, tmp, artefacts de build) sur des volumes séparés.

4) « On a tuné pour la vitesse et perdu des données » → réglages de durabilité changés sans analyse de risque → revenir aux valeurs sûres

Symptôme : Après un crash/perte de courant, corruptions du système de fichiers ou écritures récentes manquantes.

Cause racine : Barrières d’écriture désactivées, options de montage non sûres, caches sans protection contre la perte de puissance.

Correctif : Revenir aux réglages sûrs ; mettre les données à performance uniquement sur un stockage scratch ; ajouter une alimentation sans coupure ou du stockage protégé contre la perte de puissance si vous devez pousser les écritures.

5) « Le réseau semble instable seulement sur cet hôte » → NIC/driver ou mismatch duplex/MTU → vérifier compteurs et logs

Symptôme : Retransmissions, stalls intermittents, débit qui s’effondre sous charge.

Cause racine : Lien défectueux, MTU incorrect, bugs de pilote ou dépassements de file.

Correctif : Vérifier netstat -s, statistiques d’interface, compteurs du switch ; standardiser MTU/duplex ; mettre à jour pilote/firmware.

6) « Les sauvegardes tournent, mais les performances en journée meurent » → I/O batch mal planifié → programmer et limiter

Symptôme : À un moment constant, la latence explose ; le iowait monte en flèche.

Cause racine : Sauvegarde/indexation/scan AV saturant le disque.

Correctif : Programmer hors‑heures, utiliser ionice/nice, limiter la concurrence, et séparer la cible de sauvegarde du disque primaire.

Listes de vérification / plan étape par étape

Étape par étape : transformer un « PC serveur » en quelque chose que vous pouvez exploiter

1. Inventorier la charge. Listez les services, heures de pointe et ce que « lent » signifie (latence, débit, erreurs).
2. Établir une base. Capturez uptime, free -h, iostat -xz, utilisation disque et processus principaux en période « normale » et en période de pointe.
3. Séparer les classes de données. Placez OS, logs, bases de données et scratch/temp sur des systèmes de fichiers ou volumes séparés si possible.
4. Faire respecter des limites. Limitez la mémoire et le CPU pour les services non critiques afin d’empêcher un acteur d’engloutir la machine.
5. Contrôler le travail batch. Planifiez sauvegardes, indexations et compactions hors‑pointe ; throttlez avec nice/ionice.
6. Définir une politique de reboot. Les reboots doivent être planifiés, testés et documentés. « Nous ne rebootons jamais » n’est pas une stratégie de résilience.
7. Valider les réglages de durabilité. Assurez‑vous que le tuning de performance n’a pas désactivé la sécurité. Si vous ne pouvez pas expliquer le compromis, revenez en arrière.
8. Surveiller les bons signaux. Pression mémoire, utilisation/await disque, taux d’erreur, retransmissions — pas seulement le CPU.
9. Tester la restauration. Les sauvegardes non restaurées ne sont que de l’optimisme coûteux.
10. Écrire la « méthode de diagnostic rapide ». Votre futur vous sera fatigué et peu impressionné par vos talents d’improvisation.

Checklist : avant de déclarer « le matériel est trop lent »

• Voyez‑vous du swapping (vmstat si/so) ?
• Le disque est‑il saturé (iostat %util proche de 100%) ?
• Y a‑t‑il des erreurs disque (dmesg timeouts/resets) ?
• Le système de fichiers est‑il presque plein (df -h et df -i) ?
• Y a‑t‑il un job batch programmé qui cause des douleurs périodiques ?
• Les retransmissions augmentent‑elles (netstat -s) ?
• Avez‑vous une base de référence pour comparer ?

Checklist : si vous devez extraire des performances d’un matériel limité

• Réduisez la concurrence avant de réduire la sécurité.
• Préférez déplacer les écritures hors du système de fichiers critique plutôt que de rendre ce dernier non sûr.
• Ajoutez de la RAM si le swap est actif ; c’est souvent le meilleur ROI.
• Gardez les disques sous une utilisation confortable ; les disques pleins sont des disques lents.
• Mesurez après chaque changement. Si vous ne pouvez pas le mesurer, vous ne l’avez pas amélioré — vous l’avez juste changé.

FAQ

Le 386 a‑t‑il vraiment « transformé les PC en serveurs » ?

Pas à lui seul. Mais il a fourni les primitives matérielles — mode protégé utilisable, pagination et v86 — qui ont permis au comportement de classe serveur de devenir normal sur les PC.
Le changement culturel a suivi : multi‑utilisateur, services de longue durée et responsabilité opérationnelle.

Quelle est la plus grande leçon ops de l’ère 386 ?

L’isolation change tout. Une fois que les défaillances peuvent être contenues à un processus, vous commencez à concevoir des systèmes qui attendent l’échec et s’en remettent
au lieu de prier pour un logiciel parfait.

La pagination est‑elle toujours mauvaise ?

La pagination est un outil. Une pagination légère peut être acceptable ; un échange soutenu sous charge est une urgence de performance.
Si votre service principal swappe régulièrement, considérez‑le sous‑dimensionné ou mal configuré.

Pourquoi une charge moyenne élevée arrive parfois alors que le CPU est bas ?

Parce que la charge moyenne inclut les tâches bloquées en sommeil non interruptible, généralement en attente d’I/O disque.
C’est pourquoi mpstat et iostat comptent plus que des suppositions.

Quelle est l’équivalence moderne de « applis DOS en v86 » ?

Exécuter une charge héritée dans une VM ou un conteneur avec des frontières strictes. L’objectif est le même : compatibilité sans donner à la charge
le droit de faire tomber tout l’environnement.

Comment savoir si la lenteur vient du stockage ou de la mémoire ?

Vérifiez vmstat pour si/so. Si l’activité de swap est persistante, la pression mémoire est probablement à l’origine de l’I/O.
Confirmez ensuite avec free -h et /proc/pressure/memory. Si le swap est silencieux mais que iostat montre un await et un util élevés, c’est le stockage.

Que dois‑je mettre à niveau en premier : CPU, RAM ou disque ?

Commencez par les preuves. Si le swap est actif et que la mémoire « available » est faible, augmentez la RAM. Si le %util disque est bloqué avec un await élevé, upgradez le stockage ou séparez les charges.
Les upgrades CPU n’aident que lorsque %usr/%sys sont constamment élevés avec peu de %iowait.

Pourquoi les systèmes de fichiers presque pleins causent des problèmes avant d’être complètement remplis ?

Les allocateurs ont moins de choix, la fragmentation augmente, le travail sur les métadonnées augmente et la maintenance (comme la rotation des logs) commence à échouer.
Vous voulez une marge opérationnelle, pas une efficacité héroïque du dernier octet.

La stratégie « ne jamais redémarrer » est‑elle bonne pour la fiabilité ?

Non. La maintenance planifiée vaut mieux qu’une défaillance surprise. Si vous évitez les reboots pendant des années, vous n’êtes pas stable — vous êtes non testé.
Planifiez des reboots, validez la récupération et conservez l’état sur disque avec la durabilité appropriée.

Quelle est la meilleure manière de maintenir un petit serveur stable sous des charges mixtes ?

Séparez les tâches I/O lourdes (logs, sauvegardes, scratch) des services sensibles à la latence, appliquez des limites de ressources et planifiez le travail batch.
La plupart des désastres de « petit serveur » ne sont que de la contention non gouvernée.

Conclusion : étapes pratiques suivantes

Le 386 n’était pas juste une puce plus rapide. C’était le moment où les PC ont gagné suffisamment de discipline architecturale pour supporter de véritables systèmes d’exploitation avec une isolation réelle et un vrai multitâche — ce qui signifie qu’ils ont aussi gagné de véritables modes de défaillance opérationnels : tempêtes de pagination, files d’attente disque et l’usure lente de la contention des ressources partagées. En d’autres termes, c’est quand le PC a cessé d’être un jouet et a commencé à devenir votre problème.

Si vous exploitez aujourd’hui quelque chose qui sent « une machine qui est devenue silencieusement un serveur », faites trois choses cette semaine :
(1) établissez des bases pour le CPU, la pression mémoire et l’await disque ; (2) séparez ou limitez l’I/O batch ; (3) appliquez des limites pour qu’un service ne puisse pas
dévorer l’hôte. Vous éviterez l’incident classique où rien ne « casse », mais tout cesse de fonctionner.