Celeron : comment une puce réduite est devenue une légende de la mise à niveau

Ce que Celeron était censé être

Celeron a commencé comme la gamme économique d’Intel : un moyen d’atteindre des points de prix plus bas sans cannibaliser la marque Pentium haut de gamme. En pratique, c’était un ensemble tournant de compromis — généralement moins de cache, parfois un front-side bus plus lent, parfois des fonctionnalités manquantes, parfois des fréquences plus basses, souvent tout cela à la fois.

Cela ressemble à une histoire ennuyeuse de segmentation produit. Ce n’en était pas une. Parce que le silicium sous-jacent n’était souvent pas « bas de gamme » du tout ; il s’agissait fréquemment du même cœur architectural que les pièces supérieures, simplement configuré différemment. Si vous êtes SRE, vous savez comment ça se passe : même plateforme, différents réglages. Et parfois ces réglages n’importent pas comme le marketing le prétend.

La raison pour laquelle Celeron est devenu une « légende de la mise à niveau » n’est pas qu’il était secrètement magique. C’est que la courbe de performance des charges de travail réelles est en dents de scie. Certaines charges sont liées au cache. D’autres sont limitées par la fréquence. D’autres encore sont sensibles à la latence mémoire. Certaines sont liées à l’I/O et ne méritent pas le CPU coûteux que vous vous apprêtez à acheter pour apaiser votre anxiété.

Celeron vivait justement dans cet espace désordonné où une puce amputée pouvait encore sembler rapide — surtout si votre référence était une machine de quelques années plus tôt, ou si votre charge de travail se fichait des éléments manquants.

Comment la légende de la mise à niveau s’est formée

Il y a deux sortes de légendes en informatique : celles qui sont largement vraies, et celles qui sont vraies dans une configuration étroite puis répétées par des gens qui n’ont jamais refait l’expérience. Celeron a mérité les deux.

L’histoire canonique est l’ère du Celeron 300A : un processeur bon marché qui, avec la bonne carte mère et le bon refroidissement, pouvait tourner à une vitesse de bus supérieure et offrir des performances comparables à des pièces beaucoup plus chères. C’était une parfaite conjonction d’architecture, de binning et de culture du montage PC des années 90.

Mais la raison plus profonde pour laquelle la légende a perduré dans les générations suivantes est plus banale : pour beaucoup d’utilisateurs, le goulet n’était pas le cœur CPU. C’était le disque, la quantité de RAM, le GPU, ou tout simplement l’embonpoint logiciel. On installe un CPU « assez bon » et le système a l’air « réparé ». Les humains créditent alors le CPU parce que c’est l’amélioration la plus visible. Pendant ce temps, la pile de stockage est dans le coin, faisant silencieusement 400 IOPS aléatoires et ruine la journée de tout le monde.

Blague #1 (courte et douloureusement exacte) : Upgrader un CPU pour réparer un portable lent, c’est comme acheter des pneus de course pour une voiture avec le frein à main serré. On se sent proactif, jusqu’au moment où ça sent le brûlé.

En serveur, la légende de Celeron a pris une autre forme : faible consommation, basse chaleur, « assez bon » pour de petits services. C’est parfois vrai. C’est aussi comme ça qu’on finit par exécuter un reverse proxy chargé de TLS sur une puce qui paraît correcte en moyenne CPU mais s’écroule aux pics de handshakes.

Faits rapides et contexte historique

Ce ne sont pas des anecdotes pour le plaisir ; elles expliquent pourquoi certains Celeron étaient adorés et d’autres allaient à la décharge.

• Celeron a été lancé en 1998 comme réponse d’Intel à la pression du marché value, surtout face aux puces au prix agressif d’AMD.
• Les premiers Celeron « Covington » ont été livrés sans cache L2 (oui, aucun), ce qui les rendait très mauvais malgré des fréquences correctes pour l’époque.
• Les Celeron « Mendocino » ont ajouté un cache L2 sur puce, un saut énorme en performance réelle car la latence du cache a chuté drastiquement.
• Le Celeron 300A (1998) est devenu célèbre pour l’overclocking en faisant tourner une puce FSB 66 MHz à 100 MHz, si votre carte mère et votre RAM supportaient le rythme.
• Intel utilisait des leviers de segmentation comme la vitesse du FSB et la taille du cache pour séparer Celeron du Pentium, souvent en utilisant la même conception de cœur.
• Les Celeron ultérieurs se sont orientés vers les rôles basse consommation mobile et embarqué, incluant de nombreux modèles double‑cœur destinés aux netbooks et petits desktops.
• Certaines puces modernes sous la marque « Celeron » sont basées sur des cœurs dérivés d’Atom plutôt que sur les grands cœurs desktop, ce qui change le comportement de performance (surtout en mono‑thread).
• Le support de la virtualisation varie selon les générations ; certains Celeron n’ont pas VT-x ou ont des fonctions limitées comparées aux SKU voisins.
• La marque a survécu à plusieurs ères architecturales (P6, NetBurst, Core et familles Atom), ce qui explique pourquoi les affirmations générales sur la « performance Celeron » sont généralement fausses.

Le deal technique : cache, bus, fréquences et coupes

Cache : la coupe qui importait le plus (jusqu’à ce que ça n’importe plus)

La plupart des segmentations Celeron se concentraient sur le cache. Ce n’est pas arbitraire ; le cache coûte en surface de die et en énergie, et il est critique lorsque votre charge de travail a un working set qui tient dedans. Réduire le cache force plus d’allers-retours vers la mémoire principale, où la latence écrase le temps d’exécution du cœur.

En termes de production : moins de cache augmente les probabilités que vos chemins de code chauds et vos données chaudes ne restent pas chauds. Vous le voyez comme une augmentation des cycles par instruction (CPI), plus de cycles backend bloqués, et un CPU qui semble « occupé » mais ne fait pas de travail utile.

C’est là que le mythe se sépare :

• Si votre charge tient dans le cache (ou est en streaming et prévisible), une puce à cache réduit peut encore paraître excellente.
• Si votre charge fait beaucoup de pointer‑chasing (bases de données, certains key‑value stores, certains schémas de compression, certains runtimes de langage), les coupures de cache nuisent de façon disproportionnée.

Front-side bus et sous‑système mémoire : le limiteur invisible

Les anciens Celeron avaient souvent des vitesses de front-side bus plus lentes. Ça compte quand vous êtes lié par la mémoire ou quand le chipset + RAM est déjà limite. Vous pouvez avoir un CPU prêt à tourner et un sous‑système mémoire qui ne l’est pas.

Les plateformes modernes ont abandonné le modèle classique de FSB, mais le principe reste : le sous‑système mémoire (fréquence, canaux, latence, qualité du contrôleur) est fréquemment l’enveloppe réelle de performance.

Coupes fonctionnelles : virtualisation, instructions et « ça démarre mais c’est triste »

Certaines SKU Celeron omettent des fonctionnalités comme VT-x, certaines fonctions de sécurité, ou des extensions vectorielles avancées. C’est là que des améliorations bon marché se transforment en dette opérationnelle. Vous pouvez faire tourner des conteneurs sur presque n’importe quoi, mais si vous comptez exécuter des hyperviseurs, de la virtualisation imbriquée, ou certaines accélérations crypto, vous devez vérifier le SKU exact.

Autrement dit : « Celeron » n’est pas une spécification. C’est une étiquette qui vous avertit de lire les petites lignes.

Thermique et consommation : la raison discrète pour laquelle ils avaient du sens

Dans de petits boîtiers, des PC de bureau bon marché et des boîtiers sans ventilateur, la marge thermique est la vraie monnaie. Les pièces à faible TDP se comportent mieux : moins d’événements de throttling, moins de bruit de ventilateur, moins de baisses de tension étranges du bloc d’alimentation lorsque tout démarre.

Et pour les labs à la maison : un CPU qui grignote l’énergie peut valoir plus qu’un qui gagne un benchmark, parce que le benchmark ne paye pas votre facture d’électricité.

Où Celeron gagne (et pourquoi)

Soyons pragmatiques. La puce est « bonne » quand ses contraintes correspondent à votre charge. Les meilleurs moments de Celeron sont lorsque la plateforme est stable, la charge est légère à modérée, et que votre goulot est ailleurs.

1) Services simples avec concurrence prévisible

Résolveurs DNS, petits reverse proxies Nginx (sans fort churn TLS), tableaux de bord internes, collecteurs de métriques, expéditeurs de logs — ces services passent souvent sur des CPU modestes si vous avez assez de RAM et un stockage correct. L’expression clé est « concurrence prévisible ».

2) Rôles NAS et serveurs domestiques où le stockage domine

Partage de fichiers, sauvegardes et streaming média sont fréquemment limités par le débit disque, le réseau ou la surcharge du protocole. Si vous saturez 1 GbE, le CPU n’est peut‑être pas le problème. Ajoutez le chiffrement, la compression, la déduplication ou des checksums lourds et la donne change — vite.

3) Amélioration de la réactivité d’un desktop ancien

Un CPU d’entrée de gamme associé à un SSD et assez de RAM peut sembler une amélioration miraculeuse par rapport à un ancien système avec disque dur. Mais le miracle est généralement l’SSD et la RAM, pas le CPU. Ne vous trompez pas d’attribution ; c’est comme ça que les budgets d’amélioration partent mal dépensés.

4) Environnements contraints par la puissance et le bruit

Parfois, la « machine la plus rapide » est celle qui ne bridera pas. Une pièce modeste tournant à fréquence stable toute la journée peut battre une puce plus chaude coincée dans la gestion thermique. Les SKU Celeron basse consommation les rendaient attractifs dans les kiosques, petits bureaux et appliances réseau.

Où Celeron échoue (et comment)

1) Tout ce qui exige une sensibilité sérieuse à la latence par cœur

Quand votre latence en queue importe, la performance mono‑thread compte. Pas toujours, mais souvent. Beaucoup de Celeron ont moins de cœurs, des fréquences plus basses, un cache plus petit, et parfois des microarchitectures plus faibles (surtout les lignes dérivées d’Atom). Le mode d’échec est subtil : le temps de réponse moyen semble acceptable ; les p99 et p999 deviennent affreux sous charge.

2) Charges lourdes en chiffrement

Si vous terminez du TLS à grande échelle, chiffrez des disques ou compressez et chiffrez des sauvegardes, vous voulez le bon jeu d’instructions et assez de débit de cœurs. L’absence d’accélération ou un simple manque de marge se manifeste par un CPU au taquet pendant les handshakes, une latence plus élevée aux pics, et des retries en cascade qui ressemblent à de la « fluctuation réseau ».

3) Virtualisation et rêves de « petit cloud »

Les gens adorent l’idée d’un petit serveur domestique qui fait tourner plein de VMs. Réalité : vérifiez VT-x, la capacité mémoire et l’I/O. Un Celeron peut exécuter un hyperviseur, mais il peut aussi vous piéger dans des chemins d’émulation lents ou une mémoire trop juste qui rend chaque invité malheureux.

4) Piles de stockage qui font du vrai travail

ZFS avec compression, déduplication (ne le faites pas), checksums, scrubs et snapshots peut peser sur le CPU. Idem pour RAID logiciel de parité, codage d’effacement et systèmes de fichiers modernes faisant du travail d’intégrité. Le mode d’échec est que l’utilisation disque semble basse mais le débit cale ; le CPU est le facteur limitant, pas les disques.

Blague #2 (courte) : La déduplication sur un petit CPU, c’est comme organiser un buffet dans une cabine téléphonique. Techniquement possible ; socialement et thermiquement désastreux.

Une citation, parce que c’est toujours vrai

Idée paraphrasée de Gene Kim : « Améliorer le flux et le feedback bat les coups d’éclat ; rendez le travail visible, réduisez la taille des lots, et les problèmes deviennent plus faciles à corriger. »

Transposé au matériel : rendez les goulets visibles avant de dépenser de l’argent. N’achetez pas une mise à niveau sur des impressions.

Playbook de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Ceci est le playbook que j’utilise quand on me dit « le serveur est lent » et que la conversation budgétaire est sur le point de devenir coûteuse.

Premier : décidez si c’est saturation CPU ou attente CPU

• Vérifiez la charge moyenne vs utilisation CPU. Une charge élevée avec une faible utilisation CPU signifie souvent attente I/O ou contention de locks.
• Regardez la file d’exécution et l’iowait. Si l’iowait est élevé, n’achetez pas de CPU tout de suite.
• Vérifiez le throttling. Un CPU « lent » peut être un CPU surchauffé.

Second : identifiez le domaine du goulet (CPU / mémoire / disque / réseau)

• Disque : await élevé, débit faible, file d’attente device saturée → goulet stockage ou latence mauvaise.
• Mémoire : swap, fautes majeures élevées, peu de libre, reclaim élevé → goulet mémoire.
• Réseau : retransmissions, pertes, NIC saturée → goulet réseau.
• CPU : temps user/system élevé, threads runnable nombreux, iowait bas → goulet CPU.

Troisième : trouvez le limiteur spécifique

• Si CPU : thread unique saturé ? locks ? crypto ? garbage collection ? temps noyau ?
• Si disque : I/O aléatoire ? fsync storms ? écritures petites ? amplification d’écriture ? RAID dégradé ?
• Si mémoire : fuite ? caches surdimensionnés ? JVM mal dimensionnée ? limites de conteneur ?
• Si réseau : mismatch MTU ? pertes dues aux ring buffers ? offloads mal gérés ?

L’objectif n’est pas de trouver « une métrique qui semble élevée ». L’objectif est de trouver la chose qui fixe le plafond de débit ou le plancher de latence. La légende Celeron existe parce que des gens ont amélioré le mauvais élément et ont pourtant constaté un gain, généralement par accident.

Tâches pratiques : commandes, sorties, ce qu’elles signifient, et ce que vous décidez

Ci‑dessous des tâches réelles à exécuter sous Linux pour évaluer si un Celeron (ou tout CPU modeste) est « suffisant », et pour diagnostiquer quand il ne l’est pas. Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie, et la décision à prendre.

Task 1: Identify the exact CPU model and capabilities

cr0x@server:~$ lscpu
Architecture:             x86_64
CPU op-mode(s):           32-bit, 64-bit
Vendor ID:                GenuineIntel
Model name:               Intel(R) Celeron(R) CPU J4125 @ 2.00GHz
CPU(s):                   4
Thread(s) per core:       1
Core(s) per socket:       4
Socket(s):                1
Flags:                    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... aes ... vmx

Signification : Vous connaissez maintenant le SKU, le nombre de cœurs, et si des fonctionnalités comme aes (AES-NI) et vmx (VT-x) existent.

Décision : Si vmx est absent, arrêtez de promettre « plein de VMs ». Si aes est absent, soyez prudent pour la terminaison TLS et les charges lourdes en chiffrement.

Task 2: Confirm virtualization support (KVM readiness)

cr0x@server:~$ egrep -o 'vmx|svm' /proc/cpuinfo | head
vmx
vmx
vmx
vmx

Signification : vmx indique Intel VT-x. Si ça n’affiche rien, la virtualisation matérielle n’est pas disponible.

Décision : Si vide, prévoyez uniquement des conteneurs, ou acceptez une virtualisation logicielle plus lente (généralement inacceptable pour du sérieux).

Task 3: Check if the CPU is throttling (thermal or power)

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|powercap' | tail -n 5
[ 8921.113421] thermal thermal_zone0: critical temperature reached, shutting down
[ 9120.221044] CPU0: Core temperature above threshold, cpu clock throttled

Signification : Le kernel vous dit que le CPU a atteint des limites thermiques. Les problèmes de performance ici ne sont pas un « CPU faible », mais un « mauvais refroidissement ou châssis ».

Décision : Réparez le refroidissement, la poussière, le flux d’air, la pâte thermique, la courbe des ventilateurs, les limites d’alimentation du BIOS. Upgrader le CPU sans corriger le thermique, c’est se saboter.

Task 4: See current frequencies to catch sustained downclocking

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:800000

Signification : Le CPU est à 800 MHz. Ça peut être de l’inactivité (correct) ou coincé à cause d’une politique d’alimentation (pas correct).

Décision : Si les plaintes de performance surviennent alors que les fréquences restent basses, inspectez les paramètres du gouverneur et les limites d’alimentation ; envisagez le gouverneur « performance » pour les serveurs qui ont besoin d’une latence stable.

Task 5: High-level CPU and iowait snapshot

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.1.0 (server)  01/09/2026  _x86_64_  (4 CPU)

12:01:10 PM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:01:11 PM  all   12.00  0.00  4.00   0.00 0.00  1.00   0.00 83.00
12:01:12 PM  all   10.75  0.00  3.50  18.25 0.00  0.50   0.00 67.00
12:01:13 PM  all   11.50  0.00  3.25  22.75 0.00  0.75   0.00 61.75

Signification : Le CPU n’est pas saturé, mais l’iowait augmente. Votre « serveur lent » attend probablement le disque.

Décision : N’achetez pas un CPU plus rapide. Allez regarder la latence de stockage, le queueing et le comportement du système de fichiers.

Task 6: Load average and run queue reality check

cr0x@server:~$ uptime
 12:02:01 up 34 days,  4:20,  2 users,  load average: 6.21, 5.88, 5.43

Signification : Sur un CPU 4 cœurs, une load average soutenue autour de 6 suggère du queueing. Mais cela peut être des tâches prêtes à tourner ou de l’iowait non interruptible.

Décision : Associez immédiatement avec vmstat pour distinguer une file d’attente CPU d’une attente I/O.

Task 7: Distinguish CPU pressure from I/O wait and swapping

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
 6  0      0 412000  21000 512000    0    0    12   150  320  780 12  4 82  2  0
 7  0      0 410800  21000 512500    0    0     8  1200  340  820 14  5 70 11  0
 5  1      0 410500  21000 512100    0    0     0  2400  360  900 10  4 55 31  0
 3  2      0 409900  21000 511900    0    0     0  1800  310  860  8  3 50 39  0
 4  1      0 410200  21000 512200    0    0     0   900  300  830  9  3 62 26  0

Signification : r est le nombre de tâches prêtes, b est bloqué. Ici, les processus bloqués augmentent et wa grimpe : l’I/O est la douleur.

Décision : Concentrez‑vous sur le stockage : quel device, quel processus, quel motif d’accès. L’upgrade CPU n’est pas votre premier move.

Task 8: Find the top CPU consumers and whether it’s one hot thread

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:03:10 up 34 days,  4:21,  1 user,  load average: 5.92, 5.80, 5.41
Tasks: 212 total,   3 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu(s): 28.1 us,  6.3 sy,  0.0 ni, 40.0 id, 25.6 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7865.2 total,   612.4 free,  1021.8 used,  6231.0 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2113 postgres  20   0 1894328 412560  17892 R  98.7   5.3  12:08.33 postgres
1452 root      20   0  612280  38400  12300 D  35.2   0.5   2:12.04 rsync

Signification : Un processus postgres consomme presque un cœur entier ; l’iowait est élevé et rsync est bloqué en sommeil non interruptible (D).

Décision : Si votre SLA dépend de la latence Postgres, un petit CPU peut être serré — mais corrigez d’abord l’attente stockage, sinon vous courrez après des fantômes.

Task 9: Check per-disk latency and queueing

cr0x@server:~$ iostat -x 1 3
Linux 6.1.0 (server)  01/09/2026  _x86_64_  (4 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              1.20   60.30    80.1  4200.7  45.20   1.90  98.30
nvme0n1         10.00    5.00  1200.0   300.0   1.10   0.20   2.00

Signification : sda est saturé à ~98% d’utilisation avec un await élevé. C’est votre goulet, pas le CPU.

Décision : Déplacez la charge chaude vers NVMe/SSD, corrigez la disposition RAID, réduisez les écritures synchrone, ou changez les motifs d’accès. Le choix du CPU est secondaire tant que la latence disque reste élevée.

Task 10: Verify filesystem and mount options (sync can hurt)

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

Signification : Vous voyez le système de fichiers et les options de montage. Ce n’est pas « mauvais », mais ça aide à valider des hypothèses (par ex. sommes‑nous sur disque rotatif ? utilisons‑nous des options étranges ?).

Décision : Si vous attendiez SSD/NVMe et que vous êtes sur /dev/sda2, vous venez de trouver une erreur de migration.

Task 11: Check memory pressure and swapping

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.0Gi       620Mi       120Mi       6.1Gi       6.3Gi
Swap:          2.0Gi         0B       2.0Gi

Signification : Beaucoup de mémoire disponible ; le swap n’est pas le problème pour l’instant.

Décision : N’ajoutez pas de RAM « juste parce que ». Si la performance est encore mauvaise, regardez la latence I/O ou la contention CPU.

Task 12: Identify memory latency or cache-miss suspicion (quick proxy via perf)

cr0x@server:~$ sudo perf stat -p 2113 -a -- sleep 5
 Performance counter stats for 'system wide':

        6,210.45 msec task-clock                #    1.242 CPUs utilized
       12,112,040      context-switches          #    1.952 M/sec
          102,400      cpu-migrations            #   16.489 K/sec
     18,220,000,000      cycles                  #    2.936 GHz
     10,440,000,000      instructions            #    0.57  insn per cycle
        1,220,000,000      cache-misses          #   30.1% of all cache refs

       5.000812445 seconds time elapsed

Signification : L’IPC est bas et les cache‑miss sont élevés. Cela pointe souvent vers un comportement lié à la mémoire — exactement là où un cache réduit et des sous‑systèmes mémoire faibles font mal.

Décision : Envisagez un CPU avec plus de cache / des cœurs plus performants, ou retravaillez la requête/index/charge. Si vous êtes sur un Celeron à faible cache, c’est votre signal « arrêtez de faire semblant ».

Task 13: Check network drops and retransmits (don’t blame CPU for packet loss)

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 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0     184       0      12
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0      96       0       0

Signification : Il y a des drops. Pas nécessairement catastrophiques, mais suffisants pour créer une lenteur « aléatoire » sous charge.

Décision : Enquêtez sur les ring buffers du NIC, le pilote, le port de switch, le câble, le MTU et la surcharge hôte. N’offrez pas un CPU en sacrifice rituel.

Task 14: Verify crypto acceleration availability (TLS and encryption realism)

cr0x@server:~$ grep -m1 -o 'aes' /proc/cpuinfo
aes

Signification : AES-NI est disponible. C’est bon pour les ciphers TLS courants et le surcoût du chiffrement disque.

Décision : Si absent, prévoyez une utilisation CPU plus élevée sous chiffrement ; vous pourriez avoir besoin d’une autre classe de CPU ou d’une stratégie d’offload.

Task 15: Measure storage latency from the application’s perspective (fsync-heavy)

cr0x@server:~$ sudo fio --name=fsync-test --directory=/var/lib/postgresql --rw=write --bs=4k --size=256m --fsync=1 --numjobs=1 --iodepth=1 --runtime=20 --time_based --direct=1
fsync-test: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-3.33
fsync-test: (groupid=0, jobs=1): err= 0: pid=3312: Thu Jan  9 12:04:10 2026
  write: IOPS=210, BW=840KiB/s (860kB/s)(16.4MiB/20001msec); 0 zone resets
    clat (usec): min=900, max=250000, avg=4600.12, stdev=12000.55

Signification : Écritures 4k sync à ~210 IOPS avec des pics de latence millisecondes à centaines de ms. Ça tuera la latence tail d’une base de données quel que soit le CPU.

Décision : Corrigez le stockage d’abord (SSD/NVMe, cache adéquat, contrôleur, protection contre la perte de puissance). Les upgrades CPU ne vous rendront pas la latence fsync.

Task 16: Determine whether your CPU is the limiter under real load (quick stress)

cr0x@server:~$ stress-ng --cpu 4 --timeout 15s --metrics-brief
stress-ng: info:  [4102] setting to a 15 second run per stressor
stress-ng: info:  [4102] dispatching hogs: 4 cpu
stress-ng: metrc: [4102] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [4102] cpu              4200     15.01     59.80      0.02       279.8

Signification : Cela vous donne une base brute de débit CPU et aide à détecter le throttling thermique pendant une charge soutenue quand on le combine avec des vérifs de fréquence.

Décision : Si la performance s’effondre ou si la fréquence chute fortement pendant ce test, votre problème est thermique/puissance. Si c’est stable, le CPU peut soutenir le travail annoncé.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (la « mise à niveau CPU » qui ne l’était pas)

Une équipe SaaS de taille moyenne a hérité d’un service de reporting qui générait des PDFs à la demande. Le service tournait sur une petite machine qui, pour être juste, était sous-dimensionnée : CPU bas de gamme, RAM modeste et un SSD SATA unique. En fin de mois, les temps de réponse ont grimpé. Les tickets de support ont suivi. Le récit évident s’est formé rapidement : « Il nous faut un CPU plus rapide. »

Ils ont monté un CPU de meilleure gamme — plus de cœurs, fréquences plus élevées, cache plus grand. Les graphiques se sont améliorés pendant exactement une semaine. Puis la fin du mois est revenue, et la latence p99 a de nouveau explosé. Les gens ont accusé l’outil de monitoring parce qu’il « n’avait pas prédit » ça.

L’erreur était de supposer que la charge était CPU‑bound. Ce n’était pas le cas. Le pipeline de génération de PDF écrivait beaucoup de petits fichiers, appelait souvent fsync, puis compressait et téléchargeait les artefacts. Le device de stockage, bien qu’un SSD, était saturé par l’amplification d’écriture et la latence fsync sous travaux concurrents. L’utilisation CPU restait confortablement sous 50% pendant que l’iowait montait et que la file d’exécution semblait occupée.

Une fois qu’ils ont lancé un simple iostat -x et un test fio focalisé sur fsync, l’histoire a changé. Ils ont déplacé le répertoire scratch vers un volume NVMe plus rapide et réduit la fréquence des écritures synchrones quand la cohérence le permettait. Ils ont aussi limité la concurrence lors de la fin de mois. L’« incident CPU » a disparu sans toucher au CPU.

Conclusion : la légende de Celeron vit dans l’écart entre ce qui est facile à upgrader et ce qui est réellement lent. Ne soyez pas la personne qui échange le silicium parce que le graphique disque est ennuyeux.

Mini-récit 2 : L’optimisation qui s’est retournée contre l’équipe (économiser CPU en le dépensant)

Une autre équipe gérait un dépôt d’artefacts interne. Ce n’était pas énorme, mais la latence comptait pour les développeurs. Quelqu’un a eu une idée brillante : activer une compression agressive pour réduire les coûts stockage et accélérer les transferts réseau. En théorie c’est raisonnable — jusqu’à ce que vous le mettiez sur un petit CPU avec un cache limité et une performance mono‑thread modeste.

Le premier symptôme n’était pas une saturation CPU évidente. C’était une lenteur intermittente. Les téléchargements prenaient parfois plus de temps qu’avant. Les uploads parfois time‑out. Le système de stockage montrait un débit disque brut réduit mais un temps CPU système plus élevé. L’équipe réseau s’est fait blâmer. Puis l’équipe stockage. Finalement, le développeur qui a activé la compression a été pointé du doigt, ce qui est un anti‑pattern culturel mais aussi historiquement fréquent.

Le retour de bâton était classique : la compression sauvait des octets mais augmentait le travail CPU et rendait la latence spiky, surtout quand plusieurs clients touchaient le service en même temps. Les limitations de cache et la faible performance par cœur ont transformé la compression en point de contention. En outre, l’« optimisation » a déplacé le goulet du disque vers le CPU, mais seulement pendant les rafales — donc les graphiques moyens semblaient corrects et tout le monde a disputé.

La correction n’était pas d’« acheter un CPU plus gros » immédiatement. Ils ont d’abord mesuré : quels types de contenu bénéficiaient de la compression, quel coût CPU cela représentait, et où la douleur p99 survenait. Ils ont désactivé la compression pour les formats déjà compressés, mis en place des limites de concurrence sensées, puis envisagé un changement de CPU pour de la marge future.

Conclusion : sur des petits CPU — y compris beaucoup de Celeron — des optimisations « malignes » peuvent générer de la latence tail. Mesurez l’impact sous concurrence, pas en test mono‑client.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (notes de capacité et vérifications)

Une équipe gérant de petits services on‑prem (runners CI, Git interne, une pile métriques) standardisait sur du hardware modeste pour contenir les coûts. Certaines machines étaient de classe Celeron, choisies pour l’efficacité énergétique et la disponibilité. L’environnement fonctionnait parce qu’ils le traitaient comme de la production, pas comme un hobby.

La pratique ennuyeuse : chaque service avait une note d’une page « capacité et contraintes ». Elle listait le QPS attendu, les événements de pic, les fonctionnalités CPU requises (AES‑NI, virtualisation), l’objectif de latence stockage, et une liste noire (« pas de dédup, pas de VMs surprises, pas de compression lourde sur les nœuds les plus faibles »). Ils enregistraient aussi des mesures de référence après provisioning : latence fio, débit iperf, et un simple run CPU pour vérifier le throttling.

Un jour, une mise à jour du kernel a coïncidé avec une nouvelle charge CI. Les builds ont ralenti. Tout le monde a supposé que la nouvelle charge était simplement plus lourde. Mais le runbook les a forcés à re‑vérifier la baseline : la fréquence CPU était bloquée basse à cause d’un changement de gouverneur d’alimentation. Le récit « hardware lent » n’a jamais eu la chance de prendre racine parce qu’ils avaient des chiffres connus pour comparer.

Ils ont revert la politique du gouverneur, confirmé les thermiques, et le système est revenu à la normale. Personne n’a commandé de nouveau hardware. Personne n’a passé deux semaines à se disputer sur Slack pour savoir dont le code « est devenu plus lent ».

Conclusion : la différence entre « hardware budget qui marche » et « hardware budget qui fait mal » est l’hygiène opérationnelle. Celeron peut convenir si vous traitez les contraintes comme des éléments de première classe.

Erreurs courantes : symptômes → cause racine → correction

Cette section est volontairement spécifique. Si vous reconnaissez un motif de symptôme, vous pouvez généralement éviter une mise à niveau idiote ou un incident stupide.

1) Symptom: high load average, CPU not pegged

Cause racine : tâches coincées en attente I/O non interruptible (latence disque, stalls NFS, RAID dégradé) ou contention de verrous.

Correction : vérifiez vmstat (b et wa), puis iostat -x pour await et %util. Si c’est NFS, inspectez la latence du serveur et les pertes réseau. N’achetez pas de CPU pour l’instant.

2) Symptom: p99 latency spikes during backups or scrubs

Cause racine : I/O de fond saturant la file disque ; petit CPU ne peut pas masquer la latence stockage ; contention du scheduler.

Correction : throttlez backups/scrubs, utilisez ionice, planifiez hors‑pic, déplacez les données chaudes vers un stockage plus rapide. Si le CPU est aussi au taquet à cause de compression/chiffrement, ajustez ces paramètres.

3) Symptom: TLS termination slows down “randomly” under bursts

Cause racine : CPU par cœur insuffisant pour les rafales de handshakes, accélération manquante, ou trop de workers causant des context switches.

Correction : vérifiez le flag aes, ajustez le nombre de workers, activez la réutilisation de sessions, envisagez un CPU plus puissant si le taux de handshakes est limité par les cœurs.

4) Symptom: database feels fine until concurrency rises, then collapses

Cause racine : cache misses et latence mémoire amplifiés par un cache CPU réduit ; latence fsync stockage ; contention de verrous.

Correction : mesurez le taux de cache miss (perf), inspectez les plans de requête/index, vérifiez la latence fsync. Si perf montre un IPC bas et des cache misses élevés sur un CPU à faible cache, un CPU avec plus de cache peut être la bonne solution.

5) Symptom: “CPU upgrade” yields minimal improvement

Cause racine : le goulet est stockage, mémoire ou réseau ; le CPU n’était pas le limiteur.

Correction : baseline avant changements. Après changement, comparez iowait, disk await, retransmits et comportement swap. Arrêtez de traiter les CPU comme du désodorisant de performance.

6) Symptom: VM performance terrible even though host looks idle

Cause racine : absence de VT-x, mauvaise virtualisation d’I/O, ou RAM insuffisante provoquant du thrash cache sur l’hôte.

Correction : confirmez vmx ; vérifiez les modules KVM chargés ; assurez suffisamment de RAM ; préférez les conteneurs sur les puces d’entrée de gamme si les fonctions VM sont limitées.

7) Symptom: fans screaming, performance inconsistent

Cause racine : throttling thermique dans un petit châssis, poussière, ventilateur défaillant, ou paramètres BIOS conservateurs.

Correction : vérifiez dmesg pour le throttling ; inspectez les fréquences ; corrigez le flux d’air. Un CPU modeste qui tourne frais bat souvent un « meilleur » CPU qui surchauffe.

8) Symptom: storage throughput lower than expected on “fast” disks

Cause racine : le CPU limite pour checksumming/compression/parité ; ou la charge est de petites I/O aléatoires.

Correction : lancez fio pour classifier l’I/O ; inspectez l’utilisation CPU et l’iowait ; reconsidérez compression, mode RAID et l’alignement recordsize/block size. N’upgradez le CPU que si le temps CPU est le facteur limitant après tuning.

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

Étape par étape : décider si un Celeron est « suffisant » pour un rôle

1. Nommez la charge. « NAS » n’est pas une charge. « Partage SMB, 10 utilisateurs, copies de gros fichiers occasionnelles » l’est.
2. Notez l’objectif de performance. Débit ? Latence ? p99 ? Temps de build ? Fenêtre de sauvegarde ?
3. Listez les exigences strictes. VT-x requis ? AES‑NI requis ? RAM maximale nécessaire ? Lignes PCIe pour NVMe ?
4. Mesurez une baseline. Stabilité stress CPU, latence fio sur le système de fichiers cible, débit réseau, et un benchmark simple au niveau applicatif.
5. Classez les goulets. Utilisez le playbook de diagnostic rapide : CPU vs mémoire vs disque vs réseau.
6. Décidez des réglages avant d’acheter du hardware. Limites de concurrence, stratégie de cache, politique de compression/chiffrement.
7. Ensuite seulement, choisissez la classe CPU. Si vous êtes lié par la latence mémoire, plus de cache et des cœurs plus forts comptent. Si vous êtes limité par le stockage, dépensez d’abord sur le stockage.
8. Documentez les contraintes. Mettez par écrit « pas de compression lourde sur ce nœud ». Le futur vous oubliera.

Checklist : chemin d’upgrade sûr pour systèmes budget

• Améliorez le stockage d’abord si vous voyez des pics await ou de latence fsync.
• Ajoutez de la RAM si vous voyez du swapping ou des fautes majeures sous charge normale.
• Corrigez les thermiques avant de changer le silicium.
• Confirmez les flags fonctionnels (vmx, aes) avant de choisir un cas d’usage.
• Benchmarquez sous concurrence, pas seulement en test mono‑utilisateur.
• Gardez un plan de rollback : paramètres BIOS, versions du kernel, politiques de gouverneur.

Checklist : quand éviter les CPU de classe Celeron

• Points de terminaison TLS à fort taux de handshakes ou pipelines crypto lourds sans marge claire.
• Noeuds primaires de bases de données où la latence p99 compte et les working sets dépassent le cache.
• Hôtes multi‑VM où vous avez besoin d’une performance par cœur constante et de fonctionnalités de virtualisation complètes.
• Noeuds de stockage faisant de la parité/codage d’effacement/compression à haut débit visé.
• Tout ce dont vous ne pouvez pas contrôler la charge de fond et pour lequel vous avez besoin d’une latence stable.

FAQ

1) Was Celeron “just a worse Pentium”?

Parfois. Mais souvent c’était le même cœur sous‑jacent avec moins de cache ou des vitesses de bus plus faibles. La différence entre « pire » et « suffisant » dépend entièrement de la charge et du comportement mémoire.

2) Why did the Celeron 300A become famous?

Parce qu’il pouvait souvent fonctionner à une vitesse de bus plus élevée que sa spécification officielle sur certaines cartes mères, offrant des performances proches des pièces plus chères. C’était une intersection rare d’architecture et de culture d’overclocking.

3) Can I run a NAS on a Celeron?

Oui, si votre charge consiste principalement à servir des fichiers et que vos objectifs de débit ne sont pas extrêmes. Mais des fonctionnalités comme le chiffrement, la compression et les checks d’intégrité peuvent vous rendre CPU‑limités. Mesurez la latence fsync et la marge CPU.

4) Why do people say “cache matters” so much for Celeron?

Parce que les coupures Celeron visaient souvent le cache, et le cache fait la différence entre un accès local rapide et des allers‑retours lents en mémoire principale. Beaucoup de charges serveur sont sensibles à la latence mémoire même quand l’utilisation CPU paraît modérée.

5) How do I tell if I should upgrade CPU or storage first?

Si iowait est élevé et que await disque l’est aussi, stockage d’abord. Si le CPU est saturé en user/system avec un iowait bas et une file d’exécution élevée, CPU d’abord. Si les deux sont mauvais, corrigez la latence stockage d’abord pour rendre les mesures CPU significatives.

6) Do all Celerons support virtualization (VT-x)?

Non. Cela varie selon la génération et le SKU. Vérifiez les flags de lscpu pour vmx. Si absent, n’espérez pas que KVM offre une performance VM acceptable.

7) Are modern Celerons always low-power Atom-class cores?

Pas toujours, mais beaucoup sont dérivés de designs basse consommation. Cela change le profil de performance : souvent adapté aux services légers, moins bon pour la latence mono‑thread ou le calcul lourd.

8) Is overclocking relevant to the Celeron legend today?

Comme stratégie courante, non. La légende reste une mémoire culturelle, mais les plateformes modernes verrouillent les choses et les contraintes thermiques sont plus strictes. Pour la production, l’overclocking est un passe‑temps, pas un plan d’exploitation.

9) What’s the biggest operational risk with low-end CPUs?

Sous‑estimer la latence tail sous charges en rafales, surtout quand des fonctionnalités CPU manquent ou quand des tâches de fond se disputent des cœurs limités. Le mode d’échec est « bien la plupart du temps », et c’est comme ça que naissent les incidents.

10) If I already have a Celeron box, how do I make it behave?

Gardez la latence stockage basse, évitez les fonctionnalités de fond coûteuses (dédup, compression lourde), limitez la concurrence et surveillez les thermiques. Écrivez les contraintes pour que le prochain « petit changement » ne transforme pas la machine en radiateur bruyant.

Conclusion : prochaines étapes pratiques

Celeron est devenu une légende de la mise à niveau parce qu’il a exploité une vérité que nous réapprenons sans cesse : la performance concerne le système, pas le composant avec le plus gros budget marketing. Parfois une puce amputée est exactement ce qu’il faut. Parfois c’est un piège avec une étiquette amicale.

Prochaines étapes que vous pouvez faire cette semaine :

1. Baselinez votre système actuel avec les commandes ci‑dessus : flags CPU, signaux de throttling, iowait, await disque, et un test fio ciblé.
2. Rédigez une note d’une page sur les contraintes pour chaque machine : ce qu’elle est autorisée à exécuter, ce qu’elle doit ne jamais exécuter, et à quoi ressemblent les métriques « normales ».
3. Dépensez l’argent là où est le goulet : latence stockage d’abord pour bases de données et charges fsync‑intensives ; cache/CPU pour charges liées à la latence mémoire ; RAM pour tout ce qui swappe ; corrections réseau pour pertes et retransmits.
4. Si vous achetez un upgrade CPU, faites‑le avec des preuves : compteurs perf, chiffres de latence, et un benchmark avant/après sous concurrence.

La légende n’est pas que Celeron était secrètement premium. La légende, c’est que des gens intelligents ont appris — parfois par accident — que le correctif le moins coûteux est celui qui match le vrai goulet.