バックバッファの書き込み保存は最初からひどかった。バックバッファ書き込み保存を実行するときは、フォアグラウンドアクティビティに最小限の影響を与える必要があります。これはバックグラウンドアクティビティの定義です...しかし、リバーファーリングの作者は私が覚えている限りこれを行動しませんでした。たとえば、次のようにします。
$ dd if=/dev/zero of=foo bs=1M count=10k私のラップトップでChromeを実行しようとすると、デフォルトではバッファリングされた書き込み保存が完了するまで実行されません。
これでLinuxにパッチを適用し、Fedora Workstationや他の場所で利用できるようになりました。うん。
ただし、この「書き込み保存制限」（WBT）は、少なくともSATA HDDおよびSSDには基本的に影響しません。基本IOスケジューラCFQ互換性がないWBTで。 BFQ（マルチキューブロック層のCFQ以降のバージョン）も同様です。バックグラウンド書き込みストレージ自体を制限しないI / Oスケジューラに切り替える必要があります。したがって、いくつかのトレードオフを作成する必要があります：-（。
CFQは、過去にも同様に魅力的に聞こえる説明を広告に含めた可能性があります。 BFQの場合も同様です。しかし、文書によると、CFQと同様の経験的方法を使用しているようです。 IOレイテンシを測定し、レイテンシが高すぎると、バックグラウンド書き込みの保存を制限することがわかりません。
私は回転するハードドライブを搭載した2年前のラップトップを持っています。デバイスの32の深さI / Oキュー、SATA NCQを完全にサポートします。に基づいてv3パッチのカバー、私のようなシステムでは、バックグラウンド書き込みストレージが一度に多すぎるIOをコミットする可能性があるこの問題が発生すると予想されます。
大容量ファイル（20G VMファイル、8GB RAM）をコピーすると、システムが利用できなくなることがわかりました。それでもこれが私が持っている最大の問題だと思います。ext4のためです、また一部GNOMEシェルエラー。
- WBTが解決した問題を再現し、これが特定のシステムの問題であることを示す非常におおよその数値を得るためには、どのようなガイドラインに従う必要がありますか？
- この問題は非常に深刻であると思われ、少なくとも数年間は理解されてきました。一部の監視システムが潜在的な問題をどのように表示するかを知りたい場合があります。パフォーマンスの問題があり、これが考えられる原因の1つであると思われる場合は、それを診断するためにどのような測定値を見ることができますか？