高いディスクI / O中のシステムパフォーマンス/応答性の向上に関する進捗状況を教えてください。

高いディスクI / Oがある場合は常に、システムは通常よりもはるかに遅くなり、応答が遅くなる傾向があります。これに関するLinuxカーネルの進捗状況を教えてください。この問題は積極的に取り組んでいますか？

大部分は解決されたと思います。重いIOでのパフォーマンスは2.6.36で向上しましたが、2.6.37でさらに向上すると期待しています。これらの phoronix記事を参照してください。

Wu FengguangとKOSAKI Motohiroは今週、これらの応答性の問題のいくつかに対処すると信じているパッチを公開しました。これらの問題については、「システムはメモリ不足とダーティ/ライトバックページの多い状態で応答しなくなる」というバグです。この問題をLKMLに報告し、カーネルのvmscanに対して適用される2つのパッチをテストしたユーザーの1人であるAndreas Mohrが成功を報告しました。Andreasの問題は、ソリッドステートドライブがUSB 1.1経由で接続されているときにEXT4ファイルシステムを作成すると、システムが完全に応答しなくなる（そしてVTへの切り替えに20秒以上かかる）ことでした。彼のシステムで/ dev / zeroファイルから300Mを書き込んだ場合、問題はさらに悪化しました。

ここにバグへの直接リンクがあります

また、Phoronixから

幸い、私たちのテストと、この問題が修正されたのを期待している他のLinuxユーザーのレポートから、公開された比較的小さなvmscanパッチは、この問題により適切に対処しているようです。システムが圧倒的な量のディスクアクティビティを維持している場合、ユーザーインターフェイス（この場合はGNOME）は100％流動的ではありませんが、以前よりはるかに優れており、Linux 2.6.35カーネルで今でも見られるものです。

Phoronix 2.6.36リリースのお知らせもあります

思わブロックバリアが離れて行くとそのはず、ヘルプのパフォーマンス。

実際には、バリアはブロックI / Oパフォーマンスを無効にすることに対して不愉快な評判があり、管理者はしばしばそれらをオフにしてリスクを取るように誘惑されます。最新のハードウェアによって提供されるタグ付きキュー操作は、バリアを適切に実装する必要がありますが、これらの機能を利用しようとする試みは、一般的に困難に直面しています。したがって、現実の世界では、バリアは、バリア操作を発行する前にI / Oリクエストキューをドレインするだけで実装され、ハードウェアが実際にデータを永続的なメディアにコミットするためにいくつかのフラッシュ操作がスローされます。キュードレイン操作はデバイスを停止させ、完全なパフォーマンスに必要な並列処理を強制終了します。バリアの使用に苦痛が伴うことは当然のことです。

公平なI / Oスケジューリングに関するこのLWN記事もあります。

2.6.28でext4がリリースされた時期について、IOが大いに再覚醒したと思います。次のリンクはLinuxカーネルの初心者向けカーネルリリースへのリンクです。ブロックセクションとファイルシステムセクションを確認してください。もちろん、これは不公平な感情かもしれませんし、FS開発の監視を始めたばかりの頃は、それが全体的に改善されていることは確かですが、ext4の問題のいくつかは、人々が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