Write システムコールのレスポンスタイムの遅延

上述したWriteシステムコールの既存の処理では，IOスケジューラにおいてIOリクエス

ト処理の最悪値を改善する取り組み等，いくらかのレスポンスタイムに対する取り組みが行わ れている．しかしWriteシステムコールのレスポンスタイム対する考慮は十分有効ではない．

特に呼処理でのトランザクションログ記録のように，高優先で処理されるべき書込みが，他の プログラムによる非優先の書込みと同時に同一のHDDに対して行われる場合，高優先書込み のレスポンスタイムは著しく遅延する（図4.7）．

高優先で発行されるWriteシステムコールのレスポンスタイムを，計測用の擬似呼処理プ ロセスと，Linuxカーネルバージョン2.6.21を使用して計測を行った．擬似呼処理プロセス は，呼処理プロセスの書込み処理を擬似し，高優先（CPU優先度：高，ioniceによるIO優先 度：高）で同一ファイルに対して4KByte単位の同期Writeシステムコールを用いた書込みを 行う．

また同一ディスクに対する背景負荷として，rsync[60]（CPU優先度：通常，ioniceによる IO優先度：通常）によるファイルのバックアップを同時に同一のディスクに実施した．また ディスク上の全てのパーティションは同期モードでマウントしている．これら評価環境につい て表4.1に示す．

擬似呼処理プロセスは連続的にWriteシステムコールを100万回実施し，それぞれのレス ポンスタイムを計測した．この結果の概要を図4.8に示す．図4.8にはレスポンスタイムの平 均値，最大値，最小値が示されている．Y軸はログスケールでレスポンスタイムを示し，X軸 はIOスケジューラのパターンを示している．

本結果からレスポンスタイムの最大値は極めて大きく，Writeシステムコールが大きく遅延 していることがわかる．最大値はAnticipatory IOスケジューラでは約3.2秒，CFQ IOスケ ジューラでは約1.4秒，Deadline IOスケジューラでは約１秒，NOOP IOスケジューラでは 約700ミリ秒と極めて長く，タイムアウト値を大きく超過している．

本結果のように1秒を超過するレスポンスタイムが発生する場合，4.2.2で示したように，

呼処理プロセスやサーバ自身が異常な状態になっていると認識され，フェイルオーバー等の障 害処理が生じる可能性もある．このような状態で，異常状態とみなされることは致命的であ り，既製コンピュータを交換システムへ適用するにあたり課題となる．

4.4.2 レスポンスタイムを向上させる Write _{処理の提案}

Writeシステムコールのレスポンスタイム遅延を解決するために，IOスケジューラとファ

イルシステムの改善を以下に提案する．

Call control process

Hard disk drive Backup process

Logging process

High priority process

that requires response time Normal priority process

Delays due to IO congestion

IO accesses

図4.7.IOアクセス輻輳時の問題

10² 10³ 10⁴ 10⁵ 10⁶ 10⁷

Anticipatory CFQ Deadline NOOP

3x10⁵

Response time (micro-seconds)

IO scheduler pattern

Average Max Minimum

図4.8.既存IOスケジューラを使用した場合の高優先Writeシステムコールのレスポンスタ イム

表4.1.評価環境

CPU Pentium Xeon 2.8 GHz x2

Memory 2GB

HDD 160 GB SATA-1, 7200 RPM, 8 MBytesキャッシュ, 同期マウント

HDDコントローラ Intel 6300ESB SATA

カーネル 2.6.21

計測対象 擬似呼処理プロセスが発行する高優先Writeシステム コールのレスポンスタイム

背景負荷 RSYNCプログラムによりRoot パーティションをコ

ピー

計測回数 100万回計測を実施

IOスケジューラでの遅延低減

IOスケジューラのロジックを調査した結果，遅延の原因は，NOOP IOスケジューラを除 いた他のIOスケジューラで共通的に，ディスク全体でのIOスループットを向上させる事に 重点がおかれていることが原因であることがわかった．

具体的には，IOリクエストのソートがセクタ順で行なわれていることと，IOリクエストの マージ処理がIO優先度を考慮せず，かつ制限なく実施されている点にある．

このソート処理によりIOリクエストが高優先度であっても，このIOリクエストがアクセ スするセクタが現在処理されているセクタから離れた位置であれば，すぐには処理されない．

更にこのマージ処理により，１つのIOリクエストが有する実際のIO処理の書込みブロック サイズがしばしば肥大化する．HDDはIO処理の書込みブロックサイズに応じて処理時間を 要する．このため通常優先度のIOリクエストが数多くマージされれば，巨大な書込みブロッ クサイズを有するIOリクエストを生成し，このIOリクエストがデバイスドライバによって 処理される場合，その後のキューに存在するIOリクエストが刈り取られるまでの時間が，著 しく遅延する．仮に通常優先度のIOリクエストが，高優先度のIOリクエストの前に処理さ れる場合，次に処理される高優先度のIOリクエストが処理されるまでに遅延が発生し，結果

としてIO Wait状態で書込みを待ち合わせているユーザプロセスのレスポンスタイムが遅延

する（図4.9）．

この問題を解決するために，筆者はIOスケジューラにてIOリクエストをマージする回数 に制限を持たせるとともに，HDDのセクタ順ではなく，IO優先度を第一の優先順位として ソートするIOスケジューラを提案する．

提案方式は，同一のIO優先度のIOリクエストのみをマージすることを許容し，IO優先度 が高優先でない場合，マージ可能な回数を一定の値に制限する．これにより高優先でないIO リクエストが有する書込みブロックサイズを一定のサイズに制御でき，次に続く高優先のIO

Device driver IO scheduler Request

A Request

B Request C

Merge operation

IN OUT

operation Sort

IO scheduler policy

Request NEW Block layer

IO request that will be added to

IO scheduler Check the possibility

of merge to existing IO requests. If possible, the size of

request is enlarged without limitation.

sector Normal X

priority

Sector X+100 High Priority

Sector X+105 High Priority

Request D

Sector Normal X+50 priority IO scheduler queue

Check the details of new request and sort them

depend on sector number, not IO priority.

File system

図4.9.IOスケジューラの問題

リクエストがデバイスドライバに高速に刈り取られることを可能とする．

また提案方式では，IO優先度に応じて登録されたIOリクエストをソートする．更に同一 優先度をもつIOリクエストは登録順にソートする．このソートによりIOスケジューラは常 にもっとも優先度が高いIOリクエストを，登録された順にデバイスドライバに渡すことが可 能となる（図4.10）．

IOスケジューラでの遅延低減の実装

上述した提案方式のIOスケジューラを，すでにIO優先度の概念をもつCFQ IO スケ ジューラをベースに新たなIOスケジューラとして実装を行った．

マージ処理部ではcfq merge()処理を変更し，非高優先度のIOリクエストに対して設定 された一定回数を超過するマージを行わない処理とした．またキューイング部分においては，

cfq insert request()処理において，高優先のIOリクエストが登録される場合に，CFQのプ ロセス・優先度別のキューではなく，優先度・登録順にソートしてマスターキューに登録する 処理に変更した．

ファイルシステムでの遅延低減

Writeシステムコールのレスポンスタイムの遅延はIOスケジューラだけではなく，ファイ

ルシステムにおいても生じている．EXT3ファイルシステムの各処理にタイムスタンプを埋 め込み遅延の原因を調査した結果，ジャーナルの記録方法にも問題があることがわかった．具 体的にはジャーナルの記録処理を行うKjournaldカーネルスレッドの実行がユーザプロセス の実行と独立していることに原因が存在する．

Kjournaldはカーネルスレッドであり，Writeシステムコールを発行したユーザプロセスの

実行とは独立したタスクとして実行される．このためKjournaldはユーザプロセスのIO優 先度とは関係なく処理を行なう．つまりKjournaldはあらゆるジャーナルの更新を通常のIO 優先度を使用して書き込む．Kjournald により書き込まれるジャーナルの更新処理もIOリ クエストとして処理されるためIOスケジューラでデータブロックの更新に伴うIOリクエス トが優先度順にソートしたとしても，IO処理が輻輳している場合，メタデータの更新に伴う ジャーナルの更新処理が遅延する．

ファイルシステムが次の状態に遷移するためには，ジャーナルの一貫性を確保するために ジャーナル更新の完了を待つ必要がある．ファイルシステムが高優先のIO優先度のユーザ プロセスのカーネルモードで動作している場合でも，該当ファイルのジャーナルの更新は

Kjournaldによる通常のIO優先度で処理される．メタデータ更新に伴うジャーナル更新と，

データブロック更新のIO優先度が異なることで，ファイルシステムにて長時間待ち合わせが 発生し，高優先のWriteシステムコールのレスポンスタイムが遅延する（図4.11）．

この問題を解決するためにKjournaldの処理に，Writeシステムコールを発行したユーザプ ロセスのIO優先度を一定区間引き継ぐことで，kjounraldとユーザプロセスを連携させるこ とを提案する．

既存のEXT3ファイルシステムの書込み処理は，inodeを更新する前にジャーナル記録を開

ドキュメント内 向上に関する研究 (ページ 86-92)