Comment tester correctement la RAM sur les serveurs QNAP à l'aide de MemHound

Tester la RAM sur un système d'exploitation actif (espace utilisateur) est un défi d'ingénierie. Le système d'exploitation, les services de virtualisation et de mise en cache (l'ARC de ZFS avant tout) continuent de réserver de l'espace d'adressage et d'en bloquer l'accès.

MemHound, la fenêtre Memory Doctor de StorageDiag Workbench, procède par paliers croissants : Quick → Standard → Deep → Hammer → Boot. Il verrouille toute la RAM libre qu'il peut prendre, moins une marge de 256 Mo, y écrit des motifs de test et les relit. Il garde chaque bloc jusqu'à la fin de la passe : le noyau doit donc lui céder chaque page libre. Voici comment vérifier la stabilité de la mémoire pour votre configuration et votre système de fichiers.

1. Quickbalayage rapide, le NAS continue de fonctionner
2. Standardinversions mobiles, le NAS continue de fonctionner
3. Deeparrête les services, libère l'ARC
4. Hammerrow-hammer sur chaque cœur
5. Bootla clé USB, en dehors du système NAS

01Diagnostic quotidien sur QTS (ext4)

Avec un système de fichiers traditionnel (ext4), QTS ne réserve pas de grandes quantités de RAM pour lui-même, ce qui facilite un test fiable depuis le système en cours d'exécution. Les défauts de mémoire apparaissent souvent dans l'espace utilisateur, c'est pourquoi des tests Quick réguliers sont efficaces.

1. Désactivez les services réseau non critiques (Samba, NFS, AFP).
2. Arrêtez les applications gourmandes en ressources dans l'App Center (stations de bureau HDMI, conteneurs, machines virtuelles) et ne laissez que StorageDiag en cours d'exécution. Gardez un seul onglet de navigateur sur le NAS.
3. Avec les caches libérés et les services arrêtés, la majeure partie de la RAM physique est libre pour le test. La carte Quick est étiquetée DAILY lorsqu'au moins 90 % de la RAM est libre.
4. Exécutez le test Quick. Il est rapide : après une vérification des adresses, il exécute deux motifs et saute le vidage du cache ligne par ligne qu'utilise Standard. Définissez 1 à 3 passes (le champ Passes accepte de 1 à 16 et vaut 1 au départ). Si la mémoire qu'il atteint présente un défaut matériel, le test le trouve presque immédiatement.

02Diagnostic sur QuTS hero (ZFS)

Le système de fichiers ZFS utilise l'ARC (Adaptive Replacement Cache), qui peut prendre la majeure partie de la RAM disponible. Dans ce cas, un simple test Quick ne couvre qu'une fraction de la mémoire.

1. Sélectionnez le test Deep au lieu de Quick.
2. Une fois que vous confirmez (Stop services & test), MemHound arrête les services du NAS et les applications de l'App Center (le panneau Web reste accessible), vide l'ARC ZFS et vide les caches du noyau. Cela libère la majeure partie de la mémoire physique pour le test : sur un TS-1288X de 128 Go, la mémoire disponible est passée de 96,6 Go à 116,9 Go.
3. Déroulement : une passe Quick sur la RAM libérée s'exécute en premier. Si elle trouve des erreurs, la procédure s'arrête tôt et vous fait gagner du temps. Si elle n'en trouve aucune, l'outil passe à la passe Standard.
4. Temps d'arrêt : les services restent indisponibles pendant leur arrêt et pendant l'exécution des deux passes, et une passe Standard sur une grande quantité de RAM peut prendre des heures. Ils reviennent d'eux-mêmes à la fin du test, si vous l'annulez, si le processus de test s'arrête brutalement, et au plus tard deux heures après le début. Si le seul arrêt des services prend plus de 30 minutes, le test est abandonné et tout est restauré.

03Test absolu (Mode Rescue / hors ligne)

Lorsque le journal du noyau (klog) signale une mémoire instable (segfaults spontanés dans plusieurs programmes, call traces, erreurs machine ou erreurs EDAC) mais que les tests depuis le système en cours d'exécution (Quick, Deep) se terminent par PASS, passez à un environnement isolé. Cela contourne complètement le système d'exploitation du NAS.

Option A : une clé USB bootable (recommandé)

La clé USB a été conçue pour que tout le test s'exécute de lui-même, y compris sur les unités sur lesquelles vous ne pouvez pas brancher de moniteur ni de clavier. Aucune pression de touche n'est nécessaire. L'entrée de démarrage fait de la clé USB le choix par défaut au prochain redémarrage, le test démarre de lui-même et publie sa progression à l'adresse du NAS, que la fenêtre MemHound lit pour vous. Après un PASS, le NAS redémarre de lui-même sous QTS et la fenêtre affiche le verdict ; après un défaut de mémoire, le test éteint le NAS (voir ci-dessous). Un moniteur et un clavier ne sont nécessaires que lorsque le firmware ne peut pas recevoir l'entrée de démarrage et que la clé USB doit être lancée à partir du menu de démarrage de l'unité.

1. Dans la fenêtre MemHound, cliquez sur Create bootable USB dans la barre de titre.
2. Branchez n'importe quelle clé USB de plus de 192 Mo dans un port USB du QNAP. Tout ce qui s'y trouve est effacé, et son formatage actuel n'a pas d'importance.
3. Cliquez sur Update the image lorsque l'assistant propose une version plus récente (Download the image la première fois), puis suivez les invites : Continue, tapez le nom du périphérique, Erase and write, Add the boot entry.
4. Redémarrez le serveur à partir de la clé USB de diagnostic préparée (Restart now and test). Une fois le NAS redémarré, la fenêtre affiche le verdict.

Lorsque le test au démarrage ne se déroule pas comme prévu

• Le NAS ne lance pas le test à partir de la clé USB. Add the boot entry place un fichier, grub/custom.cfg, sur la partition de démarrage du NAS lui-même. À la mise sous tension, le chargeur de démarrage du NAS (GRUB) recherche un volume étiqueté MEMHOUND et le démarre s'il en trouve un. GRUB ne voit une clé USB qu'à travers la prise en charge USB du firmware lui-même. Le NAS démarre donc QTS comme d'habitude si le firmware ne présente pas la clé USB à la mise sous tension (ce que certaines clés USB bon marché ou de mauvaise qualité ne font pas), si le démarrage USB est désactivé dans la configuration du firmware, ou pour une raison que le firmware n'affiche pas. Essayez une autre clé USB, un port USB à l'arrière, ou lancez la clé USB à partir du menu de démarrage de l'unité (F11, ou la touche utilisée par ce modèle, à la mise sous tension). L'assistant indique This firmware cannot be given a boot entry lorsque le chargeur de démarrage ne lit pas du tout le fichier, et The boot entry here is an old one lorsqu'une version antérieure l'a écrit (Replace the boot entry). Une clé USB dont le test s'est déjà déroulé n'est pas relancée : réécrivez-la avec Create bootable USB pour tester à nouveau.
• Le NAS s'est éteint tout seul et ne s'est pas rallumé. C'est ce que fait le test lorsqu'il détecte un défaut de mémoire : il éteint volontairement le NAS, afin que rien ne soit écrit sur les disques avec de la mémoire dans cet état, et il ne le redémarre pas. Un test réussi redémarre le NAS sous QTS. Un NAS qui s'est éteint pendant le test au démarrage et qui est resté éteint indique donc un défaut de mémoire. Les détails se trouvent sur la clé USB (FAT32, label MEMHOUND) : lisez /memhound/report-<time>.txt et map-<time>.json sur n'importe quel ordinateur, ou branchez la clé USB sur un NAS sain exécutant StorageDiag Workbench et ouvrez MemHound, qui la lit de lui-même.

Option B : Mode Rescue (sans disques configurés) via SSH

Si vous préférez travailler à distance et connaissez les bases de la ligne de commande, ce mode permet un test complet sans clé USB.

1. Connectez-vous au serveur QNAP via SSH.
2. Dans le menu texte (QTS Console Management), choisissez de redémarrer le serveur en mode Rescue (sans disques configurés).
3. Après le redémarrage, Qfinder affiche le serveur comme « uninitialized » (non initialisé). C'est normal.
4. Activez SSH depuis Qfinder. Connectez-vous en tant que admin (sur QTS 5.2 et versions ultérieures, le mot de passe par défaut est le mot de passe cloud ; sur les anciennes versions, c'est l'adresse MAC complète en majuscules sans deux-points).
5. Téléchargez et décompressez MemHound avec le premier bloc ci-dessous, puis lancez les tests en mode texte avec le second.

# Télécharger et décompresser MemHound
arch=$(uname -m)
[ "$arch" = armv7l ] && arch=armhf
wget https://www.qnaputilities.com/pub/memhound/bin/memhound.tar.gz
tar zxvf memhound.tar.gz
chmod +x memhound-*

# Test Quick avec 2 passes (point de départ recommandé)
./memhound-$arch --quick --passes 2 --ui

# Test Standard (après un Quick PASS avec End reason : completed)
./memhound-$arch --standard --ui

Quick vérifie d'abord les adresses, puis écrit un damier (checkerboard) et une inversion mobile aléatoire (random moving inversion). Standard répète ces deux motifs et en ajoute onze autres, le tout en une seule exécution, et effectue une passe à moins que vous n'ajoutiez --passes. Lorsque l'interface texte se ferme, MemHound affiche un résumé en anglais. Passez à Standard lorsqu'il indique Verdict : PASS et End reason : completed : une exécution écourtée par manque de mémoire indique tout de même PASS, avec End reason : aborted: …. La section 04 explique les autres verdicts.

04Comment lire les résultats

MemHound décide selon des règles fixes, et ces règles dépendent du test. Quick, Standard, Deep et Hammer recherchent des défauts dans la mémoire qu'ils atteignent. Benchmark and Quality, plus loin, qualifie un kit de mémoire entier.

Quick, Standard, Deep et Hammer

• Défauts matériels (hard) et transitoires. Une seule lecture erronée ne condamne pas un module. MemHound la compte comme transitoire : la carte le marque Suspect et le résumé textuel indique PASS_WITH_TRANSIENTS. Un défaut devient matériel (hard) lorsqu'une vérification ultérieure échoue à nouveau à la même adresse de la propre mémoire de MemHound (l'adresse virtuelle ; l'adresse physique est affichée à côté sous la forme p=), après deux occurrences par défaut (--hard-threshold 2). Tout défaut matériel rend le verdict FAIL.
• Ce que dit la fenêtre Workbench. Sa ligne d'état compte les deux types, par exemple FAIL — 0 hard fault(s), 1 transient. Sans défaut matériel, répétez le test hors ligne (la clé USB ou le mode Rescue) avant d'incriminer un module : le guide intégré à l'application considère un résultat uniquement transitoire comme une raison de refaire le test hors ligne, jamais de demander un RMA (retour). Le résumé textuel ajoute que de tels résultats peuvent indiquer des problèmes d'alimentation, de chaleur ou de timing marginal.
• Compteurs ECC et journal du noyau (kernel log). Les compteurs ECC (EDAC) et les événements du journal du noyau sont affichés à côté du résultat, et le résumé ajoute <== HARDWARE ECC ERRORS DURING TEST lorsqu'un compteur a augmenté. Ils ne modifient pas le verdict : vérifiez-les donc vous-même.
• Comment l'exécution s'est terminée. Le résumé se termine par End reason : completed, stopped by user ou aborted: …. Une exécution qui ne s'est pas terminée par completed n'a pas testé tout ce qu'elle avait prévu, quelle que soit sa ligne de verdict.

Bon à savoir : Benchmark and Quality

Le bouton Benchmark and Quality dans la barre de titre de MemHound mesure la bande passante mémoire soutenue par rapport au chiffre JEDEC des modules installés, vérifie la gigue de latence (jitter) et échoue (FAIL) à la moindre erreur de bit. Son verdict est PASS (ou PASS-UNQUALIFIED), MARGINAL, FAIL ou INCONCLUSIVE, et ses règles sont plus strictes que celles de la recherche de défauts.

• Erreurs. Une erreur de bit, une erreur ECC non corrigée (UE) ou un événement critique du noyau enregistré pendant l'exécution entraîne le verdict FAIL. Les événements critiques sont un Machine Check ou « Hardware Error », une erreur de mémoire non corrigée, une défaillance de la mémoire, une corruption de données ou un kernel panic. Une erreur ECC corrigée (CE) limite le verdict à MARGINAL : le module fonctionne, mais le kit ne peut pas être certifié. Les Segfaults, call traces, Oops et OOM kills sont affichés mais ne changent pas le verdict.
• Un kit apparié (matched kit). Le test qualifie un kit apparié. Il échoue à la vérification (gate) lorsque les modules diffèrent (par numéro de pièce, ou par taille, vitesse, type et ECC lorsque DMI ne donne pas le numéro de pièce), lorsqu'il y a 3 modules ou un nombre impair supérieur à 4, ou lorsque les canaux A et B ont des capacités différentes. L'exécution se poursuit pour information, mais le verdict est FAIL, et le résultat n'est ni enregistré ni partagé. Lorsque DMI ne signale rien, la vérification est ignorée.
• Un NAS très sollicité. Lorsque la bande passante est insuffisante (FAIL ou MARGINAL) ou que la gigue de latence échoue alors que le NAS est très sollicité (une charge sur 1 minute supérieure à 0,6 par CPU), à court de mémoire (moins de 40 % libre au début) ou bridé (throttled), le verdict est INCONCLUSIVE : l'état du système est en cause, pas les modules. Une exécution arrêtée par vous ou par la protection de la mémoire est également INCONCLUSIVE. Les erreurs de bits, les UE, les événements critiques du noyau, les erreurs de motif, les atténuations de bits (bit fade) et la vérification du kit (kit gate) ne sont jamais atténués de cette façon.

05La RAM dans un NAS, bonnes pratiques et particularités matérielles

Avant de blâmer les disques ou le réseau pour des transferts lents, il est utile de savoir ce que la mémoire d'un NAS a de particulier. La mémoire d'un NAS n'est pas la mémoire d'un PC de jeu. Un NAS fonctionne 24h/24 et 7j/7 sous une charge constante : tampons système, le cache ZFS (ARC), les machines virtuelles et les conteneurs. Il attend de sa mémoire de la stabilité et de la compatibilité, pas des fréquences d'horloge record. Il tolère également moins les erreurs qu'un PC de bureau : une longue disponibilité (uptime) et une charge constante font ressortir des erreurs rares que des redémarrages fréquents cacheraient sur un PC.

Sur une plate-forme sans ECC (un TS-464, par exemple), aucun paramètre ne permet de l'activer. Les UDIMM sont sans tampon (unbuffered) ; les RDIMM et les LRDIMM sont à registre (registered) et déchargent le contrôleur : un canal accepte donc plus de modules de grande capacité.

Trois modules peuvent-ils être plus lents que deux ? Oui, sur AMD avant tout. Un contrôleur de mémoire Ryzen abaisse son horloge garantie en fonction du nombre de modules et de rangs par canal : DDR4 3200 avec un module par canal, 2933 avec deux modules à un seul rang, 2666 avec deux modules à double rang. Plus de modules donnent plus de capacité et moins de bande passante ; lorsqu'une tâche manque de mémoire, plus de capacité vaut quand même mieux que manquer de mémoire et passer en swap.