私は約6年間何の問題もなくDebianをテストに使用してきましたが(ただ定期的に更新しました)、最近は「再起動するまで続く低いI / Oパフォーマンス」とまとめることができるランダムな動作が現れ始めました。
問題は、突然、すべてのディスクの読み取りと書き込みの速度が約5 MB /秒に遅くなり、これが継続的な読み取りと書き込みを引き起こすことです。速度が低すぎるため、ディスクが機械的に問題を引き起こしたりストレスを受けたりすることはありませんが、再起動するまですべてが遅くなります。
コンピュータのI / Oサブシステムは、1つのOCZ Vertex 3 SSDと2つのWD Caviar Black HDDで構成されています。 SSDはオペレーティングシステムの読み取り中心部分を保持し、HDDのパーティションは残りの部分を保持します。
問題を診断するために次のことを試しましたが、成功しませんでした。
top
CPUやI/O使用量はいずれも暴走活動を示さなかった。hdparm
ディスクの一般的なパフォーマンス評価を返します(-t
ただし確認のみしました)。smartctl
ディスクにパフォーマンスの問題が表示されませんでした。長期テストの結果、ディスクは新しいものと同じでした。
システムにはZ77チップセット、16GB RAM、およびIntel i7 3770K CPUがあり、統計にはRAM、I / O、またはCPU飽和の兆候はありませんが、これらの問題(特にカーネルスペース)をデバッグした経験はありません。どんな助けでも大変感謝します。
アップデート1:
- 予防措置として、各パーティションでfsckを(強制)実行します。すべてのFSがきれいです。
- ところで、1ヶ月前に発表されたBIOSアップグレードを見つけて適用してみました。
- パーティションが50%以上満たされていません。
アップデート2:
2日間、問題は現れませんでした。あるいは、fsck
BIOSアップデートによってシステムの一部の詰まりが解決された可能性があります。私はまだこの質問に従い、事後の答えで終わります。
アップデート3:
問題が再び発生し、もう少し掘り下げてみました。答えを参照してください。
答え1
大容量のディスクキャッシュにより、問題を再現できました。私のディスクキャッシュは8 GB以上に大きくなる可能性がありますが、一部のアプリケーションではそれが好きではなく、I / Oに問題があるようです。
ルートとしてディスクキャッシュを削除すると、echo 3 > /proc/sys/vm/drop_caches
問題が解決する可能性があります。現時点では、大容量ディスクキャッシュがI / Oパフォーマンスの低下を引き起こす理由がわかりません。
最近の更新:さらなる調査は、キャッシュ内のファイル数が問題を引き起こすことを示しました。多くの小さなファイルをディスクに再コミットしようとすると、ディスクが破損します。私はこのシステムを10年間使用してきたので、64ビットDebianを再インストールすることにしました。今仕事はよく進んでいます。これは、32ビットオペレーティングシステムの制限を発見した10年間のアップグレードの副作用かもしれません。
答え2
疑わしいニュースはありませんかdmesg
?
システムのボトルネックに関する洞察を得るために試すことができるより多くのツールがあります。
- 統計
- 遅れたトップ
- システム教授