Disk I/Oを理解する - どういった点に注意すべきか?

Derek Haynes  on February 10, 2011

今回の記事の作成には、ブルーボックスグループのシニアシステムアドミニストレーターのクリスチャン・パレディスが参加してくれた。ブルーボックスグループは、強力なアプリケーションの最高のパフォーマンスを維持するためのオペレーションコンサルティングを行なっている、ウェブホストで、特にRuby on Railsに注力している。クリスチャンはブルーグループの内部インフラを最善の状態にキープし、Tier3のテクニカルサポートも行っている。更に、アドミニストレーターの連盟であるLOPSAにてボランティアとしても活躍している。

01.photo.png

フロッピーを知っている世代ならば、当時はデイスクの読み込みや出力（I/O：インプット/アウトプット）にかなりの時間待たされて、やきもきした経験があるだろう。例えば、1970年代に人気を博したオレゴントレールというゲームを覚えているだろうか。このゲームで次のシーンを読み込んでいる間、ドライブがきしむような独特の音をよく聞いたのではないだろうか。この音は、アイドル状態のCPUにデータが読み込まれるのをひたすら待っている状態のものである。フロッピーのドライブがもっと高速だったら、今頃とっくにコロンビア川の急流を下っているのにと苛立ったこともあったかもしれない。

ディスクがデスクトップ上のものでない場合は、さらに、読み込み時間が掛かる原因を解明するのは難しいだろう。ウェブアプリのディスクI/O処理に関する４つの質問を見てみよう。

ナメクジ　VS  戦闘機

02.io_compare.png

ディスクI/O処理とは、ハードディスクのインプットおよびアウトプットオペレーションの総称である。ディスク上のファイルからデータを読み取る際、ファイルを読み込む間プロセッサが待機している必要がある。(書き込む場合も同様だ。)

ディスクを使用する際に大きな弊害となるのは、処理時間だ。処理時間は、コンピュータがプロセッサからのデータリクエストを処理し、ストレージデバイスから必要なデータを引き出すのに要する時間のことを言う。ハードディスクは機械的であるため、どうしてもディスクが必要な部分を回転させるのを待つ必要があるのである。

一般的に、ディスクの処理時間は13ms(ミリ秒) だが、それは品質やハードドライブの回転スピードに大きく左右される。一方、RAMの処理時間は約83ナノセカンドだ。 この差はどの程度のものなのか。

例えて言うならば、RAMが最高時速が1190マイルになるアメリカ戦闘機（F-18 Hornet）だとすると、ディスクの処理スピードは、最高時速0.007マイルのナメクジ(banana slug)だ。このため、メモリーの中にデータを格納することがパフォーマンスに大きく影響してくる。RAMとハードディスクの処理時間の差は非常に大きい。

ディスクI/Oの処理時間が長くなる原因を診断

ディスクI/Oの処理時間（I/O wait %）を測定することで、根本原因が何かを診断することが可能だ。I/O wait %は、プロセッサがディスク作業の間、待機している時間がどの程度あるかをパーセンテージで表す。例えば、MySQLから10,000のレコードを引き出し、引き出したレコードで何らかのオペレーションを行うのに1秒かかるとする。

レコードが出力されている間、ディスクは常にアクセスされている状態となる。この間、プロセッサはアイドル状態となり、ディスクの作動の間、待機しているということになる。先ほど挙げた例の場合、ディスクI/Oの処理には700ms要しているので、I/O wait パーセンテージは70%である。I/O wait %は、あらゆる設定のLinux環境のtopコマンドから確認可能だ。

I/O wait %の値が、CPUコア数分の１より大きい場合、ディスクのサブシステムの処理に、CPUがかなりの時間待機していることになる。上記の場合、8つのコア（via cat /proc/cpuinfo）でI/O wait %は12.1%となる。1/8 cores = 0.125にとても近い値である。
この状態が続けば、アプリケーションの動作スピードが低下する可能性も出てくる。

I/O処理時間の速さを左右するものとは

データベース、メールサーバー、ファイルサーバなど、様々なディスクアクセスにおいて、１秒間でインプットおよびアウトプットのオペレーションが何回可能なのか(IOPS)を注視する必要がある。

IOPSを左右する主な４つの要因を挙げてみる。

IOPSの限界値を算出

IOPSの限界値に対して、現状どの程度のレベルにあるのかを検証するより正確な方法は、理論上のIOPSを計算し、実際のIOPSと比較することだ。２つの数値が近いならば、I/O処理に関する何らかの支障が発生しているかもしれない。

理論上のIOPSは下記の計算で算出可能。

I/O Operations Per-Sec =

number of disks * Average I/O Operations on 1 disk per-sec

% of read workload + (Raid Factor * % of write workload)

ほぼ全ての代入数はハードウェアのスペックで決定するが、１つだけ例外がある。

読み込み・書き込みのワークロード（workload）は、アプリケーションで決まる要素だ。この数値は、sarのようなツールを使用して検出できる。また、スカウトのDevice Input/Output plugin を使用すると、読み込みと書き込みのスループットが検出できる。

理論上のIOPSが算出できたら、sarにより表示されるtpsコラムと比較してほしい。tpsコラムには、1秒毎のデバイスへのトランスファ数が表示される。この数値が、実際のIOPSだ。もしtpsの数値が理論上の数値に近いならば、処理能力の限界に近いということだ。

03.Scout _ Scout RRD-1.png

IOPSの算出方法の詳細はこちらから

I/O処理時間改善における最善のソリューションとは

ナメクジがThe 4 Hour Body,に挙げられているような非常に効果的なトレーニングを行っても、F-18ホーメットのスピードに追いつくことはないだろう。

同様に、ディスクハードウェアを調整し、パフォーマンスを向上させることは可能だが、この調整は複雑なプロセスで、RAMのスピードに達することはないだろう。

処理時間の改善に対して、ハードウェアを調整するというのは効率の良いソリューションではない。

ハードウェアを変換するには、大変な量の検証やデータ移行、アプリケーション開発者とシステムアドミンのやりとりが発生する。

ブルーボックスグループで　I/O処理時間遅延の原因に対してトラブルシューティングを行う際、まずI/O処理を最も行なっているサービスを調整し、RAMにより多くのデータを格納している。例えば、RAMを最大化し(最大64gb程度)、MySQLのクエリーキャッシュをできるだけ多くメモリーに格納するようデータベースサーバーのコンフィグレーションを行うことが一般的だ。

覚えておくべき３点

サーバーの追加か、コードの最適化（高速化）か？

　サーバーの追加は応急処置としては有効である。しかし、Scout APMは、あなたが頭を抱えているシステム内の非効率なコードやコストが多く掛かっているコードを見つけ出す。Scout APMは、自動でN+1のコードやメモリーボード、その他関連する課題を特定し、デバックに掛かる時間を削減し、本来実施したいコードのプログラムに時間を割くことが可能になる。

無料トライアル

参考情報ページ