Jak prawidłowo testować pamięć RAM w serwerach QNAP za pomocą MemHound

Testowanie pamięci RAM na działającym systemie operacyjnym (live/userspace) to wyzwanie inżynieryjne. System operacyjny, wirtualizacja oraz usługi buforowania (szczególnie ZFS ARC) stale rezerwują przestrzeń adresową i blokują do niej dostęp.

MemHound, czyli okno Memory Doctor w StorageDiag Workbench, działa według drabiny eskalacji: Quick → Standard → Deep → Hammer → Boot. Blokuje całą wolną pamięć, jaką może zająć, poza zapasem 256 MB, zapisuje w niej wzorce testowe i odczytuje je z powrotem. Każdy blok trzyma do końca przebiegu, więc jądro musi oddać każdą wolną stronę. Poniżej opisujemy, jak sprawdzić stabilność pamięci w zależności od konfiguracji i systemu plików.

1. Quickszybki przebieg, NAS dalej działa
2. Standardruchome inwersje, NAS dalej działa
3. Deepzatrzymuje usługi, zwalnia ARC
4. Hammerrow-hammer na każdym rdzeniu
5. Bootpendrive, poza systemem NAS-a

01Codzienna diagnostyka na systemach QTS (EXT4)

Przy tradycyjnym systemie plików (EXT4) QTS nie rezerwuje dużych ilości RAM-u na własne potrzeby, co ułatwia miarodajny test z poziomu działającego systemu. Awarie pamięci często objawiają się w przestrzeni użytkownika (user space), dlatego regularne, szybkie testy są skuteczne.

1. Wyłącz wszystkie niekrytyczne usługi sieciowe (Samba, NFS, AFP).
2. Zatrzymaj zasobochłonne aplikacje w App Center (stacje robocze HDMI, kontenery, maszyny wirtualne), zostawiając aktywny tylko pakiet StorageDiag. Zostaw jedną kartę przeglądarki z NAS-em.
3. Po zwolnieniu buforów i zatrzymaniu usług większość fizycznej pamięci RAM jest wolna do testu. Karta Quick dostaje znacznik DAILY, gdy wolne jest co najmniej 90% RAM-u.
4. Uruchom test Quick. Jest szybki, bo po sprawdzeniu adresów zapisuje tylko dwa wzorce i pomija opróżnianie pamięci podręcznej linia po linii, którego używa Standard. Ustaw od 1 do 3 przebiegów (pole Passes przyjmuje od 1 do 16, domyślnie 1). Jeśli w pamięci, do której test dociera, jest usterka sprzętowa, test wykaże ją niemal natychmiast.

02Diagnostyka na systemach QuTS hero (ZFS)

System plików ZFS korzysta z mechanizmu ARC (Adaptive Replacement Cache), który potrafi zająć większość dostępnego RAM-u. W takim układzie zwykły test Quick sprawdzi tylko ułamek pamięci.

1. Zamiast testu Quick wybierz test Deep.
2. Po potwierdzeniu (Stop services & test) MemHound zatrzymuje usługi NAS-a i aplikacje z App Center (panel WWW zostaje), opróżnia ZFS ARC i zwalnia bufory jądra. To oddaje do testu większość fizycznej pamięci: na TS-1288X ze 128 GB dostępna pamięć wzrosła z 96,6 GB do 116,9 GB.
3. Przebieg: najpierw test Quick sprawdza zwolnioną pamięć. Jeżeli wykryje błędy, procedura kończy się wcześniej i oszczędza czas. Jeśli błędów brak, narzędzie przechodzi do przebiegu Standard.
4. Przestój: usługi stoją, dopóki trwa ich zatrzymywanie i oba przebiegi, a przebieg Standard na dużej ilości RAM-u potrafi trwać godziny. Wracają same po zakończeniu testu, po anulowaniu, gdy proces testu padnie, a najpóźniej dwie godziny od startu. Jeśli samo zatrzymanie usług trwa dłużej niż 30 minut, test zostaje porzucony, a wszystko przywrócone.

03Testowanie absolutne (Rescue mode / offline)

Gdy log jądra (klog) wskazuje na niestabilność pamięci (spontaniczne segfaulty w kilku programach, call trace, błędy MCE lub EDAC), a testy z poziomu działającego systemu (Quick, Deep) kończą się statusem PASS, trzeba przejść do środowiska odizolowanego. Omija ono całkowicie system operacyjny NAS-a.

Opcja A: bootowalny pendrive USB (zalecane)

Pendrive zbudowano tak, żeby cały test przebiegał sam, także na urządzeniach, do których nie da się podłączyć monitora i klawiatury. Nic nie wymaga naciśnięcia klawisza. Wpis rozruchowy ustawia pendrive jako domyślny przy najbliższym restarcie, test startuje sam i raportuje postęp pod adresem samego NAS-a, a okno MemHound odczytuje go za Ciebie. Po wyniku PASS NAS sam wraca do QTS, a okno pokazuje werdykt; po usterce pamięci test wyłącza NAS (patrz niżej). Monitor i klawiatura są potrzebne tylko wtedy, gdy firmware nie przyjmie wpisu rozruchowego i pendrive trzeba uruchomić z menu startowego urządzenia.

1. W oknie MemHound kliknij Create bootable USB na pasku tytułu.
2. Włóż dowolny pendrive większy niż 192 MB do portu USB w QNAP-ie. Cała jego zawartość zostanie wymazana, a obecne formatowanie nie ma znaczenia.
3. Kliknij Update the image, gdy kreator proponuje nowszą wersję (za pierwszym razem Download the image), i postępuj zgodnie z kolejnymi krokami: Continue, wpisanie nazwy urządzenia, Erase and write, Add the boot entry.
4. Zrestartuj serwer z przygotowanego pendrive'a diagnostycznego (Restart now and test). Gdy NAS wróci, okno pokaże werdykt.

Gdy test z pendrive'a nie przebiega zgodnie z planem

• NAS nie uruchamia testu z pendrive'a. Add the boot entry dodaje jeden plik, grub/custom.cfg, na własną partycję rozruchową NAS-a. Przy starcie boot loader NAS-a (GRUB) szuka woluminu z etykietą MEMHOUND i uruchamia go, gdy go znajdzie. GRUB widzi pendrive USB tylko przez obsługę USB w firmware, więc NAS uruchamia QTS jak zwykle, gdy firmware nie przedstawi pendrive'a przy starcie (niektóre tanie lub słabej jakości pendrive'y tego nie robią), gdy start z USB jest wyłączony w ustawieniach firmware albo z powodu, którego firmware nie pokazuje. Spróbuj innego pendrive'a, portu USB z tyłu obudowy albo uruchom pendrive z menu startowego urządzenia (F11 lub klawisz tego modelu, przy włączaniu). Kreator wyświetla This firmware cannot be given a boot entry, gdy boot loader w ogóle nie czyta tego pliku, a The boot entry here is an old one, gdy wpis zapisała starsza wersja (Replace the boot entry). Pendrive, na którym test już się odbył, nie zostanie uruchomiony ponownie: żeby testować jeszcze raz, nagraj go od nowa przyciskiem Create bootable USB.
• NAS sam się wyłączył i nie wrócił. Tak właśnie kończy się test, który znalazł usterkę pamięci: celowo wyłącza NAS, żeby nic nie zapisało się na dyskach przy pamięci w takim stanie, i nie uruchamia go ponownie. Test zakończony wynikiem PASS restartuje NAS do QTS. NAS, który podczas testu z pendrive'a sam się wyłączył i pozostał wyłączony, wskazuje więc na usterkę pamięci. Szczegóły są na pendrive'ie (FAT32, etykieta MEMHOUND): przeczytaj /memhound/report-<czas>.txt i map-<czas>.json na dowolnym komputerze albo włóż pendrive do sprawnego NAS-a z StorageDiag Workbench i otwórz MemHound, który odczyta go sam.

Opcja B: Rescue mode (bez skonfigurowanych dysków) przez SSH

Jeśli wolisz pracę zdalną i znasz podstawy CLI, ten tryb pozwala na pełny test bez pendrive'a.

1. Zaloguj się do serwera QNAP przez SSH.
2. W tekstowym menu (QTS Console Management) wybierz ponowne uruchomienie serwera w trybie Rescue (bez skonfigurowanych dysków).
3. Po restarcie Qfinder wykryje serwer jako „niezainicjowany”. To prawidłowe zachowanie.
4. Z poziomu Qfindera włącz dostęp SSH. Zaloguj się jako admin (dla QTS 5.2 i nowszych domyślnym hasłem jest hasło chmurowe, dla starszych pełny adres MAC wielkimi literami bez dwukropków).
5. Pierwszym blokiem poleceń poniżej pobierz i rozpakuj MemHound, drugim uruchom testy w trybie tekstowym.

# Pobranie i rozpakowanie 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 z 2 przebiegami (zalecany punkt wyjścia)
./memhound-$arch --quick --passes 2 --ui

# Test Standard (po wyniku PASS z Quick, gdy End reason : completed)
./memhound-$arch --standard --ui

Quick najpierw sprawdza adresy, potem zapisuje szachownicę (checkerboard) i losową ruchomą inwersję (moving inversion). Standard powtarza te dwa wzorce i dokłada jedenaście kolejnych, wszystko w jednym uruchomieniu, a bez --passes robi jeden przebieg. Gdy interfejs tekstowy się zamknie, MemHound wypisuje podsumowanie po angielsku. Do testu Standard przejdź, gdy podaje ono Verdict : PASS i End reason : completed: test przerwany z braku pamięci też pokazuje PASS, ale z End reason : aborted: …. Pozostałe werdykty objaśnia punkt 04.

04Jak czytać wyniki

MemHound rozstrzyga według stałych reguł, a reguły zależą od testu. Quick, Standard, Deep i Hammer szukają usterek w pamięci, do której sięgają. Benchmark i jakość, opisany niżej, kwalifikuje cały zestaw pamięci.

Quick, Standard, Deep i Hammer

• Usterki trwałe i przejściowe. Jeden błędny odczyt nie przesądza o module. MemHound liczy go jako przejściowy (transient): mapa oznacza go jako Podejrzane, a podsumowanie w trybie tekstowym podaje PASS_WITH_TRANSIENTS. Usterka staje się trwała (HARD), gdy kolejne sprawdzenie znów zawiedzie pod tym samym adresem w pamięci samego MemHound (adres wirtualny; fizyczny jest wypisany obok jako p=), domyślnie po dwóch trafieniach (--hard-threshold 2). Każda usterka trwała daje werdykt FAIL.
• Co pokazuje okno Workbencha. Pasek stanu liczy oba rodzaje, na przykład NIEZALICZONO — usterki trwałe: 0, przejściowe: 1. Bez usterki trwałej powtórz test offline (pendrive albo tryb Rescue), zanim obwinisz moduł: przewodnik w aplikacji traktuje wynik z samymi usterkami przejściowymi jako powód do testu offline, nigdy do reklamacji (RMA). Podsumowanie w trybie tekstowym dodaje, że takie wyniki mogą wskazywać na zasilanie, temperaturę albo graniczne timingi.
• Liczniki ECC i log jądra. Liczniki ECC (EDAC) i zdarzenia z logu jądra są pokazywane obok wyniku, a podsumowanie dopisuje <== HARDWARE ECC ERRORS DURING TEST, gdy licznik wzrósł. Nie zmieniają werdyktu, więc sprawdź je osobno.
• Jak skończył się test. Podsumowanie kończy się wierszem End reason: completed, stopped by user albo aborted: …. Test zakończony inaczej niż completed nie sprawdził wszystkiego, co miał, bez względu na to, co mówi wiersz Verdict.

Warto wiedzieć: Benchmark i jakość

Przycisk Benchmark i jakość (w angielskim interfejsie Benchmark and Quality) na pasku tytułu okna MemHound mierzy ciągłą przepustowość pamięci względem wartości JEDEC zainstalowanych modułów, sprawdza rozrzut opóźnień i odrzuca każdy błąd bitu. Werdykt to PASS (albo PASS-UNQUALIFIED), MARGINAL, FAIL lub INCONCLUSIVE; słowa werdyktów zostają po angielsku. Reguły są tu ostrzejsze niż przy szukaniu usterek.

• Błędy. Jeden błąd bitu, jeden nieskorygowany błąd ECC (UE) albo jedno krytyczne zdarzenie jądra zapisane w trakcie testu daje werdykt FAIL. Zdarzenia krytyczne to machine check lub „Hardware Error”, nieskorygowany błąd pamięci, awaria pamięci (memory failure), uszkodzenie danych (data corruption) albo kernel panic. Skorygowany błąd ECC (CE) ogranicza werdykt do MARGINAL: moduł działa, ale zestawu nie da się certyfikować. Segfaulty, call trace, Oops i zabicia przez OOM są pokazywane, ale nie zmieniają werdyktu.
• Dobrany zestaw. Test kwalifikuje jeden dobrany zestaw modułów (matched kit). Nie przechodzi bramki, gdy moduły się różnią (numerem części, a gdy DMI go nie podaje, pojemnością, szybkością, typem i ECC), gdy modułów jest 3 albo nieparzysta liczba powyżej 4, albo gdy kanały A i B mają różną pojemność. Test działa dalej tylko informacyjnie, ale werdykt to FAIL, a wynik nie jest ani zapisywany, ani udostępniany. Gdy DMI nie podaje nic, bramka jest pomijana.
• Zajęty NAS. Gdy przepustowość wypada za nisko (FAIL lub MARGINAL) albo rozrzut opóźnień nie przechodzi, a NAS jest przy tym zajęty (obciążenie z ostatniej minuty powyżej 0,6 na procesor), brakuje mu pamięci (poniżej 40% wolnej na starcie) albo procesor jest dławiony (throttling), werdykt brzmi INCONCLUSIVE: winny jest stan systemu, nie moduły. Test zatrzymany przez Ciebie albo przez strażnika pamięci też kończy się INCONCLUSIVE. Błędy bitów, UE, krytyczne zdarzenia jądra, błędy wzorców, zanik bitów (bit fade) i bramka zestawu nigdy nie są w ten sposób łagodzone.

05Pamięć RAM w NAS-ie, dobre praktyki i specyfika sprzętu

Zanim obwinisz dyski albo sieć za wolne transfery, warto wiedzieć, co wyróżnia pamięć w NAS-ie. RAM w serwerze to nie RAM w komputerze do gier. NAS pracuje całą dobę pod stałym obciążeniem: bufory systemu, pamięć podręczna ZFS (ARC), maszyny wirtualne i kontenery. Od pamięci potrzebuje stabilności i zgodności, a nie rekordowego taktowania. Znosi też błędy gorzej niż komputer stacjonarny: długi czas pracy (uptime) i stałe obciążenie ujawniają rzadkie błędy, które w pececie ukryłyby częste wyłączenia.

Na platformie bez ECC (na przykład TS-464) żadne ustawienie nie włączy ECC. UDIMM to moduły bez bufora; RDIMM i LRDIMM są rejestrowane i odciążają kontroler, więc na kanał wchodzi więcej kości o dużej pojemności.

Czy trzy kości mogą być wolniejsze niż dwie? Tak, zwłaszcza na AMD. Kontroler Ryzena obniża gwarantowany zegar wraz z liczbą kości i rank na kanał: DDR4 3200 przy jednej kości na kanał, 2933 przy dwóch jednostronnych, 2666 przy dwóch dwustronnych. Więcej kości daje więcej pojemności, a mniej przepustowości; gdy zadaniu brakuje pamięci, większa pojemność i tak wygrywa z przepełnieniem i swapem.