ハードウェアの現実、リソース制限、ディープパフォーマンスモニタリング

QNAP NASが遅いと感じたら、まずそのハードウェアに何ができるかを確認します。次に、NASがリソースを何に使っているかを調べ、その後でようやく、より深いところにあるキュー（I/Oで止まっているプロセスや、プロセッサを奪い合う仮想マシン）を調べます。

1. 期待このハードウェアの目的
2. ベースライン余分なものを停止し、RAMとSWAPを監視する
3. DステートI/Oでスタックしているプロセス
4. vCPUスレッド、オーバーサブスクリプション、スチール
5. グラフBlackBoxとPulseを正しく読む

01ハードウェアの期待と現実

QNAPサーバーは、価格に見合ったパーツで構築されています。QNAPは10年以上前のユニットにもファームウェアのアップデートを提供し続けていますが、だからといって古いNASやエントリーレベルのNASが、今日のあらゆるアプリを妥協なしに実行できるわけではありません。ソフトウェアは開発が進むにつれて重くなりますが、ハードウェアはそのままです。

低予算のNASは、スムーズなファイル共有のために設計されています。そのNASで仮想マシンや重いデータベースが問題なく動くと期待するのは、NASの性格を取り違えています。プロセッサとメモリが実際に何ができるかを確認し、ハードウェアの選択に責任を持ってください。NASの主な仕事はファイルを扱うことで、それ以外はすべて、残ったリソースの範囲で動く追加機能です。

02ブランチ1：サービス分離によるベースライン

NASが遅くなったとき、とりわけメモリが足りなくなってSWAP（すべての操作が大きく遅くなります）を使い始めたときは、最初の診断手順としてサービスを切り分けます。

1. QTSまたはQuTS heroにサインインします。
2. App Centerを開き、必須ではないアプリやサービスを1つずつ停止します。Workbenchがアプリを自動的に停止することはありません。
3. QTSの「リソースモニター」またはWorkbenchのPulse（Utilitiesデスク、スタートメニュー → Monitoring → Pulse。管理者のみ）でシステムを監視します。コックピットは2秒ごとに更新され、次のものを表示します：CPU使用率（論理CPUごとに1本のバー）、RAMの使用量と合計（ページキャッシュは別の帯で表示）、NASにスワップがある場合はSWAPのバー、1分間のロード、実行キュー（run queue）。CPU負荷と使用中のSWAPが下がっていくのを確認します。
4. ベースラインを見つける：NASの主要機能であるスムーズなファイル共有が完全に戻るまで、サービスの停止を続けます。

これがハードウェアのベースラインです。そこから、ハードウェアに残されたリソースの範囲内で、他のアプリを1つずつ起動します。

03ブランチ2：Dステートと隠れたボトルネック

原因が、CPUの過負荷やRAMの不足ではないこともあります。プロセスが割り込み不可能なスリープ状態（Dステート）にあると、プロセッサにまだ余裕があってもシステムが停止する可能性があります。Workbench自身の言葉を借りれば、DステートのプロセスはカーネルI/O（ディスク、ネットワークファイルシステム、ハングしたドライバー）を待ってスタックしており、そのI/Oが完了するまで強制終了させることすらできません。Dステートのプロセスが多いのは、プロセスが列を作って待っている状態で、たいていは遅いディスクI/Oの後ろに並んでいます。こうなると、デバイスは固まってしまいます。

このキューイングは、NASが仮想マシン（Virtualization Station、KVM）をホストしているときに最も悪影響を及ぼします。リソースの割り当てが適切でないと、ネットワークパケットの取りこぼしや長いI/O遅延となって現れます。

• Pulseは、1つのプロセスがDステートになるとすぐにProcesses in D-state (I/O)を表示し、2つを超えるとクリティカルとしてマークします。ProcessesタブのD + Zには、スタックしている（D）プロセスとゾンビ（Z）プロセス、およびその親プロセスのみが表示されます。
• BlackBoxは、パッケージが動き始めた時点から、20秒ごとにNASを記録します。スイッチを入れる必要はありません。記録する項目は次のとおりです：CPU使用率、iowait、コアごとのクロック、ロード、実行キュー、Blocked (D)。使用中のメモリと利用可能なメモリ、ページキャッシュ、スワップ、OOMキル。インターフェイスごとのトラフィック、ドロップ、TCP再送。ディスクごとのawait、キューの深さ、使用率。温度とファン。VMごとのCPU、vCPU、メモリ、ディスクI/O。20秒ごとのサンプルは1日間そのまま保持し、その後は、1週間分を1分単位、1か月分を5分単位、1年分を1時間単位の要約で保持します。
• 2つの異なるDカウント。BlackBoxのBlocked (D)は、ブロックされたタスクのカーネルによるカウントです。PulseはDステートで確認したプロセスをカウントします。これらが一致する必要はありません。
• PSIではなくiowait。QNAPのカーネルはPressure Stall Informationなしで構築されているため、WorkbenchはI/O遅延をiowaitとして測定します。

04CPU割り当て：pCPU、lCPU、vCPU

VMにリソースを与える前に、トポロジーを知っておく必要があります。

• pCPU (physical CPU)：NASプロセッサの実際の物理コア。
• lCPU (logical CPU)：オペレーティングシステムが認識するコア。ハイパースレッディング（Hyper-Threading）を含みます。ハイパースレッディングはパフォーマンスを2倍にするわけではありません。目安として、スループットが約30%増える程度です。
• vCPU (virtual CPU)：VMに与えられた仮想コア。

Pulseは論理CPUをカウントします：6コア12スレッドのXeon W-1250で12 coresと表示されている場合、それはスレッドのことです。

オーバーサブスクリプションの罠。32コアのプロセッサでVMに128個のvCPUを割り当てることは、それらが決して同時にビジーにならないことを前提としています。もしそうなった場合、ハイパーバイザーはvCPUを十分に速くスケジュールできず、VMはCPU時間を待って停止します。これは、ゲストの内部ではスチール時間（steal time）として表示されます。Pulseはホスト側からこれを報告します：

• vCPU over-subscription（情報）：実行中のVMが、NASが持つ論理CPUよりも多くのvCPUを持っている場合。
• VMs contending for CPU（警告）：それに加えて、ホストのビジー状態が75%を超えているか、実行キューがスレッド数よりも長い場合。このNASでの注記：Over-subscribed (17 vCPUs / 12 cores) AND the host is busy (84%, queue 11) — your VMs are likely contending for physical cores NOW. This is CPU theft, host-side.
• スチール時間 (Steal time)はゲストの内部で測定されます。NAS上では仕様によりゼロと表示されます。Workbench自身の注記には、ホストからゲストのスチールを見ることはできないと書かれています。NAS上での競合（contention）は、スレッド数に対するvCPUの数、ビジー率、実行キューで判断し、スチールはVMの内部で確認します（Linuxゲストではtopまたはvmstatのst列）。

05仮想マシンの監視

WorkbenchにはVMにインストールするエージェントはありません。Workbenchは自分が動いているNASを測定し、その中にはNASがホストする仮想マシンも含まれます。

1. PulseのVMタブを開きます。実行中のすべてのVMと、そのvCPU、CPU%、メモリ、RSS、状態、プロセスID、およびHosting 4 VM(s), 17 vCPUsというタイトル行が表示されます。
2. BlackBox（スタートメニュー → Monitoring）を開き、Heat map（ヒートマップ）に切り替えて、Virtual machinesレーンをオンにします。1日を通した各VMのCPUが、温度とディスクのawaitの横に表示されます。そのチャートには、各VMのvCPU、メモリ、ディスクI/O、および各VMの開始と停止も記録されます。
3. VMにネットワークで届くかどうかを見るには、BlackBoxのSettings → Monitored hostsにそのアドレスを追加します。すると、BlackBoxはそのラウンドトリップとパケットロスを記録します。
4. VMの内部では、ゲスト自身のツールでスチール時間（steal time）を監視します。

Virtual Machines · LOCALウィンドウ（Local NAS → Virtual Machines）には、Virtualization Stationからの各VMの構成（vCPU、トポロジ、CPUセット、CPUモデル、ディスク、ネットワークカード）が表示されます。このウィンドウを開くと、QNAP自身の診断ダンプが実行され、その結果がWorkbenchのキャッシュに保存されます。設定は何も変わりません。

06グラフの読み方：クリティカルな状態

• 高いDステートとI/O遅延。プロセスがディスクを待っています。BlackBoxのウィークリーレポートでは、これを Processes waiting on storage と呼び（95パーセンタイルのiowaitが20%以上で警告、40%以上でクリティカル）、最もビジーなディスクの名前を示します。Slow array memberは、awaitが同じアレイのほかのディスクの2倍で、しかも50ミリ秒以上（200ミリ秒でクリティカル）のディスクに印を付けます。Disk with no headroomは、2時間にわたって90%以上ビジーなディスクに印を付けます。対処法として、筆者は次のことを勧めます。VMをSSDボリュームに移動し、ディスクの健全性を確認し（パフォーマンスガイド）、他のプロセスがRAIDを飽和させていないか確認してください。
• CPUの激しいキューイング。NASのプロセッサがオーバーサブスクライブされています。Pulseは VMs contending for CPU と表示し、ウィークリーレポートの Virtual machine hogging the host は1つのコアの150%以上を使用しているVMにフラグを立てます（300%はクリティカル）。VMのvCPUを減らしてください。VMあたり1つまたは2つから始め、ゲストがそれを必要とする場合にのみ追加してください。
• サーマルスロットリング (Thermal throttling)。CPU温度が高く、その後クロックが下がり、遅延が長くなる場合は、プロセッサが過熱していることを意味します。ウィークリーレポートではこれを CPU thermal throttling と呼びます。CPUが少なくとも60%ビジーであるにもかかわらず、コアが自身の通常のクロックの60%以下で実行されている状態です。ヒートマップ上では、65℃は琥珀色、80℃は赤色です。Workbench自身のアドバイス：ヒートシンク、ファン、吸気口からほこりを取り除き、ファンが回っているか確認し、空気の流れを改善するか室温を下げてください。QTSでファンの回転数を上げるのも効果があります。

07KVMのベストプラクティス：CPUモデル

• Host / passthrough (推奨)：NASプロセッサ自体を、それが持つすべての命令セット（たとえばAVX）とともに、VMに渡します。NASが1台だけなら、最も高い性能と最も少ないオーバーヘッドが得られます。
• エミュレートされたモデル (汎用IntelまたはAMD CPU)：ホストのプロセッサを隠します。これは、物理的に異なるホスト間で稼働中のVMを移動する（ライブマイグレーション）ためのクラスターで役立ちます。単一のNAS上では、パフォーマンスを犠牲にするだけです。

Virtual Machines · LOCALウィンドウには、各VMに与えられたCPUモデル（たとえば Westmere）とそのトポロジが表示されます。Workbenchは、その選択を評価しません。

08基礎知識：リソースのオーバーコミット

NASの能力の限界近くで、VMの性能を落とさないための基礎知識です。まず数えておきたいのは、vCPUと物理コア (pCPU) の比率です：

一般的なルール。 オーバーコミットは、アクティブな監視が伴う軽く不均一な負荷の下では安全ですが、余裕のないピーク時には危険です。予備を確保しておきましょう。