Linux I / Oレイテンシーのデバッグ

私が管理しているいくつかのLinuxシステムでI / Oの問題が発生しています。それらは、ファイルのopen（）、unlink（）、close（）などの単純なシステムコールでプロセスが数秒間ブロックすることが多いことを示しています（これは、関連するプログラムの一部が操作にかなり低いI / Oレイテンシを必要とするため問題です）正しく）。問題のシステムがある程度のI / O負荷を経験することは事実ですが、そのような膨大な待ち時間を正当化するのに十分だとは思えません。場合によっては、呼び出しが完了するまでに15秒以上かかることがあります（ただし、多くの場合、1〜2秒または3秒ほどかかります）。

私の質問は、どうしてこれが起こるのかを知るにはどうすればよいですか？私が欲しいのは、問題のプロセスがカーネルでブロックされているものと、それらがスリープしているものがビジーである理由、それで何が起こっているのか、などを教えてくれるツールです。そのようなツールはありますか、または何が起こるかをデバッグしようとする他の方法がありますか？

もちろん、実際に何が起こっているのかについて何か手掛かりがあれば、どうすればそれを避けることができますか？

記録のために、私が使用するファイルシステムはXFSです。

そのうち、私はこの問題を自分で解決することができたので、少なくとも後世のために自分でフォローアップすることができます。

残念ながら、カーネルのアップグレードで元の問題を失いましたが、代わりに新しい問題を取得しました。パフォーマンスはさらに悪化し、追跡するのも同様に困難でした。私が見つけたテクニックは次のとおりです。

まず、blktrace/ blkparseは非常に役立つツールです。個々のI / O要求の進行状況を、要求を送信したプロセスなど、多くの役立つ詳細とともに追跡できます。出力をon tmpfsにすると、トレースのストレージの処理が自動的にトレースを開始しないようになります。

ただし、これはこれまでのところ役立ちました。そのため、より多くのデバッグ機能を備えたカーネルをコンパイルしました。特に、ftraceカーネルスペース内のパフォーマンスの低いプロセスをトレースして、それが何をしたのか、どこでブロックされたのかを確認できるので、非常に役立ちました。デバッグカーネルをコンパイルすると、作業WCHAN出力も提供さpsれます。これは、少なくとも単純なケースでは、プロセスがカーネル内で何を行っているかを確認する簡単な方法として機能します。

LatencyTopが役立つことを望んでいましたが、非常にバグが多く、残念ながら「高レベル」すぎて本当に役に立たないレイテンシーの理由しか表示されないこともわかりました。

また、次のように、非常に近い間隔でiostatコンテンツを表示するよりも便利です/sys/block/$DEVICE/stat。

while :; do cat /sys/block/sda/stat; sleep .1; done

ファイルのDocumentation/iostats.txt形式については、カーネルソースツリーを参照してくださいstat。近い間隔で表示すると、I / Oバーストなどの正確なタイミングとサイズを確認できました。

最終的に、カーネルアップグレード後に発生した問題は、Linux 3.0で導入された機能である安定したページが原因であることがわかりました。この場合、私の場合、Berkeley DBはmmapされたページをダーティにすると長時間停止します地域ファイル。この機能を修正することは可能だと思われますが、Linux 3.9でそれが引き起こす問題は修正されるかもしれませんが、Berkeley DBに修正を加えて地域ファイルを別のディレクトリに配置できるようにすることで、今までの最悪の問題を解決しました（私の場合は/dev/shm）、問題を完全に回避できるようにします。

私の経験によると、謎めいたシステムパフォーマンスの問題をトレースするためにインストールできる最も簡単で詳細な統計ツールはhttp://freecode.com/projects/sysstat akaです。サル

iostatコマンドの出力も確認してください。特に、通常のシステム負荷（1.0以下）で％iowaitが5〜10％を下回っている必要があります。

STAT列にDステータスが表示されている場合、ps出力を確認します。これは、プロセスがロックされ、IOまたはコントローラーまたはディスクのハードウェアの問題を待機していることを意味します。SMART統計とdmesgおよびsyslogを手がかりとして確認してください。

sarログを確認し、これが発生した場合はピーク時間を特定し、それらの時間をディスクを集中的に使用するcronジョブ（ネットワーク経由のバックアップなど）と一致させます

bonnie ++でディスクのパフォーマンスをベンチマークできます

この質問は数ヶ月前のものですが、私はstraceについて言及したいと思いました。このページを見つけた同様の問題を持つ人を助けるかもしれません。

試してください。

strace "application"

あなたもできる

strace -e read,write "application"

読み取り/書き込みイベントを表示するだけです。

アプリケーションは通常どおりロードされます（起動に少し時間がかかります）。問題を引き起こすために通常どおり使用できます。出力は、straceの起動に使用したシェルに表示されます。

straceの良い点は、アプリケーションがスローダウンをトリガーした時点で最新の関数/カーネル呼び出しを確認できることです。/homeアカウントがNFS上にある場合、アプリケーションは何らかの理由でNFSを介したファイルI / Oに問題があることがわかります。