每個設備的dirty_ratio
我最近檢查了一個幾乎完全掛起的 RHEL7.2，因為它已寫入 CIFS 文件系統。在記憶體和 cifs 的預設設置
dirty_ratio = 30（用於讀取和寫入）的情況下，這些臟頁大多是 cifs 的。在記憶體壓力下，當系統回收大部分讀記憶體時，系統頑固地嘗試刷新和回收臟（寫）記憶體。因此情況是巨大的 CPU iowait 伴隨著出色的本地磁碟 I/O 完成時間、D 中的許多程序不間斷等待和完全無響應的系統。OOM 殺手從未參與，因為系統沒有釋放可用記憶體。（我認為 CIFS 也有一個錯誤，它使刷新速度非常慢。但在這裡不要介意。）
我驚訝地發現核心處理刷新頁面到一些慢速遠端 CIFS 盒子的方式與處理超快速本地 SSD 驅動器的方式完全相同。只有一個
dirty_ratio包是不明智的，它很快就會導致 30% 的 RAM 包含來自最慢設備的髒數據。真是浪費錢。這種情況是可重現的；設置
dirty_ratio = 1完全解決了問題。但是為什麼我需要犧牲本地磁碟的記憶體僅僅因為我使用了 cifs 掛載呢？除了完全禁用某些設備的記憶體或設置
vm.dirty_ratio為非常低的值之外，還有什麼方法可以將快速設備“列入白名單”以獲得更多的寫入記憶體？或者讓慢速設備（或像 //cifs/paths 這樣的遠端“設備”）使用更少的寫入記憶體？RHEL 7.2 的核心版本稱為 3.10.0-327。（它基於 3.10.0，但包括數年的反向移植）。
每個設備的dirty_ratio
問：有沒有辦法將快速設備“列入白名單”以獲得更多寫入記憶體？或者讓慢速設備（或像 //cifs/paths 這樣的遠端“設備”）使用更少的寫入記憶體？
對此有一些設置，但它們並不像您希望的那樣有效。請參閱以下中的
bdi（“支持設備”）對象sysfs：linux-4.18/Documentation/ABI/testing/sysfs-class-bdi
min_ratio（讀寫）
在正常情況下，每個設備都會獲得總回寫記憶體的一部分，該記憶體與其目前相對於其他設備的平均寫出速度有關。
‘min_ratio’ 參數允許將回寫記憶體的最小百分比分配給特定設備。例如，這對於提供最低 QoS 很有用。
max_ratio（讀寫）
允許限制特定設備使用不超過給定百分比的回寫記憶體。這在我們希望避免一個設備佔用所有或大部分回寫記憶體的情況下很有用。例如，在 NFS 掛載容易卡住的情況下。
問題是“此設置僅在我們總共有超過 (dirty_background_ratio+dirty_ratio)/2 個臟數據後才生效。因為這是我們開始限制程序時的髒數據量。所以如果你想要的設備限制是目前唯一寫入的，限制沒有太大影響。” 進一步閱讀：
- Jan Kara (2013)的 LKML 文章。
- 這個答案末尾的“測試案例”。
- 在 v2.6.24 中送出5fce25a9df48。“如果系統上有很多空間，我們允許違反 bdi 限制。一旦我們達到總限制的一半，我們就開始強制執行 bdi 限制……”這是同一核心版本的一部分，它添加了每個設備的內部“限度”。所以“限制”一直都是這樣工作的，除了預發布版本 v2.6.24-rc1 和 -rc2。
為簡單起見，讓我們忽略您的 30% 設置並假設預設值：dirty_background_ratio=10 和dirty_ratio=20。在這種情況下，允許程序無任何延遲地臟頁，直到整個系統達到 15% 點。
問：情況是可重現的；設置
dirty_ratio = 1完全解決了問題。:-/
這聽起來類似於 LWN.net 寫的一篇文章中提到的“有害的 U 盤失速問題”。不幸的是，這篇特定的文章具有誤導性。它是如此混亂，以至於它製造了一個與報告的問題不同的問題。
一種可能性是您正在重現更具體的缺陷。如果您可以將其報告給核心開發人員，他們也許能夠對其進行分析並找到解決方案。就像解決了與透明大頁面的互動一樣。您應該使用上游核心重現該問題。或與您的付費支持聯繫人聯繫:)。
否則，有一個更新檔可以用來暴露內部
strictlimit設置。這使您可以更改max_ratio為嚴格的限制。該更新檔尚未應用於主線。如果有足夠多的人對此表示需要，則可能會應用該更新檔，或者它可能會鼓勵一些工作以消除對它的需求。我擔心的是，雖然該功能可能有用，但可能不足以證明它的包含是合理的。因此，我們最終將通過其他方式解決這些問題，然後我們將保留這個過時的遺留功能。
我在想，除非有人能證明這是好的、完整的並且足以解決“足夠大”的一組問題，否則我會通過更新檔
$$ 1 $$. 人們怎麼想？ $$ 1 $$實際上，我會把它放在 -mm 中並維護它，所以下次有人報告問題時，我可以說“嘿，試試這個”。 ——安德魯·莫頓，2013
mm-add-strictlimit-knob-v2.patch仍然坐在-mm。有幾次，人們提到了關於更好地自動調整臟記憶體的想法。不過，我還沒有找到很多工作。一個吸引人的建議是為每個設備保留 5 秒的回寫記憶體。然而，設備的速度可能會突然改變，例如取決於 IO 模式是隨機的還是順序的。分析（但沒有結論）
問：我驚訝地發現核心處理刷新頁面到一些慢速遠端 CIFS 盒的方式與處理超快速本地 SSD 驅動器的方式完全相同。
這些並不完全相同。請參閱上面 BDI 文件的引用。“每個設備都獲得了與其目前平均寫出速度相關的總回寫記憶體的一部分。”
但是，如果慢速設備是唯一被寫入的設備，這仍然可以使慢速設備填滿整個回寫記憶體，達到 15-20% 標記之間的某個位置。
如果您開始寫入的設備的最大寫回記憶體的允許份額小於其允許份額，則“臟節流”程式碼應該留出一些餘地。這將讓您使用一些剩餘的餘量，並避免不得不等待慢速設備為您騰出空間。
該文件建議添加 min_ratio 和 max_ratio 設置，以防您的設備速度變化不可預測，包括在 NFS 伺服器不可用時停止。
問題是如果臟節流無法控制慢速設備，並且它設法填充到（或接近）20% 的硬限制。
我們感興趣的髒節流程式碼在 v3.2 中進行了重新調整。有關介紹，請參閱 LWN.net 文章“ IO-lessdirty throttling ”。此外，在發布之後，Fengguang Wu 在 LinuxCon Japan 上發表了演講。他的展示幻燈片非常詳細且內容豐富。
目標是將 BDI 的所有寫回委託給專用執行緒，以實現更好的 IO 模式。但他們也不得不改用不那麼直接的節流系統。充其量，這會使程式碼更難推理。它已經過很好的測試，但我不確定它是否涵蓋了所有可能的操作機制。
事實上，查看 v4.18，對於更極端的問題版本有明確的備份程式碼：當一個 BDI完全無響應時。它試圖確保其他 BDI 仍然可以取得進展，但是……他們可以使用多少寫回記憶體會受到更多限制。即使只有一位作家，性能也可能會下降。
問：在記憶體壓力下，當系統回收了大部分讀記憶體時，系統頑固地嘗試刷新和回收臟（寫）記憶體。因此情況是巨大的 CPU iowait 伴隨著出色的本地磁碟 I/O 完成時間、D 中的許多程序不間斷等待和完全無響應的系統。OOM 殺手從未參與，因為系統沒有釋放可用記憶體。（我認為 CIFS 也有一個錯誤，它使刷新速度非常慢。但在這裡不要介意。）
您提到您的系統處於記憶體壓力之下。這是一個非常具有挑戰性的案例。當“可用”記憶體下降時，它會對回寫記憶體的大小造成壓力。“dirty_ratio”實際上是“可用”記憶體的百分比，即空閒記憶體+頁面記憶體。
這個案例是在原作中註意到的。有人試圖減輕它。它說“新的髒限制不會避免限制輕型臟器，但可能會將它們的睡眠時間限制為 200 毫秒。”
“max_ratio”的測試案例
設置一個沒有大量 RAM 的虛擬機/筆記型電腦/任何東西。執行
dd if=/dev/zero bs=1M of=~/test，並使用 觀察寫入記憶體grep -E '^(Dirty:|Writeback:)' /proc/meminfo。您應該看到dirty+writeback 在“設定點”附近穩定下來。設定點為 17.5%，介於 15% 和 20% 之間。我在 Linux v4.18 上的結果在這裡。如果您想查看確切的百分比，請注意該比率不是總 RAM 的百分比；我建議你使用dirty_balance_pages() 中的跟踪點。
max_ratio我在文件系統的 BDI 中使用不同的值執行了這個測試。正如預期的那樣，不可能將回寫記憶體限制在 15% 以下。