双机热备集群高并发压测单核cpu打满，需区分真实计算瓶颈与同步链路资源争用；通过top、mpstat、pidstat等命令定位线程级热点，重点排查日志串行回放、高频心跳、加密校验三类问题，并针对性启用并行回放、降低心跳频率、优化加解密及网络中断分发。
高并发压测下双机热备集群出现单核CPU打满，不是单纯“加CPU”或“重启备库”能解决的。关键在于区分是业务逻辑压测引发的真实计算瓶颈，还是热备同步链路自身在高压力下的资源争用或设计缺陷。
先确认是不是真打满了单核
很多所谓“单核100%”，其实是监控误读或采样偏差。用以下命令交叉验证：
- top -H -p $PID：进线程视图，看具体哪个线程（LWP）持续占满一个核，而非进程整体；
- mpstat -P ALL 1 5：查看每颗物理核的%usr、%sys、%iowait分布，确认是否某核长期>95%，其他核空闲；
- pidstat -t -p $PID 1 5：跟踪目标进程（如数据库主进程、同步代理、心跳服务）的线程级CPU和上下文切换（%cswch/s）；
- 注意区分steal time（虚拟化环境被宿主机抢占）或softirq（软中断堆积），这两类看似“CPU高”，实则是I/O或网络调度问题，不是计算瓶颈。
重点排查热备同步路径的三类热点
双机热备在压测中单核打满，大概率出在这三个环节：
- 日志解析与重放线程串行化：例如MySQL的SQL线程、PostgreSQL的apply进程、或自研同步中间件的单线程回放模块。压测写入并发高，但日志只能顺序apply，所有变更挤在一条线程里执行，自然打满单核；
- 心跳/状态同步抢占CPU：部分热备方案为保证强一致性，在主备间高频交换状态包（如每100ms一次），且使用同步阻塞调用+加锁更新本地状态，导致小包风暴拖垮一个核；
- 加密/压缩/校验计算密集型操作：开启SSL同步、全量日志压缩传输、或每条事务做CRC校验时，若未启用多线程或硬件加速，容易卡死单个worker线程。
针对性缓解与修复建议
不推荐直接调大线程数或关闭校验——可能牺牲一致性。优先按风险等级处理：
- 检查同步配置是否启用了并行回放（如MySQL 8.0的WRITESET、PostgreSQL的logical replication slot + parallel apply）；没启用就打开，并观察线程分布；
- 把心跳频率从100ms拉宽到500ms或1s，改用异步非阻塞方式上报状态，避免锁竞争；
- 确认同步链路是否强制加密。生产环境若网络可信，可关闭SSL；若必须加密，确保使用AES-NI指令集加速，避免纯软件加解密；
- 用perf record -g -p $PID -g sleep 30 && perf report抓取热点函数，看是否卡在memcpy、json_parse、sha256_update等位置，对应优化或绕过；
- 压测脚本本身是否只压单表/单主键？这会人为制造热点，让同步线程无法并行。应模拟真实业务分布，分散写入压力。
别忽略底层支撑组件
单核打满有时是“替别人背锅”：
- 检查网卡是否启用RPS/RFS（Receive Packet Steering），否则所有网络包都由CPU 0处理，同步流量再大也只压它；
- 确认同步进程绑定的CPU亲和性（taskset）。若误绑到同一核，多个worker也会互相挤占；
- 查看vmstat 1中的cs（context switch）值。若超10k/s，说明线程频繁切换，可能是锁粒度太粗或GC抖动（Java同步服务常见），需调优线程模型或JVM参数。
