DEV Community

Remy Jacquand
Remy Jacquand

Posted on

Pourquoi mon serveur est devenu lent : le cas du disque SMR

#devjournal #linux #performance #sre

Récemment, mon serveur Lenovo Linux Mint est devenu très lent, même pour se connecter en SSH. Après quelques minutes d’attente, j’ai commencé à diagnostiquer le problème. Voici ce que j’ai découvert et ce que cela signifie.

Symptômes

  • SSH extrêmement lent.
  • apt update et autres commandes système qui mettent beaucoup de temps.
  • Serveur globalement réactif mais “ramé” sur tout ce qui touche le disque.

Diagnostic initial

J’ai commencé par vérifier :

  • RAM / CPU : usage normal, pas de saturation.
  • Disque : utilisé à 798 Go / 915 Go (~87% de remplissage).
  • Docker / conteneurs : beaucoup d’applications média (Jellyfin, qbittorrent, Sonarr, Radarr, AppFlowy…).

Le disque semblait être le principal coupable.

Vérification SMART

J’ai lancé :

sudo smartctl -a /dev/sda
Enter fullscreen mode Exit fullscreen mode

Résultats clés :

  • Modèle : Western Digital Blue Mobile (SMR)
  • Capacité : 1 To
  • SMART overall-health : PASSED
  • Secteurs réalloués : 0
  • Pending / erreurs : 0
  • Heures de fonctionnement : 12 667 h
  • Température : 47°C

Interprétation : le disque est en parfait état matériel, rien ne justifie une lenteur mécanique.

Le problème réel : la technologie SMR

  • SMR = Shingled Magnetic Recording, conçu pour stockage froid, peu d’écritures.
  • Quand le disque est presque plein (>80%) et qu’il reçoit des écritures continues (Docker, torrents, scans), il doit réécrire de grandes bandes de données pour chaque petite écriture.
  • Conséquence : latence énorme, même pour SSH ou des lectures simples.

Actions effectuées

  1. Libération d’espace disque (~100 Go).
  2. Redémarrage du serveur.
  3. Lancement d’un **fstrim -av** pour indiquer au SMR quelles zones sont libres : 
/boot/efi: 504,8 MiB trimmed
/: 426,8 GiB trimmed
Enter fullscreen mode Exit fullscreen mode
  • Résultat : le disque a reconnu 426 Go comme libres et peut désormais optimiser ses écritures.
  • Après quelques minutes, le SSH et les mises à jour système sont redevenus plus fluides.

Analyse I/O

Pendant le problème, avec iostat :

  • %util disque : ~96%
  • await lectures : ~50 ms
  • CPU libre : 73%

Conclusion : le goulot d’étranglement était le disque, pas le CPU ni la RAM.

Conclusion et recommandations

  1. Les disques SMR ne sont pas adaptés pour :
    • Docker intensif
    • Torrents
    • Bases de données
    • Applications média avec scans fréquents
  2. Même après libération d’espace et fstrim, le disque reste lent si le remplissage et l’écriture continue reprennent.
  3. Pour un serveur Docker média, préférer un SSD ou un HDD CMR classique.
    • SSD : rapide et fiable pour écritures continues
    • HDD CMR : meilleur pour gros volumes mais encore limité pour Docker très actif
  4. En cas d’achat futur, vérifier technologie SMR vs CMR pour éviter ce type de goulot d’étranglement.

TL;DR

Mon serveur est lent non pas parce que le disque est mort, mais parce qu’un disque SMR plein et actif ne peut pas suivre un usage Docker intensif. Libérer de l’espace et faire un fstrim aide, mais la solution définitive est de passer sur SSD ou HDD CMR.

Top comments (0)