以下内核参数在 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 相比有很大不同？
提前致谢。
答案1
最后，我们终于实现了将 RHEL7 中的应用程序 CPU 使用率提高到 80% 以上的目标。现在它非常接近应用程序在 RHEL6 上的表现。
以下是我们的观察结果以及得出结论的原因：
“vmstat” 显示“可运行”计数 > CPU 总数。但同时 CPU 使用率仅为 50%。另一个指标是 RHEL6 和 RHEL7 之间的“上下文切换”次数。与 RHEL6 相比，RHEL7 在相同应用程序负载下显示的上下文切换次数要少得多。
这意味着处理速度并不慢，而是可运行任务没有被分配到 CPU 核心。经过一番研究，我们发现内核参数"kernel.sched_migration_cost_ns"基本上指定了可运行任务迁移到另一个 CPU 之前的时间量。
内核.sched_migration_cost
在迁移决策中，任务在最后一次执行后被视为“缓存热门”的时间量。“热门”任务不太可能被迁移，因此增加此变量可减少任务迁移。默认值为 500000（ns）。如果在有可运行进程的情况下 CPU 空闲时间高于预期，请尝试降低此值。如果任务在 CPU 或节点之间频繁切换，请尝试增加此值。
将值降低kernel.sched_migration_cost到大约 250 纳秒（默认值：500 纳秒）有助于我们将 CPU 使用率加速到 80%。