キャパシティーの限界の識別: 演習

キャパシティーの限界自体が、パフォーマンスの問題の原因になることがよくあります。パフォーマンスとキャパシティーを区別するため、パフォーマンスは「システムの処理速度」と定義し、キャパシティーは「システムまたは個別のコンポーネントの最大パフォーマンス」と定義します。

CPU の使用率が非常に低い (10% 前後) 場合は、ディスクコントローラが完全にロードされているかどうか、入出力が原因かどうかの判別を試みます。ディスクに問題があるかどうかを判別するには、次のように iostat ツールを使用します。

# iostat -xnMCz -T d 10

たとえば、インターネット上であるディレクトリが使用可能です。顧客は複数のサイトから検索を送信します。サービスレベル契約 (SLA) は、応答時間が 3 秒を超える要求の 5% に過ぎませんでした。現在、要求の 15% が 3 秒以上かかりますが、これはビジネスに不利益をもたらす状況です。システムは、900MHz の CPU を 12 基使用する 6800 です。

vmstat の出力は、次のようになります。

procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr m0 m1 m1 m1   in   sy   cs us sy id
 0 2 0 8948920 5015176 374 642 10 12 13 0 2 1  2  1  2  132 2694 1315 14  3 83
 0 19 0 4089432 188224 466 474 50 276 278 0 55 5 5 4 3 7033 6191 2198 19  4 77
 0 19 0 4089232 188304 430 529 91 211 211 0 34 8 6 5 4 6956 9611 2377 16  5 79
 0 18 0 4085680 188168 556 758 96 218 217 0 40 12 4 6 4 6979 7659 2354 18 6 77
 0 18 0 4077656 188128 520 501 75 217 216 0 46 9 3 5 2 7044 8044 2188 17  5 78

右の 3 つの列 us=user、sy=system、および id=idle を参照すると、CPU の 50% 以上がアイドル状態にあり、パフォーマンスの問題に使用可能であることがわかります。メモリーの問題を検出する方法の 1 つは、vmstat の出力の sr (スキャンレート) 列を参照することです。ページスキャナが実行を開始しているか、スキャンレートが 0 より大きくなる場合、メモリーシステムをより詳細に確認する必要があります。この表示の奇妙な点は、左側に表示されるブロックされたキュー に 18 または 19 個のプロセスが含まれるのに、実行キューにはプロセスが存在していないことです。これは、Solaris 内のどこかで、プロセスが、使用可能な CPU をすべて使用せず、ブロックされていることを示しています。

次に入出力サブシステムを確認します。Solaris 8 では、iostat コマンドにスイッチ -C を指定するとコントローラレベルで入出力が集められます。次のように iostat コマンドを実行します。

#  iostat -xnMCz -T d
                    extended device statistics              
    r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  396.4   10.7    6.6    0.1  0.0 20.3    0.0   49.9   0 199 c1
  400.2    8.8    6.7    0.0  0.0 20.2    0.0   49.4   0 199 c3
  199.3    6.0    3.3    0.0  0.0 10.1    0.0   49.4   0  99 c1t0d0
  197.1    4.7    3.3    0.0  0.0 10.2    0.0   50.4   0 100 c1t1d0
  198.2    3.7    3.4    0.0  0.0  9.4    0.0   46.3   0  99 c3t0d0
  202.0    5.1    3.3    0.0  0.0 10.8    0.0   52.4   0 100 c3t1d0

コントローラ 1 では毎秒 396 回の読み取りを実行しており、コントローラ 3 では毎秒 400 回の読み取りを実行しています。データの右側を見ると、コントローラがほとんど 200% のビジー状態であることが出力からわかります。このため、個別のディスクが毎秒ほぼ 200 回の読み取りを実行しており、出力からディスクが 100% のビジー状態であることがわかります。このことから、大まかに言えば、個別のディスクが毎秒約 150 回の入出力を実行しています。これは、大規模なディスクアレイの LUN や LDEV には当てはまりません。これまでの数値の検証に基づき、各コントローラに 2 台のディスクを追加してデータを中継するという案が得られます。

この演習では、すべての数値に注意を向け、問題の特性を正確に把握することを試みました。CPU とメモリーを追加すればパフォーマンスの問題がすべて解決されると決め込まないようにしてください。この場合は、検索プログラムがディスクドライブのキャパシティーを超過しており、それがトランザクションで応答に極端に長い時間がかかるというパフォーマンスの問題を引き起こしていました。これらの CPU はすべて、ディスクドライブからの応答を待機していました。