【NetApp】sysstat コマンドでの性能分析とボトルネック特定手順

はじめに

ストレージ管理者にとって、ユーザーからの「ファイルサーバーが遅い」「システムのレスポンスが悪い」という問い合わせは、最も緊張する瞬間の一つではないでしょうか。 そんな時、NetApp（Data ONTAP）の現状を把握するために、真っ先に実行すべきコマンドが sysstat です。

このコマンドは、ストレージの「聴診器」のような役割を果たします。 実行するだけで、「今どれくらいのアクセス（IOPS）があるのか」「CPU やディスクは限界を迎えていないか」 といった重要情報を、1秒単位のリアルタイムで可視化することができます。

本記事では、出力項目が多く難解に見えがちな sysstat の読み解き方を、ボトルネック特定の観点から解説します。

sysstat コマンドとは？

sysstat は、NetApp の OS である Data ONTAP に標準実装されている、最も基本的かつ強力な性能統計ツールです。 外部ツールをインストールする必要なく、SSH やコンソールからコマンドを叩くだけで、ストレージコントローラー全体の稼働状況 をリアルタイムに表示します。

何が見えるのか？

このコマンドでは、ストレージの処理フローにおける以下の 3 つの要素を一画面で確認できます。

プロトコル毎の統計（入り口）

• NFS, CIFS (SMB), iSCSI, FCP などのプロトコルごとに、毎秒どれくらいのアクセス（IOPS）が来ているか。

スループット（交通量）

• ネットワーク（Network）やディスク（Disk）、テープ装置に対して、毎秒何キロバイト（kB/s）のデータ転送が発生しているか。

ハードウェアリソース（エンジンの状態）

• CPU: コントローラーの処理能力に余裕はあるか。
• Disk: ディスクへの読み書きが追いついているか（Disk Util）
• NVRAM (CP): キャッシュメモリからディスクへのデータ書き込み処理（CP）が正常か。

実行方法とオプション (-x, -m)

トラブルシューティングの現場では、単に sysstat と打つことはほとんどありません。 より詳細な情報を取得するために、以下のオプションを組み合わせるのが「鉄板」です。

【基本】詳細モードでの実行 (sysstat -x)

最も頻繁に使用されるのが -x オプションです。

sysstat -x 1

-x （Extended）

• 拡張表示モードです。デフォルト表示に加えて、CP（Consistency Point）の詳細 や ディスクの統計情報 など、ボトルネック特定に不可欠な情報が表示されます。

1 （Interval）

• 更新間隔（秒）です。「1」を指定することで、1秒ごとのリアルタイムな変動を確認できます。
• ※ 終了するには Ctrl + C を押します。

なぜ sysstat -x 1 が推奨なのか？
デフォルトの表示では情報が丸められすぎてしまい、「何が原因で遅いのか」を深掘りできないためです。

マルチプロセッサの確認 (sysstat -m)

CPU 負荷が高い疑いがある場合に使用します。

sysstat -m 1

-m （Multi-processor）

• NetApp のコントローラーはマルチコア CPU を搭載しています。
• 通常の sysstat は全コアの「平均値」しか出しませんが、このオプションを使うことで 「特定のコアだけが 100% に張り付いていないか」 を確認できます。
• 特定の処理（ネットワーク割り込みなど）が 1 つのコアに集中してボトルネックになるケースを発見できます。

出力結果の見方（重要項目）

コマンドを実行すると大量の数字が流れますが、システムの健康状態を判断するために見るべきは、以下の 4 つの指標です。これらが「システムのバイタルサイン（生命兆候）」となります。

ボトルネックの真犯人「CP（Consistency Point）」を読み解く

sysstat -x の出力にある 「CP ty（CP Type）」 という列。ここには、NetApp の心臓部であるデータ書き込み処理の状態が表示されます。

CP とは？（ダムの放流に例えると…）

NetApp は高速化のために、サーバーからの書き込みデータを一旦 NVRAM（不揮発性メモリ） という「一時保管場所」に受け取り、そこで「書き込み完了」の返事を返します。 その後、NVRAM に溜まったデータを、まとめて裏で ディスク（HDD/SSD） に書き込みます。この 「NVRAM からディスクへデータをフラッシュする処理」 を CP（Consistency Point）と呼びます。

これを 「ダムの放流」 に例えると分かりやすいです。
・雨（サーバーからの書き込み）: どんどん降ってきます。
・ダム（NVRAM）: 一旦水を貯めます。容量には限界があります。
・放流（CP）: 通常は「10秒に1回」定期的にゲートを開けて、下流（ディスク）へ水を流します。

危険なサインの見分け方

通常、CP ty の列には 「T（Timer）」 が表示されます。これは「タイマー通り、平和に放流しました」という意味です。 しかし、システムに負荷がかかると、危険なサイン（アルファベット）が表示されます。特に注意すべきは以下の 2 つです。

F（NVLog Full）

• NVRAM がパンクした状態: 定期放流（10秒）を待たずに満杯になったため、緊急で書き込み処理が走ります。
• 原因: NVRAM の容量不足、または、突発的な大量データの書き込み。

一時的な書き込み停止リスク

B（Back-to-Back）

• ディスク書き込みが間に合ってない状態: 前の放流が終わってないのに、次の放流指示が来ている（連続発生）
• 原因：Disk I/O ボトルネック（ディスクの本数が足りない、または HDD の性能限界）

システム全体のレスポンスが大幅悪化

イメージでは、
・F（NVLog Full）は「ダムが決壊寸前！」
・B（Back-to-Back）は「下流が詰まって放流できない！」
です。

対処の方向性

F が頻発する場合

• 書き込みのタイミングを分散させる。
• 上位モデルのコントローラー（NVRAM 容量が大きいもの）への更改を検討する。

B が頻発する場合

• ディスクの増設: 本数を増やして負荷を分散させる（スピンドル数を稼ぐ）
• メディアの変更: HDD から SSD (All Flash) へ変更する。
• 負荷分散: データ（Volume）を別の Aggregate（ディスク集合体）へ移動する。

よくあるボトルネックの兆候パターン

sysstat の数値は、単体ではなく組み合わせて見ることで、真の原因が見えてきます。 ここでは、現場で頻繁に遭遇する 3 つの典型的なパターンを紹介します。

パターン A: CPU ボトルネック

コントローラーの処理能力が限界を迎えているケースです。

兆候

• CPU: 平均して 90% 〜 100% に張り付いている。
• Disk Util: 低い（ディスクにはまだ余裕がある）
• CP: 特に異常なフラグ（F や B）は出ていない、または F がたまに出る。

何が起きている？

• ストレージエンジン（WAFL）の処理計算が追いついていません。重複排除や圧縮などの高負荷処理、あるいは単純にさばける IOPS の限界を超えています。

対策

• CPU 負荷の高い処理をオフピーク時間帯に移動する。
• コントローラーのアップグレード（上位モデルへの移行）を検討する。

パターン B: ディスクボトルネック（最も多い！）

物理ディスクの読み書き性能が限界を迎えているケースです。

兆候

• Disk Util: 70% 〜 80% 以上 が断続的に続いている。
• CP ty: 「B」（Back-to-Back）や 「b」 が頻発している。
• Cache Hit: 低下している場合が多い。

何が起きている？

• NVRAM からディスクへのデータ掃き出しが間に合っておらず、常にディスクが回転し続けている状態です。

対策

• ディスクの増設: 本数を増やして負荷を分散させる（スピンドル数を稼ぐ）
• Flash Cache / SSD 導入: I/O 処理能力を根本的に底上げする。

パターン C: ヘッドルーム不足（特定プロトコルの遅延）

全体のリソースには余裕があるように見えるのに、レスポンスが悪いケースです。

兆候

• CPU / Disk Util: 共に低い（余裕がある）
• 現象: FCP や iSCSI 接続のサーバーだけタイムアウトや遅延が発生する。
• sysstat -m: 特定の CPU コアだけ 100% になっていることがある。

何が起きている？

• ヘッドルーム（余力）の不足、またはネットワーク経路の問題です。平均値としては余裕があっても、特定の処理キュー（Queue）が詰まっていたり、スイッチ側でパケットロスが発生している可能性があります。

対策

• sysstat -m で特定コアの偏りを確認する。
• ネットワーク統計コマンド（ifstat 等）でインターフェースのエラーを確認する。

まとめ

本記事では、NetApp のパフォーマンス分析の基本である sysstat コマンドについて解説しました。

異常値を検知した後は、より詳細な統計情報を取得できる高度なコマンド statit（または qos statistics）を使用して、高負荷の原因となっている「犯人（ボリュームやホスト）」を特定します。

以上、最後までお読みいただきありがとうございました。