我在做 DPDK 开发时会重点关注NUMAburstcachedescriptorPCIelockless因为默认认为只要数据路径优化好了时延自然就稳定。但我曾经遇到一个非常诡异的问题程序PPS 很稳定CPU 利用率正常没有丢包cache miss 很低pipeline 也没堵塞然而业务 RTT 却会偶发性暴涨。例如平均 RTT35usP99 RTT50us偶发尖刺3ms 5ms 甚至 10ms最奇怪的是这些 spike完全随机。而且CPU 看起来一点问题都没有。第一次遇到时我怀疑过NIC interruptburst 积压ring 抖动false sharingNUMA 远程访问最后才发现真正的问题竟然是CPU C-State 与频率动态调节。而这个问题也让我真正理解了高性能低时延系统中“省电机制”有时反而是性能杀手。一、问题现场程序是一个典型的DPDK L3 Forwardingbusy polling每核独占 queuelockless pipeline系统长期运行平均性能非常好。但监控平台总能看到偶发 latency spike二、最奇怪的地方这些 spike并没有规律。例如空闲时会出现高负载时也会出现PPS 没变化CPU usage 没异常几乎无法关联。三、第一反应是不是 GC 类问题因为“偶发卡顿”很像JVM Stop-The-Worldmalloc lock contentionpage reclaim但程序是纯 C。而且几乎不使用 malloc/free。四、进一步观察 RTT 分布后来重点看tail latency发现平均值很漂亮。但P999极其难看。五、为什么 tail latency 特别重要很多人只看average latency但真实业务里用户感知的是最慢那部分请求。尤其金融交易UPFDPI实时通信tail latency 往往比平均值更关键。六、真正关键的一步查看 CPU frequency后来执行watch -n 1 cat /proc/cpuinfo | grep MHz发现CPU 频率居然在不断变化。例如3200 MHz ↓ 1200 MHz ↓ 800 MHz这里突然意识到不对劲。七、Linux 默认会动态调频现代 CPU默认开启frequency scalingpower savingturbo boostC-State系统会根据负载动态调整频率电压核心休眠状态八、什么是 C-StateCPU 空闲时会进入节能状态。例如C0工作状态。C1轻度休眠。C3关闭部分 cache。C6深度休眠。越深省电越明显。但恢复时间越长。九、为什么 DPDK 特别怕 C-State因为DPDK 是busy polling。本质要求CPU 永远低延迟响应而 C-State会让 CPU“睡着”。十、最致命的问题wake-up latencyCPU 从C6恢复可能需要几十微秒甚至更高于是packet arrival 后CPU 不能立即响应。十一、这就是 latency spike 的根本原因平时CPU 很快。但偶尔CPU 正处于deep sleep。于是首个 packet必须等待CPU 唤醒。十二、为什么 PPS 看起来没问题因为总体吞吐没变。只是某些 packet延迟极高。所以average 很正常P99 也正常P999 极差这是典型tail latency 问题。十三、另一个隐藏问题CPU frequency scaling不仅仅是 C-State。还有动态降频。十四、为什么降频会影响 DPDK例如CPU从3.5GHz降到1.2GHz单核处理能力瞬间下降。十五、尤其在 burst 场景DPDK通常batch processing。如果CPU 频率突然降低queue 积压速度会迅速增加。导致ring accumulatelatency 增加burst 等待变长十六、perf 数据终于暴露问题后来使用turbostat观察发现CPU 大量进入C3/C6同时频率频繁波动。十七、真正修复方案后来做了几个关键调整。1. 禁用 deep C-State启动参数intel_idle.max_cstate0 processor.max_cstate12. CPU governor 改为 performance例如cpupower frequency-set -g performance3. 关闭 powersaveBIOS 中关闭Energy SavingPackage C-StateAutonomous C-State4. CPU isolation结合isolcpus nohz_full rcu_nocbs减少系统干扰。十八、优化后结果优化前指标数值Avg RTT35usP9950usP9995ms优化后指标数值Avg RTT33usP9940usP99960ustail latency 大幅改善。十九、为什么很多 benchmark 看不出问题因为很多 benchmark只跑几分钟或者只看average PPS但真实生产环境更关注长时间稳定性jittertail latencydeterministic response二十、进一步理解 DPDK 哲学DPDK 真正追求的并不是CPU 利用率最低。而是predictable latency。因此很多“省电机制”实际上会破坏确定性。二十一、为什么低时延系统几乎都关闭节能例如高频交易电信 UPF实时音视频超低时延网关通常都会固定频率禁用 deep sleepdedicated core换取稳定响应时间。二十二、一个非常经典的误区很多人看到CPU usage 不高就认为系统很健康。其实CPU 可能正在频繁 sleep/wakeup而这种 jitter比高 CPU 更危险。二十三、这次排查真正学到什么以前我以为低时延优化主要是cacheNUMAburst后来才意识到真正影响 tail latency 的有时候是CPU 电源管理。二十四、工程经验总结做低时延 DPDK一定要检查C-Stategovernorturbo behaviorfrequency scalingBIOS power profile否则你优化再多tail latency 依然可能随机暴涨。二十五、总结为什么 DPDK 程序没有丢包、吞吐正常但 RTT 偶尔暴涨很多时候不是NIC 问题burst 问题NUMA 问题而是CPU C-State 与动态调频。通过这次问题我们真正理解了核心概念C-Statefrequency scalingtail latencywake-up latencybusy pollingpredictable performance这也是高性能网络开发真正进入“系统级调优”的开始决定时延稳定性的可能已经不是代码。而是CPU 的电源管理策略。
为什么我的 DPDK 程序偶尔延迟暴涨？一次排查让我彻底理解 CPU C-State 与频率调节
我在做 DPDK 开发时会重点关注NUMAburstcachedescriptorPCIelockless因为默认认为只要数据路径优化好了时延自然就稳定。但我曾经遇到一个非常诡异的问题程序PPS 很稳定CPU 利用率正常没有丢包cache miss 很低pipeline 也没堵塞然而业务 RTT 却会偶发性暴涨。例如平均 RTT35usP99 RTT50us偶发尖刺3ms 5ms 甚至 10ms最奇怪的是这些 spike完全随机。而且CPU 看起来一点问题都没有。第一次遇到时我怀疑过NIC interruptburst 积压ring 抖动false sharingNUMA 远程访问最后才发现真正的问题竟然是CPU C-State 与频率动态调节。而这个问题也让我真正理解了高性能低时延系统中“省电机制”有时反而是性能杀手。一、问题现场程序是一个典型的DPDK L3 Forwardingbusy polling每核独占 queuelockless pipeline系统长期运行平均性能非常好。但监控平台总能看到偶发 latency spike二、最奇怪的地方这些 spike并没有规律。例如空闲时会出现高负载时也会出现PPS 没变化CPU usage 没异常几乎无法关联。三、第一反应是不是 GC 类问题因为“偶发卡顿”很像JVM Stop-The-Worldmalloc lock contentionpage reclaim但程序是纯 C。而且几乎不使用 malloc/free。四、进一步观察 RTT 分布后来重点看tail latency发现平均值很漂亮。但P999极其难看。五、为什么 tail latency 特别重要很多人只看average latency但真实业务里用户感知的是最慢那部分请求。尤其金融交易UPFDPI实时通信tail latency 往往比平均值更关键。六、真正关键的一步查看 CPU frequency后来执行watch -n 1 cat /proc/cpuinfo | grep MHz发现CPU 频率居然在不断变化。例如3200 MHz ↓ 1200 MHz ↓ 800 MHz这里突然意识到不对劲。七、Linux 默认会动态调频现代 CPU默认开启frequency scalingpower savingturbo boostC-State系统会根据负载动态调整频率电压核心休眠状态八、什么是 C-StateCPU 空闲时会进入节能状态。例如C0工作状态。C1轻度休眠。C3关闭部分 cache。C6深度休眠。越深省电越明显。但恢复时间越长。九、为什么 DPDK 特别怕 C-State因为DPDK 是busy polling。本质要求CPU 永远低延迟响应而 C-State会让 CPU“睡着”。十、最致命的问题wake-up latencyCPU 从C6恢复可能需要几十微秒甚至更高于是packet arrival 后CPU 不能立即响应。十一、这就是 latency spike 的根本原因平时CPU 很快。但偶尔CPU 正处于deep sleep。于是首个 packet必须等待CPU 唤醒。十二、为什么 PPS 看起来没问题因为总体吞吐没变。只是某些 packet延迟极高。所以average 很正常P99 也正常P999 极差这是典型tail latency 问题。十三、另一个隐藏问题CPU frequency scaling不仅仅是 C-State。还有动态降频。十四、为什么降频会影响 DPDK例如CPU从3.5GHz降到1.2GHz单核处理能力瞬间下降。十五、尤其在 burst 场景DPDK通常batch processing。如果CPU 频率突然降低queue 积压速度会迅速增加。导致ring accumulatelatency 增加burst 等待变长十六、perf 数据终于暴露问题后来使用turbostat观察发现CPU 大量进入C3/C6同时频率频繁波动。十七、真正修复方案后来做了几个关键调整。1. 禁用 deep C-State启动参数intel_idle.max_cstate0 processor.max_cstate12. CPU governor 改为 performance例如cpupower frequency-set -g performance3. 关闭 powersaveBIOS 中关闭Energy SavingPackage C-StateAutonomous C-State4. CPU isolation结合isolcpus nohz_full rcu_nocbs减少系统干扰。十八、优化后结果优化前指标数值Avg RTT35usP9950usP9995ms优化后指标数值Avg RTT33usP9940usP99960ustail latency 大幅改善。十九、为什么很多 benchmark 看不出问题因为很多 benchmark只跑几分钟或者只看average PPS但真实生产环境更关注长时间稳定性jittertail latencydeterministic response二十、进一步理解 DPDK 哲学DPDK 真正追求的并不是CPU 利用率最低。而是predictable latency。因此很多“省电机制”实际上会破坏确定性。二十一、为什么低时延系统几乎都关闭节能例如高频交易电信 UPF实时音视频超低时延网关通常都会固定频率禁用 deep sleepdedicated core换取稳定响应时间。二十二、一个非常经典的误区很多人看到CPU usage 不高就认为系统很健康。其实CPU 可能正在频繁 sleep/wakeup而这种 jitter比高 CPU 更危险。二十三、这次排查真正学到什么以前我以为低时延优化主要是cacheNUMAburst后来才意识到真正影响 tail latency 的有时候是CPU 电源管理。二十四、工程经验总结做低时延 DPDK一定要检查C-Stategovernorturbo behaviorfrequency scalingBIOS power profile否则你优化再多tail latency 依然可能随机暴涨。二十五、总结为什么 DPDK 程序没有丢包、吞吐正常但 RTT 偶尔暴涨很多时候不是NIC 问题burst 问题NUMA 问题而是CPU C-State 与动态调频。通过这次问题我们真正理解了核心概念C-Statefrequency scalingtail latencywake-up latencybusy pollingpredictable performance这也是高性能网络开发真正进入“系统级调优”的开始决定时延稳定性的可能已经不是代码。而是CPU 的电源管理策略。
