SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

性能改善ノウハウを現場から直送! NTTデータのよりぬき『週刊まかせいのう』

Linux OSリソースのパフォーマンス分析(3) ~ ストレージとネットワークの使用状況を分析してみよう

性能改善ノウハウを現場から直送! NTTデータのよりぬき『週刊まかせいのう』 第7回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 Linuxサーバの「OSリソースのパフォーマンス分析方法」の3回目です。性能問題が発生して処理遅延やスループット低下が見られた場合や、将来的な処理量増加に備えて設備増強を検討する場合には、OSリソースの使用状況の分析が重要です。今回は、ストレージとネットワークの使用状況について、どのような観点から分析を行っていくかを解説したいと思います。

  • X ポスト
  • このエントリーをはてなブックマークに追加

前回説明したこと

  • 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リソースのパフォーマンス分析を行った後には、詳細なボトルネック調査を行うため、こうした関連する性能情報を確認しましょう。

次のページ
ストレージ使用状況の分析

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
性能改善ノウハウを現場から直送! NTTデータのよりぬき『週刊まかせいのう』連載記事一覧

もっと読む

この記事の著者

若山 勝吾(株式会社NTTデータ 「まかせいのう」チーム)(ワカヤマ ショウゴ)

NTTデータの性能プロフェッショナルチーム「まかせいのう」の古参メンバ。12年前、大規模プロジェクトの性能課題に直面し、満身創痍になる日々を経験する。からくも性能改善できたときの喜びをきっかけに、現場の教訓とともに性能の道を歩むことを決意する。今では、50を超えるプロジェクトにて、お客様とともに性能...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9274 2016/07/07 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング