やがて、私はこれを自分で解決することができたので、少なくとも後世のために自分でフォローアップすることができます.
残念ながら、カーネルのアップグレードで元の問題は解決しましたが、代わりに新しい問題が発生しました。パフォーマンスはさらに悪化し、追跡するのも同じくらい困難です。私が見つけたテクニックは次のとおりです:
まずはblktrace /blkparse は非常に役立つツールです。これにより、個々の I/O 要求の進行状況を、要求を送信したプロセスなど、多くの役立つ詳細とともに追跡できます。出力を 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 で導入された機能である安定したページが原因であることがわかりました。これにより、私の場合、mmap されたページをダーティにすると、Berkeley DB が長時間停止します。地域ファイル。この機能にパッチを当てることは可能であり、それが引き起こす問題は Linux 3.9 で修正される可能性がありますが、Berkeley DB にパッチを適用してリージョン ファイルを別のディレクトリに配置できるようにすることで、今のところ最悪の問題を解決しました。 (私の場合は /dev/shm )、問題を完全に回避することができます。
私の経験によると、不可解なシステム パフォーマンスの問題を追跡するためにインストールできる最も簡単で詳細な統計ツールは、別名 http://freecode.com/projects/sysstat です。サー
iostat コマンドの出力も確認してください。特に、通常のシステム負荷 (1.0 程度未満) で %iowait が 5 ～ 10% 未満である必要があります。
STAT 列に D ステータスが表示されている場合は、ps 出力を見てください。これは、これらのプロセスがロックされて IO を待機していることを意味します。コントローラーまたはディスクのハードウェアの問題である可能性が非常に高く、S.M.A.R.T 統計と dmesg および syslog をチェックして手がかりを得てください
sar ログを確認し、これが発生した場合はピーク時間を特定し、それらの時間をネットワーク経由のバックアップなどのディスク集中型の cron ジョブと一致させるようにしてください
bonnie++ でディスクのパフォーマンスをベンチマークできます
この質問は数か月前のものですが、straceについて言及したいと思います。このページを見つけた同様の問題を抱えている人の助けになるかもしれません。
strace "application"
あなたもできます
strace -e read,write "application"
読み取り/書き込みイベントのみを表示します。
アプリケーションは通常どおりロードされ (起動が少し遅くなりますが)、通常どおりに使用して問題を引き起こすことができます。 strace の起動に使用したシェルに出力が表示されます。
strace の良い点は、アプリケーションがスローダウンをトリガーした時点で、最新の関数/カーネル呼び出しを確認できることです。 /home の場合、 アカウントが NFS 上にある場合、何らかの理由でアプリケーションが NFS 経由のファイル I/O で問題を抱えています。