ディスクI / Oが高いたびに、システムは通常よりはるかに遅く、応答性が低下する傾向があります。この分野でLinuxカーネルはどのように進行していますか？この問題は積極的に解決されていますか？
ベストアンサー1
ほとんど解決されたと思います。 IOの多くの状況では、パフォーマンスは2.6.36で向上し、2.6.37ではさらに向上することが期待されています。バラよりこれら プロニックス記事。
Wu FengguangとKOSAKI Motohiroは今週、これらの応答性の問題のいくつかを解決すると思うパッチを発表しました。これを「メモリ不足と大量のダーティ/書き込み保存ページが原因でシステムが応答しない」というバグと呼ばれます。 Andreas Mohrは、この問題をLKMLに報告し、カーネルvmscanに適用された2つのパッチをテストして成功したと報告したユーザーの一人でした。 Andreasの問題は、ソリッドステートドライブがUSB 1.1を介して接続されている場合、EXT4ファイルシステムを作成するとシステムが完全に応答しなくなることです（VTに切り替えるのに20秒以上かかります）。彼のシステムでは、/dev/zeroファイルから300Mを書くと、問題はさらに悪化しました。
これはショートカットリンクです抜け穴
ポロニクスでも
幸いなことに、この問題を解決しようとしている他のLinuxユーザーのテストとレポートによれば、リリースされた比較的小さなvmscanパッチが問題解決に優れた作業を実行しているようです。システムが多くのディスク活動をしている場合、ユーザーインターフェース（私たちの場合はGNOME）はまだ100％滑らかではありませんが、間違いなく以前よりもはるかに優れています。 。
そうだブロックバリアが消えているこれはパフォーマンスの向上にも役立ちます。
実際、障壁はブロックI/O性能を破壊することで悪名高いため、管理者は危険にさらされ障壁を消そうとすることが多いです。最新のハードウェアによって提供される表示キュー操作はバリアを合理的にうまく実装する必要がありますが、これらの機能を利用する試みはしばしば困難に直面します。したがって、現実の世界では、バリアジョブを実行する前に単にI / O要求キューを消去し、ハードウェアが実際にデータを永続メディアにコミットできるように、いくつかのフラッシュジョブを投げてバリアを実装します。待ち行列の消去操作はデバイスを停止し、適切なパフォーマンスに必要な並列性を終了します。当然、障壁を使用することは痛いかもしれません。
IOが再び目覚めるのは、ext4が2.6.28にリリースされたときに起こった大きなことだったと言いたいです。次のリンクはLinuxカーネルの新機能カーネルバージョンの場合は、「ブロック」と「ファイルシステム」のセクションを見てください。もちろんこれは悔しい感情かもしれませんし、FS開発を見始めたように継続的に改善されていると確信していますが、ext4のいくつかの問題によって人々がFS開発について真剣に考えるようになったようです。 IOスタックまたはext4がすべてのパフォーマンス問題を解決すると期待していましたが、解決しない場合は、他の場所で問題を見つける必要があることに気づきます。
2.6.28、 2.6.29、 2.6.30、 2.6.31、 2.6.32、 2.6.33、 2.6.34、 2.6.35、 2.6.36、 2.6.37