前回説明したこと
- OSリソースを大まかに分けると、CPU、メモリ、ストレージ、ネットワークの4つ
- CPUとメモリの使用状況について、どのような観点から分析を行っていくか
注意
- 本稿の動作確認環境は、Red Hat Enterprise Linux 6.4（以下、RHEL6.4）＋sysstat9.0.4です。
- sysstatパッケージがインストール済みであることが前提です。
- 本稿に基づく運用については、お客様自身の責任と判断によって行ってください。
ストレージとネットワークの性能面における特徴
最初に、ストレージとネットワークの性能面に関する特徴を把握しておきましょう。
ご存じのように、ストレージやネットワークの処理時間は、CPUやメモリとは比較にならないほど低速です。このため、ハードウェア側とOS側の双方で入出力を効率化する工夫がされています。例えば、バッファリングやキャッシュ、処理の並列化などが挙げられます。これらのうち処理の並列化の例としては、ストレージではRAID（複数のディスクでI/O処理を分散）やコマンドキューイング（1つのディスクで同時に複数I/Oを処理）、ネットワークではBonding（複数のNIC〔ネットワークインタフェースカード〕で通信処理を分散）やマルチキューNIC（1つのNICで通信処理を複数のCPUへ分散）などが知られています。
特にストレージはシステムを構成するハードウェア部品の中で最も低速であるため、性能問題の温床（ホットスポット）になりがちです。このような背景から、近年ではストレージにSSD製品を採用したり、あるいはオンメモリ化やキャッシュサーバを利用するなど、極力高速なデバイスを用いることでストレージのボトルネック解消を行うことがトレンドになってきています。ネットワークについては、ギガビット以上の通信帯域が主流となったことで、ハードウェア的には高速な環境が実現されつつあります。
とはいえ、I/O処理（ストレージ関連）あるいは通信処理（ネットワーク関連）で性能問題を引き起こしているシステムは後を絶ちません。その中で、直接の原因がハードウェアのスペック不足というケースは少ないです。むしろ、設定や処理方式（アプリケーション実装など）に起因しているケースのほうが多い傾向が見られます。
また、ストレージとネットワークの性能に関しては、パフォーマンス分析が難しいという側面があります。両者の性能には、OS内部だけでなく外部の機器も含めて複数のレイヤーが関連しており、動作を細部まで把握することが容易ではないからです。基本的な性能が、ハードウェア部品のスペックで決まるCPUやメモリとはこの点で対照的です。
では、ストレージとネットワークのパフォーマンス分析は、どのように行えばよいのか。これから順を追って解説します。
パフォーマンス分析の考え方
ストレージとネットワークは、OSからはデバイスドライバを経由して「入出力」が行われるという特徴があります。そこで、ストレージやネットワークそのものをサブシステム（サービス）とみなします。これにより、パフォーマンス分析の考え方がシンプルになります。
例えば、ブラウザでWebサービスにアクセスすると、Webサービスに対して要求（入力）が行われ、その要求が処理された後に応答（出力）がブラウザに返ってきます。このとき、Webサービスの性能として着目するのは「スループット（どの程度の要求数をさばけるか）」と、その「応答時間」です。ストレージやネットワークについても、これと同様な見方ができます。
つまり、CPUでは「使用率」、メモリでは「使用量」がパフォーマンス分析の指標になるのに対し、ストレージとネットワークではスループットおよび応答時間がパフォーマンス分析の指標となります。
なお、ストレージには格納容量という意味で「使用量」の指標もありますが、通常は性能に直接関係しないため[1]、本稿では解説を割愛します。
注
[1]: ストレージの空き容量が極端に不足している場合には注意が必要です。システムが不安定になる危険性があるほか、領域割り当てのためにライト（書き込み）性能が低下することがあります。
スループットと応答時間について
ストレージとネットワークにおいて、スループットは、処理した数（I/O数や通信パケット数）と転送量（バイト単位）に分類されます。また応答時間は、処理中の時間と処理待ちの時間（待ち行列時間、キュー待ち時間ともいう）に分類されます。
特に、ストレージとネットワークのパフォーマンス分析で大事なのは、待ち行列という考え方です。
I/O処理（ストレージ関連）あるいは通信処理（ネットワーク関連）を行う際、OS内部だけでなく外部の機器も含め、同時に処理できる量には限りがあります。それを超える処理要求は処理待ちになってしまいます。ストレージやネットワークのリソースを使い切ってしまえば（ハードウェアの性能限界に達すれば）、当然ながらスループットはそれ以上出ません。処理待ちの時間が増加する一方です。イメージとしては、混雑したコンビニでレジ待ちのお客さんの行列ができている状況です。
一方で、リソースがさほど使われていないにもかかわらず、スループットが出ないケースがあります。それには2つの典型的なパターンがあります。どちらも処理方式（アプリケーション実装など）に密接に関係しています。
- 1）ロックによる排他制御のため、同時に1つしか処理できない（同時実行数が多い場合、この可能性が高い）
- 2）処理オーバーヘッドがネックとなり、なかなか処理が進まない（同時実行数が少ない場合、この可能性が高い）
1）の代表例は「データベースの行ロックによる競合待ち」です。同時に複数の処理が当該ロックを取り合おうとした場合、早い者勝ちになります。後続の処理はロックが解放されるまで待たされます。
2）は、送信データを細切れにネットワーク転送する処理方式や、1つのSQL文で一括処理できるのにループ内処理でSQL文を大量発行している処理方式などが該当します。ちょうど、コンビニで複数の商品を買おうとするお客さんが、商品1つ1つをレジに並び直して精算しているような状況です。なんと非効率な……、と思われるかもしれませんが、そのような処理方式となっているシステムは案外多いです。リソースはスカスカで（空いていて）、ロックによる排他制御も特にないはずなのに、なぜ性能が出ないのだろう……という場合、このパターンであると考えられます。
まとめると、ストレージとネットワークのパフォーマンス分析を行う際のポイントは次の2つです。
- スループットがハードウェアの性能限界に達しているか（リソースをどの程度使っているか）
- 応答時間が遅延しているか（処理中と処理待ちのどちらに時間がかかっているか）
具体的には、「OSリソースの使用状況を確認し、ボトルネックの疑いがあるか（あるいはどの程度の負荷まで耐えられそうか）」を判断することになります。
そのボトルネックの所在は、OS内部ということもあれば、外部の機器という可能性もあります。このため、OS上で計測できるリソース使用状況だけでなく、関連する性能情報を確認しなければならないことがあります。例えば、ストレージには外部ストレージ側の性能情報があり、ネットワークにはネットワーク機器や通信先マシン側の性能情報があります。また、データベース製品やアプリケーションサーバ製品の中には、I/O量やI/O待ち時間、ネットワーク転送量や通信待ち時間を計測できるものもあります。
OSリソースのパフォーマンス分析を行った後には、詳細なボトルネック調査を行うため、こうした関連する性能情報を確認しましょう。
