MemHoundを使用してQNAPサーバーでRAMを適切にテストする方法

稼働中のオペレーティングシステム上（ユーザースペース）でRAMをテストするのは、技術的に難しい作業です。オペレーティングシステム、仮想化、キャッシュのサービス（特にZFSのARC）が、アドレス空間を常に確保し、そこへのアクセスを妨げるからです。

StorageDiag WorkbenchのMemory DoctorウィンドウであるMemHoundは、Quick → Standard → Deep → Hammer → Bootの順に、段階的に強いテストへ進みます。MemHoundは、確保できる空きRAMを256 MBの余裕を残してすべてロックし、テストパターンを書き込んでから読み戻します。各ブロックはパスが終わるまで保持するため、カーネルは空きページをすべて渡さなければなりません。以下では、構成とファイルシステムに合わせてメモリの安定性を確認する方法を説明します。

1. Quick高速スキャン、NASはサービスを継続
2. Standardムービング・インバージョン、NASはサービスを継続
3. Deepサービスを停止し、ARCを解放
4. Hammer各コアでのRow-hammer
5. BootNASシステム外のUSBドライブ

01QTS (ext4) での日常的な診断

従来型のファイルシステム (ext4) を使うQTSは、大量のRAMを自分用に確保しません。そのため、稼働中のシステムからでも信頼できるテストを行いやすくなります。メモリの障害はユーザースペースに現れることが多いので、定期的なQuickテストが効果的です。

1. 必須ではないネットワークサービス (Samba、NFS、AFP) をオフにします。
2. App Centerのリソースを大量に消費するアプリ (HDMIデスクトップステーション、コンテナ、仮想マシン) を停止し、StorageDiagのみを稼働させます。NAS上でブラウザのタブを1つだけ開いておきます。
3. キャッシュを解放してサービスを止めると、物理RAMの大部分がテストに使えるようになります。RAMの90%以上が空いている場合、QuickカードにはDAILYタグが付けられます。
4. Quickテストを実行します。Quickは、アドレスチェックの後に2つのパターンを実行し、Standardが使うラインごとのキャッシュフラッシュを省くため、高速です。1〜3パスに設定します（Passesフィールドは1〜16を受け付け、初期値は1です）。テストが届く範囲のメモリにハードウェア障害があれば、テストはほぼすぐに見つけます。

02QuTS hero (ZFS) での診断

ZFSファイルシステムはARC (Adaptive Replacement Cache) を使用しており、利用可能なRAMの大部分を占有する可能性があります。この場合、通常のQuickテストではメモリのほんの一部しかカバーできません。

1. Quickの代わりにDeepテストを選択します。
2. Stop services & test で確認すると、MemHoundはNASのサービスとApp Centerのアプリを停止し (Webパネルは動いたままです)、ZFS ARCをフラッシュし、カーネルキャッシュを破棄します。これにより、物理メモリの大部分がテスト用に解放されます：128 GBのTS-1288Xでは、利用可能なメモリが96.6 GBから116.9 GBに増加しました。
3. ワークフロー：解放されたRAMに対するQuickパスが最初に実行されます。エラーが見つかった場合、手順は早期に終了し、時間を節約します。エラーが見つからなかった場合、ツールはStandardパスに進みます。
4. ダウンタイム：サービスは、停止処理の間と両方のパスの実行中、止まったままです。大量のRAMに対するStandardパスには数時間かかる場合があります。テストが終了したとき、キャンセルしたとき、テストのプロセスが異常終了したとき、そして遅くとも開始から2時間後には、サービスは自動的に復旧します。サービスを停止するだけで30分以上かかる場合は、テストは中止され、すべてが復元されます。

03完全なテスト (Rescueモード / オフライン)

カーネルログ (klog) が不安定なメモリ (複数のプログラムでの自発的なセグメンテーション違反 (segfault)、コールトレース (call trace)、マシンチェック、EDACエラーなど) を示しているにもかかわらず、稼働中のシステムからのテスト (Quick、Deep) がPASSで終わる場合は、NASから切り離した環境でテストします。この環境は、NASのオペレーティングシステムをまったく使いません。

オプションA：起動可能なUSBドライブ (推奨)

このUSBドライブは、モニターとキーボードを接続できないユニットでも、テスト全体が自動的に実行されるように作られています。キーを押す必要はありません。ブートエントリによって、次回の再起動ではUSBドライブから起動するようになり、テストが自動的に始まります。進行状況はNAS自身のアドレスで報告され、それをMemHoundウィンドウが読み取って表示します。PASSの後は、NASが自動的にQTSで再起動し、ウィンドウに判定が表示されます。メモリ障害が見つかった場合、テストはNASの電源を切ります (以下を参照)。モニターとキーボードが必要なのは、ファームウェアにブートエントリを追加できず、ユニットのブートメニューからUSBドライブを起動しなければならない場合だけです。

1. MemHoundウィンドウのタイトルバーで、Create bootable USBをクリックします。
2. 192 MBより大きい任意のUSBドライブをQNAPのUSBポートに差し込みます。中身はすべて消去されます。今のフォーマットは問いません。
3. ウィザードに新しいビルドが表示されたら、Update the imageをクリックします（初回は、Download the imageをクリックします）。その後は、画面の指示に従います。順に、Continue、デバイス名の入力、Erase and write、Add the boot entry です。
4. 準備した診断用USBドライブからサーバーを再起動します (Restart now and test)。NASが復帰すると、ウィンドウに判定が表示されます。

起動時テストが計画通りに進まない場合

• NASがUSBドライブからテストを開始しない。Add the boot entry は、1つのファイル grub/custom.cfg をNAS自身のブートパーティションに配置します。電源を入れると、NASのブートローダー (GRUB) は MEMHOUND というラベルの付いたボリュームを探し、見つかった場合はそれを起動します。GRUBがUSBドライブを認識できるのは、ファームウェア自身のUSB機能を通してだけです。そのため、電源投入時にファームウェアがUSBドライブを認識しない場合 (安価な、または品質の低いUSBドライブの一部がそうです)、ファームウェアの設定でUSBブートがオフになっている場合、またはファームウェアが示さない理由がある場合、NASは通常どおりQTSを起動します。別のUSBドライブや背面のUSBポートを試すか、ユニットのブートメニュー (電源投入時にF11、またはこのモデルが使用するキー) からUSBドライブを起動してください。ウィザードは、ブートローダーがファイルをまったく読み取らない場合は This firmware cannot be given a boot entry と表示し、以前のバージョンが書き込んだエントリの場合は The boot entry here is an old one と表示します (Replace the boot entry で置き換えます)。一度テストを実行したUSBドライブから、テストがもう一度始まることはありません。もう一度テストするには Create bootable USB で新しく書き込んでください。
• NASの電源がオフになり、復帰しなかった。これは、テストがメモリ障害を発見したときの動作です。その状態のメモリでディスクに何も書き込まれないように、NASの電源を意図的にオフにし、再起動しません。テストにパスした場合は、NASがQTSで再起動します。したがって、起動時テスト中にNASの電源がオフになり、オフのままになった場合は、メモリ障害を示しています。詳細はUSBドライブ (FAT32、ラベル MEMHOUND) にあります。任意のコンピューターで /memhound/report-<time>.txt と map-<time>.json を読むか、StorageDiag Workbenchを実行している正常なNASにUSBドライブを接続してMemHoundを開くと、MemHoundが自動的に読み取ります。

オプションB：SSH経由のRescueモード (構成済みディスクなし)

リモートで作業したい場合で、コマンドラインの基本がわかっていれば、このモードでUSBドライブなしでフルテストを実行できます。

1. SSH経由でQNAPサーバーにログインします。
2. テキストメニュー (QTS Console Management) で、サーバーをRescueモード (構成済みディスクなし) で再起動することを選択します。
3. 再起動後、Qfinderはサーバーを「初期化されていません (uninitialized)」として検出します。これは予期された動作です。
4. QfinderからSSHを有効にします。admin としてログインします (QTS 5.2以降では、デフォルトのパスワードはクラウドパスワードです。古いバージョンでは、コロンなしの大文字のフルMACアドレスです)。
5. 以下の最初のブロックでMemHoundをダウンロードして解凍し、2番目のブロックでテキストモードでテストを開始します。

# 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-*

# 2パスのQuickテスト (推奨される開始点)
./memhound-$arch --quick --passes 2 --ui

# Standardテスト (End reason : completed でのQuick PASSの後)
./memhound-$arch --standard --ui

Quickは最初にアドレスをチェックし、次にチェッカーボードとランダムなムービング・インバージョンを書き込みます。Standardはこれら2つのパターンを繰り返し、さらに11のパターンを追加して1回の実行ですべて行います。--passesを追加しない限り、1パスを実行します。テキストUIが閉じると、MemHoundは英語でサマリーを出力します。Verdict : PASS および End reason : completed と表示されたら、Standardに進んでください。メモリの圧迫によって短縮された実行でもPASSと表示され、End reason : aborted: … となります。セクション04では、他の判定について説明します。

04結果の読み方

MemHoundは決まったルールで判定し、そのルールはテストによって異なります。Quick、Standard、Deep、Hammerは、届く範囲のメモリにある障害を探します。後述のBenchmark and Qualityは、メモリキット全体の品質を判定します。

Quick、Standard、Deep、Hammer

• ハード障害とトランジェント (一時的) 障害。1回の不良読み取りでモジュールが不良と判断されることはありません。MemHoundはそれをトランジェントとしてカウントします。マップではSuspect (疑わしい) とマークされ、テキストサマリーには PASS_WITH_TRANSIENTS と表示されます。MemHound自身のメモリの同じアドレス (仮想アドレス。物理アドレスはその横に p= として表示されます) で後のチェックがまた失敗すると、その障害はハードになります。既定では、2回検出された時点でハードです (--hard-threshold 2)。ハード障害が発生すると、判定は FAIL になります。
• Workbenchウィンドウの表示内容。ステータス行には、両方の種類がカウントされます。たとえば、FAIL — 0 hard fault(s), 1 transient のようになります。ハード障害がない場合は、モジュールが原因だと決めつける前に、オフライン (USBドライブまたはRescueモード) でテストを繰り返してください。アプリ内のガイドでは、トランジェントのみの結果はオフラインでの再テストの理由として扱われ、RMA (返品保証) の理由としては扱われません。テキストサマリーには、このような結果は電源、熱、またはぎりぎりのタイミング設定を示している可能性があることが追加されています。
• ECCカウンターとカーネルログ。ECCカウンター (EDAC) とカーネルログイベントは結果の横に表示され、カウンターが増加した場合はサマリーに <== HARDWARE ECC ERRORS DURING TEST が追加されます。これらは判定を変更しないため、ご自身で確認してください。
• 実行の終了方法。サマリーは End reason (終了理由) で終わります：completed、stopped by user、または aborted: …。判定行に何が書かれていても、completed で終了しなかった実行は、予定していた範囲をすべてはテストできていません。

知っておくべきこと：Benchmark and Quality

MemHoundのタイトルバーにある Benchmark and Quality ボタンは、持続的なメモリ帯域幅を測定して、取り付けたモジュールのJEDEC規格値と比べます。さらにレイテンシのジッターを調べ、ビットエラーが1つでもあればFAILにします。その判定は、PASS (または PASS-UNQUALIFIED)、MARGINAL、FAIL、INCONCLUSIVE のいずれかであり、そのルールは障害探索よりも厳格です。

• エラー。実行中に記録された1つのビットエラー、1つの未訂正ECCエラー (UE)、または1つのクリティカルなカーネルイベントにより、判定はFAILになります。クリティカルイベントとは、マシンチェックまたは「ハードウェアエラー」、未訂正のメモリエラー、メモリ障害、データ破損、またはカーネルパニックです。訂正済みECCエラー (CE) がある場合、判定の上限はMARGINALになります。モジュールは動作しますが、キットは認定できません。セグメンテーション違反 (segfault)、コールトレース (call trace)、Oops、OOMキルは表示されますが、判定は変更されません。
• 適合 (Matched) キット。このテストは、1組の適合キットの品質を判定します。モジュールが異なる場合 (部品番号、またはDMIが部品番号を提供しない場合はサイズ、速度、タイプ、ECCが異なる場合)、3つのモジュールまたは4を超える奇数のモジュールがある場合、あるいはチャネルAとBの容量が異なる場合、ゲート (判定基準) をパスしません。実行は情報提供のために継続されますが、判定はFAILとなり、結果は保存も共有もされません。DMIが何も報告しない場合、ゲートはスキップされます。
• ビジー状態のNAS。帯域幅が足りない (FAILまたはMARGINAL) か、レイテンシジッターが不合格になったときに、NASが忙しい (CPUあたりの1分間の負荷が0.6を超える)、メモリが足りない (開始時の空きが40%未満)、またはスロットリング中だった場合、判定はINCONCLUSIVEになります。原因はモジュールではなく、システムの状態にあるからです。ユーザーまたはメモリガードによって停止された実行もINCONCLUSIVEになります。ビットエラー、UE、クリティカルなカーネルイベント、パターンエラー、ビットフェード、キットのゲートが、このように緩和されることは決してありません。

05NASのRAM、ベストプラクティスとハードウェアごとの注意点

転送が遅いことをディスクやネットワークのせいにする前に、NASのメモリの特殊性を知っておくことが役立ちます。NASのメモリはゲーミングPCのメモリではありません。NASは、システムバッファ、ZFSキャッシュ (ARC)、仮想マシン、コンテナなど、常に負荷がかかった状態で24時間365日稼働します。メモリに求められるのは安定性と互換性であり、記録的なクロック速度ではありません。また、デスクトップPCよりもエラーに対する耐性が低くなっています。長時間の連続稼働と一定の負荷によって、PCなら頻繁な再起動で隠れてしまうような稀なエラーが表に出てきます。

ECCのないプラットフォーム (TS-464など) では、どのような設定でもECCはオンになりません。UDIMMはアンバッファードです。RDIMMとLRDIMMはレジスタードであり、コントローラーの負荷を軽減するため、1つのチャネルにより多くの大容量モジュールを載せられます。

3つのモジュールが2つよりも遅くなることはありますか？ はい、とりわけAMDでは。Ryzenメモリコントローラーは、チャネルあたりのモジュールとランクの数に応じて保証クロックを下げます。チャネルあたり1つのモジュールでDDR4 3200、2つのシングルランクで2933、2つのデュアルランクで2666になります。モジュールが多いほど容量は増えますが、帯域幅は狭くなります。それでも、作業に必要なメモリが足りないなら、帯域幅が下がっても容量を増やすほうが、メモリが尽きてスワップするよりましです。