Linuxにおける予測不能な大規模なI / Oパフォーマンスの低下
私は6年ほど問題なくDebianテストを使用しています（私は定期的に更新しています）が、最近、「再起動まで持続する低いI/Oパフォーマンス」として要約できるランダムな動作を示し始めました。
問題は、突然すべてのディスクの読み取りと書き込みが約5MB /秒に遅くなり、連続的な読み取りと書き込みが発生することです。レートが非常に低いため、ディスクは機械的にチャレンジされたりストレスを受けたりしませんが、再起動するまですべてが遅くなります。
コンピューターのI/Oサブシステムは、1つのOCZ Vertex 3 SSDと2つのWD Caviar Black HDDで構成されています。 SSDはOSの読み取りが多い部分を保持し、HDD上のパーティションは残りを保持します。
問題を診断するために、私は次のことを試みましたが成功しませんでした：
topは、CPUでもI/Oの使用でも暴走を示しません。hdparmは、ディスクの通常のパフォーマンス評価を返します（チェックしたのは-tですが）。smartctlは、ディスクのパフォーマンスの問題を示していません。長いテストの結果、ディスクは新品同様であることがわかりました。
システムにはZ77チップセット、16 GBのRAMおよびIntel i7 3770K CPUがあり、統計はRAM、I/O、またはCPUで飽和の兆候を示していませんが、このような問題をデバッグする経験はありません（特にカーネル空間）どんな助けでもありがたいです。
更新1：
- 予防策として、すべてのパーティションでfsckを（強制的に）実行しました。すべてFSはきれいです。
- ちなみに、1か月前にリリースされたBIOSアップグレードを見つけて適用しました。
- 50％を超えるパーティションはありません。
アップデート2：
問題は2日間浮上していません。 fsckまたはBIOSアップデートにより、システム内のいくつかの詰まりが取り除かれました。私はまだ問題を監視しており、死後の回答で質問を閉じます。
更新3：
問題が表面化し、さらに掘り下げました。答えを見てください。
私はなんとか問題を再現しましたが、それは大きなディスクキャッシュの結果でした。私のディスクキャッシュは8GBを超える可能性があり、一部のアプリケーションはそれを気に入らず、I/Oが低下しているようです。
ルートとしてecho 3 > /proc/sys/vm/drop_cachesを使用してディスクキャッシュを削除すると、問題が解決します。大容量のディスクキャッシュが原因でこのI/Oの低下が発生する理由は、現時点ではわかりません。
最終更新：詳細な調査の結果、キャッシュ内のファイル数が問題の原因であることがわかりました。多くの小さなファイルをディスクにコミットしようとしたときにディスクを破壊していました。私はこのシステムを10年間使用していたので、思い切って64ビットDebianで再インストールしました。今ではスムーズに動作しています。これはおそらく、32ビットオペレーティングシステムの制限を見つけてアップグレードした10年の副作用でした。
dmesgに不審なメッセージはありますか？
システムのボトルネックに関する洞察を得るために使用できるいくつかのツール：
- dstat
- レイテンシトップ
- sysprof