web-dev-qa-db-ja.com

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

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

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

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

ちなみに、私が使用しているファイルシステムはXFSです。

linuxperformancelatencyio
13
Dolda2000

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

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

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

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

LatencyTop が役立つことも期待していましたが、かなりバグがあり、残念ながら、「高レベル」すぎて本当に役に立たないレイテンシの理由しか表示されなかったことがわかりました。

また、次のように、/sys/block/$DEVICE/statの内容を非常に近い間隔で表示する方がiostatよりも便利であることがわかりました。

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

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

結局、カーネルのアップグレード後に発生した問題は、Linux 3.0で導入された機能である 安定したページ が原因であることがわかりました。私の場合、BerkeleyDBは次の場合に長期間停止します。 mmapされた領域ファイルのページをダーティします。この機能にパッチを適用することは可能であり、Linux 3.9で問題が修正される可能性もありますが、私は今のところ最悪の問題を解決しました Berkeley DBにパッチを適用 そのリージョンファイルは別のディレクトリ（私の場合は/dev/shm）にあるため、問題を完全に回避できます。

14
Dolda2000

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

試してみてください。

strace "application"

あなたもすることができます

strace -e read,write "application"

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

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

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

3
user192032

私の経験によると、不思議なシステムパフォーマンスの問題を追跡するためにインストールできる最も単純で最も詳細な統計ツールは http://freecode.com/projects/sysstat 別名です。 sar

iostatコマンドの出力も確認する必要があります。特に、通常のシステム負荷（1.0程度未満）で％iowaitが5〜10％未満になる必要があります。

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

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

bonnie ++を使用してディスクパフォ​​ーマンスのベンチマークを行うことができます

3
Feczo