粒度核心參數 RHEL6 與 RHEL7 對 CPU 使用率的影響

以下核心參數顯示從 R6 到 R7 的行為非常不同，我們無法弄清楚原因。任何幫助表示讚賞。

kernel.sched_min_granularity_ns kernel.sched_wakeup_granularity_ns

背景 ：

• 應用程序已在 RHEL6 上執行
• 低延遲要求。
• 具有強韌性功能的應用程序，即一旦延遲開始增加超過可接受的門檻值水平（預定義）或 CPU 使用率超過 85%，它就會停止處理新請求以避免過載。
• 我們現在正嘗試在 RHEL7 虛擬環境中進行部署，但無法像在 RHEL6 中那樣充分利用 CPU。我們幾乎無法達到 55-60% 並觀察到超出可接受門檻值的延遲峰值。

備註：

• 兩種情況下的應用程序版本相同（R6/R7）。
• 數據庫及其配置也相同
• 記憶體和 CPU 設置也相同

在 R7 中，我們使用了調整配置文件，它更改了以下影響行為的核心參數： kernel.sched_min_granularity_ns = 10000000 kernel.sched_wakeup_granularity_ns = 15000000

如果我們將這些值更改為 R6 預設值（kernel.sched_min_granularity_ns = 4000000 kernel.sched_wakeup_granularity_ns = 4000000），那麼我們確實將 cpu 使用率提高到 R6 級別（>85%）。

但是，當我們在 R6( kernel.sched_min_granularity_ns = 10000000 kernel.sched_wakeup_granularity_ns = 15000000) 中輸入相同的值時，我們看不到任何不利影響，並且 CPU 仍可像之前一樣擴展到 85-90%。**

所以上述兩個參數的非預設值是R6 & R7 表現出相反的影響。

所以我們正在尋找為什麼相同參數的行為與 RHEL6 和 RHEL7 相比有很大不同的原因？

提前致謝。

最後，我們已經能夠在 RHEL7 中實現將應用程序 CPU 使用率擴展到 80% 以上的目標。它現在非常接近應用程序在 RHEL6 上的執行方式。

以下是我們的觀察和得出結論的原因：

“vmstat”顯示“可執行”計數 > CPU 總數。但與此同時，CPU 使用率僅為 50%。另一個指標是 RHEL6 和 RHEL7 之間“上下文切換”的數量。與 RHEL6 相比，對於相同的應用程序負載，RHEL7 顯示的上下文切換要少得多。

這意味著處理並不慢，而是任務是可執行的任務，沒有分配給 CPU 核心。經過一番研究，我們找到了核心參數"kernel.sched_migration_cost_ns"，它基本上指定了可執行任務將遷移到另一個 CPU 之前的時間量。

kernel.sched_migration_cost

在遷移決策中，任務被認為是“記憶體熱”的最後一次執行後的時間量。“熱”任務不太可能被遷移，因此增加此變數會減少任務遷移。預設值為 500000 (ns)。如果存在可執行程序時 CPU 空閒時間高於預期，請嘗試減小此值。如果任務在 CPU 或節點之間跳動太頻繁，請嘗試增加它。

將值減小kernel.sched_migration_cost到大約 250 納秒（預設值：500ns）有助於我們將 CPU 使用率加速到 80%。

引用自：https://serverfault.com/questions/925815