Come testare correttamente la RAM sui server QNAP utilizzando MemHound

Testare la RAM su un sistema operativo live (userspace) è una sfida ingegneristica. Il sistema operativo, i servizi di virtualizzazione e caching (soprattutto lo ZFS ARC) continuano a riservare spazio di indirizzamento e a bloccarne l'accesso.

MemHound, la finestra Memory Doctor di StorageDiag Workbench, procede per gradi lungo una scala di escalation: Quick → Standard → Deep → Hammer → Boot. Blocca tutta la RAM libera che può prendere, meno un margine di 256 MB, vi scrive pattern di test e li rilegge. Trattiene ogni blocco fino alla fine del passaggio, così il kernel deve cedere ogni pagina libera. Di seguito trovi come verificare la stabilità della memoria per la tua configurazione e il tuo file system.

1. Quickscansione veloce, il NAS continua a servire dati
2. Standardmoving inversions, il NAS continua a servire dati
3. Deepinterrompe i servizi, libera l'ARC
4. Hammerrow-hammer su ogni core
5. Bootla pendrive, all'esterno del sistema NAS

01Diagnostica quotidiana su QTS (ext4)

Con un file system tradizionale (ext4), QTS non riserva grandi quantità di RAM per sé, rendendo più facile un test affidabile dal sistema in funzione. I guasti della memoria si manifestano spesso nello spazio utente, il che rende efficaci i test rapidi regolari.

1. Disattiva i servizi di rete non critici (Samba, NFS, AFP).
2. Interrompi le app ad alto consumo di risorse nell'App Center (stazioni desktop HDMI, container, macchine virtuali) e lascia in esecuzione solo StorageDiag. Tieni aperta una sola scheda del browser sul NAS.
3. Con le cache liberate e i servizi interrotti, la maggior parte della RAM fisica è libera per il test. La scheda Quick è contrassegnata come DAILY quando almeno il 90% della RAM è libero.
4. Esegui il test Quick. È veloce perché esegue due pattern dopo un controllo degli indirizzi e salta lo svuotamento della cache per linea utilizzato dalla modalità Standard. Imposta da 1 a 3 passaggi (il campo Passes accetta da 1 a 16 e inizia da 1). Se la memoria raggiunta presenta un guasto hardware, il test lo rileva quasi immediatamente.

02Diagnostica su QuTS hero (ZFS)

Il file system ZFS utilizza l'ARC (Adaptive Replacement Cache), che può occupare gran parte della RAM disponibile. In questo caso un semplice test Quick copre solo una frazione della memoria.

1. Seleziona il test Deep invece di Quick.
2. Una volta confermato (Stop services & test), MemHound interrompe i servizi del NAS e le app dell'App Center (il pannello web rimane attivo), svuota lo ZFS ARC e scarta le cache del kernel. Ciò libera la maggior parte della memoria fisica per il test: su un TS-1288X da 128 GB, la memoria disponibile è passata da 96,6 GB a 116,9 GB.
3. Flusso di lavoro: prima viene eseguito un passaggio Quick sulla RAM liberata. Se trova errori, la procedura termina in anticipo risparmiando tempo. Se non ne trova, lo strumento passa al test Standard.
4. Tempo di inattività: i servizi restano inattivi mentre vengono interrotti e mentre vengono eseguiti entrambi i passaggi, e un passaggio Standard su molta RAM può richiedere ore. Si riattivano da soli al termine del test, quando lo si annulla, se il processo di test si interrompe in modo anomalo e, al più tardi, due ore dopo l'avvio. Se la sola interruzione dei servizi richiede più di 30 minuti, il test viene abbandonato e tutto viene ripristinato.

03Test assoluto (Modalità Rescue / offline)

Quando il log del kernel (klog) indica memoria instabile (segfaults spontanei in vari programmi, call traces, machine checks o errori EDAC) ma i test dal sistema in funzione (Quick, Deep) terminano con PASS, passa a un ambiente isolato. Un ambiente isolato aggira del tutto il sistema operativo del NAS.

Opzione A: una pendrive USB avviabile (consigliata)

La pendrive è stata creata in modo che l'intero test venga eseguito da solo, anche su unità a cui non è possibile collegare monitor e tastiera. Nulla richiede la pressione di un tasto. La voce di avvio rende la pendrive predefinita per il riavvio successivo, il test si avvia da solo e pubblica i suoi progressi all'indirizzo del NAS, che la finestra di MemHound legge per te. Dopo un PASS il NAS si riavvia in QTS da solo e la finestra mostra il verdetto; dopo un errore di memoria il test spegne il NAS (vedi sotto). Monitor e tastiera sono necessari solo quando il firmware non accetta la voce di avvio e la pendrive deve essere avviata dal menu di avvio dell'unità.

1. Nella finestra di MemHound, fai clic su Create bootable USB nella barra del titolo.
2. Collega una qualsiasi pendrive USB più grande di 192 MB a una porta USB del QNAP. Tutto il suo contenuto verrà cancellato, e la formattazione attuale non ha importanza.
3. Fai clic su Update the image quando la procedura guidata offre una build più recente (Download the image la prima volta), quindi segui le istruzioni: Continue, digita il nome del dispositivo, Erase and write, Add the boot entry.
4. Riavvia il server dalla pendrive diagnostica preparata (Restart now and test). Quando il NAS è di nuovo online, la finestra mostra il verdetto.

Quando il test all'avvio non va come previsto

• Il NAS non avvia il test dalla pendrive. Add the boot entry inserisce un file, grub/custom.cfg, sulla partizione di avvio del NAS. All'accensione, il boot loader del NAS (GRUB) cerca un volume con etichetta MEMHOUND e lo avvia quando lo trova. GRUB rileva una pendrive USB solo tramite il supporto USB nativo del firmware, quindi il NAS avvia QTS come di consueto quando il firmware non presenta la pendrive all'accensione (alcune pendrive economiche o di scarsa qualità non lo fanno), quando l'avvio da USB è disattivato nelle impostazioni del firmware o per un motivo che il firmware non mostra. Prova con un'altra pendrive, una porta USB sul retro, oppure avvia la pendrive dal menu di avvio dell'unità (F11, o il tasto utilizzato da questo modello, all'accensione). La procedura guidata indica This firmware cannot be given a boot entry quando il boot loader non legge affatto il file, e The boot entry here is an old one quando ne è stata scritta una versione precedente (Replace the boot entry). Una pendrive il cui test è già stato eseguito non viene avviata di nuovo: scrivila di nuovo con Create bootable USB per eseguire un altro test.
• Il NAS si è spento e non si è più riacceso. Questo è ciò che fa il test quando rileva un guasto alla memoria: spegne appositamente il NAS, in modo che nulla scriva sui dischi con la memoria in quello stato, e non lo riavvia. Un test superato riavvia invece il NAS su QTS. Un NAS che si è spento da solo durante il test all'avvio ed è rimasto spento indica quindi un guasto alla memoria. I dettagli si trovano sulla pendrive (FAT32, etichetta MEMHOUND): leggi /memhound/report-<time>.txt e map-<time>.json su qualsiasi computer, oppure inserisci la pendrive in un NAS funzionante con StorageDiag Workbench e apri MemHound, che la leggerà da solo.

Opzione B: Modalità Rescue (senza dischi configurati) tramite SSH

Se preferisci lavorare in remoto e conosci le basi della riga di comando, questa modalità offre un test completo senza pendrive USB.

1. Accedi al server QNAP tramite SSH.
2. Nel menu di testo (QTS Console Management), scegli di riavviare il server in modalità Rescue (senza dischi configurati).
3. Dopo il riavvio, Qfinder rileva il server come «non inizializzato» (uninitialized). Questo è normale.
4. Abilita l'SSH da Qfinder. Accedi come admin (su QTS 5.2 e versioni successive la password predefinita è la password cloud; sulle versioni precedenti è l'indirizzo MAC completo in maiuscolo senza i due punti).
5. Scarica e decomprimi MemHound con il primo blocco di codice qui sotto, quindi avvia i test in modalità testuale con il secondo.

# Scarica e decomprimi 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 con 2 passaggi (punto di partenza consigliato)
./memhound-$arch --quick --passes 2 --ui

# Test Standard (dopo un PASS Quick con End reason : completed)
./memhound-$arch --standard --ui

Quick controlla prima gli indirizzi, quindi scrive una scacchiera e una moving inversion casuale. Standard ripete questi due pattern e ne aggiunge altri undici, tutti in un'unica esecuzione, ed effettua un passaggio a meno che non si aggiunga --passes. Quando l'interfaccia di testo si chiude, MemHound stampa un riepilogo in inglese. Passa a Standard quando indica Verdict : PASS ed End reason : completed: un'esecuzione interrotta prima del tempo perché la memoria scarseggia indica comunque PASS, con End reason : aborted: …. La sezione 04 spiega gli altri verdetti.

04Come interpretare i risultati

MemHound decide in base a regole fisse, e tali regole dipendono dal test. Quick, Standard, Deep e Hammer cercano difetti nella memoria che raggiungono. Benchmark and Quality, spiegato più avanti, qualifica un intero kit di memoria.

Quick, Standard, Deep e Hammer

• Guasti hardware (hard) e transitori. Una singola lettura errata non condanna un modulo. MemHound la conta come transitoria: la mappa la segna come Suspect e il riepilogo testuale indica PASS_WITH_TRANSIENTS. Un guasto diventa hard quando un controllo successivo fallisce di nuovo allo stesso indirizzo nella memoria occupata da MemHound (l'indirizzo virtuale; quello fisico viene stampato accanto come p=), di default dopo due riscontri (--hard-threshold 2). Qualsiasi guasto hard porta al verdetto FAIL.
• Cosa dice la finestra di Workbench. La sua riga di stato conta entrambi i tipi, ad esempio FAIL — 0 hard fault(s), 1 transient. In assenza di un guasto hard, ripeti il test offline (la pendrive o la modalità Rescue) prima di incolpare un modulo: la guida integrata nell'app considera un risultato con soli errori transitori come un motivo per un retest offline, mai per una richiesta di RMA. Il riepilogo di testo aggiunge che tali risultati possono indicare problemi di alimentazione, calore o tempistiche marginali.
• Contatori ECC e log del kernel. I contatori ECC (EDAC) e gli eventi del log del kernel vengono visualizzati accanto al risultato e il riepilogo aggiunge <== HARDWARE ECC ERRORS DURING TEST quando un contatore aumenta. Non modificano il verdetto, quindi dovrai controllarli tu stesso.
• Come si è conclusa l'esecuzione. Il riepilogo termina con End reason: completed, stopped by user oppure aborted: …. Un'esecuzione che non termina con completed non ha testato tutto ciò che doveva, a prescindere da cosa indichi la riga del verdetto.

Buono a sapersi: Benchmark and Quality

Il pulsante Benchmark and Quality nella barra del titolo di MemHound misura la larghezza di banda sostenuta della memoria rispetto al valore JEDEC dei moduli installati, controlla il jitter della latenza e fallisce se rileva qualsiasi errore a livello di bit. Il suo verdetto è PASS (oppure PASS-UNQUALIFIED), MARGINAL, FAIL o INCONCLUSIVE e le sue regole sono più rigide rispetto a quelle della ricerca dei guasti.

• Errori. Un solo errore a livello di bit, un errore ECC non corretto (UE) o un evento critico del kernel registrato durante l'esecuzione porta il verdetto a FAIL. Gli eventi critici sono i machine check o gli «Hardware Error», un errore di memoria non corretto, un memory failure, la corruzione dei dati o un kernel panic. Un errore ECC corretto (CE) limita il verdetto a MARGINAL: il modulo funziona, ma il kit non può essere certificato. Segfaults, call traces, Oops e kill di tipo OOM vengono mostrati ma non cambiano il verdetto.
• Un kit abbinato. Il test qualifica un kit correttamente abbinato (matched). Il test di sbarramento (gate) fallisce quando i moduli differiscono (per codice prodotto, oppure per dimensioni, velocità, tipo ed ECC qualora il DMI non fornisca il codice prodotto), quando vi sono 3 moduli o un numero dispari superiore a 4, oppure quando i canali A e B hanno capacità diverse. L'esecuzione prosegue a scopo informativo, ma il verdetto è FAIL, e il risultato non viene né salvato né condiviso. Quando il DMI non riporta alcun dato, lo sbarramento viene saltato.
• Un NAS sovraccarico. Quando la larghezza di banda non è sufficiente (FAIL o MARGINAL) o il jitter di latenza fallisce mentre il NAS è sotto carico (un load average a 1 minuto superiore a 0,6 per CPU), a corto di memoria (meno del 40% libero all'avvio) o in throttling, il verdetto è INCONCLUSIVE: la causa è lo stato del sistema, non i moduli. Anche un'esecuzione interrotta da te o dalla protezione della memoria (memory guard) è INCONCLUSIVE. Errori di bit, UE, eventi critici del kernel, errori di pattern, bit fade e il gate del kit non vengono mai mitigati in questo modo.

05La RAM in un NAS, buone pratiche e particolarità hardware

Prima di incolpare i dischi o la rete per la lentezza dei trasferimenti, è utile conoscere le particolarità della memoria in un NAS. La RAM di un NAS non è la RAM di un PC da gaming. Un NAS lavora 24 ore su 24 sotto un carico costante: buffer di sistema, la cache di ZFS (ARC), macchine virtuali e container. Dalla memoria gli servono stabilità e compatibilità, non velocità di clock da record. Inoltre tollera gli errori molto meno di un PC desktop: un lungo uptime e un carico costante fanno emergere errori rari che i frequenti riavvii nasconderebbero su un PC.

Su una piattaforma sprovvista di ECC (un TS-464, ad esempio) nessuna impostazione può attivare l'ECC. Le UDIMM sono unbuffered; le RDIMM e le LRDIMM sono registered e alleggeriscono il carico sul controller, cosicché un canale può accogliere più moduli di grande capacità.

Tre moduli possono essere più lenti di due? Sì, soprattutto su piattaforma AMD. Un controller di memoria Ryzen abbassa il suo clock garantito in base al numero di moduli e di rank per canale: DDR4 3200 con un modulo per canale, 2933 con due moduli single-rank, 2666 con due moduli dual-rank. Più moduli offrono maggiore capacità ma minore larghezza di banda; quando un task è a corto di memoria, disporre di maggiore capacità è comunque preferibile all'esaurimento e all'uso dello swap.