HAProxy 性能瓶颈排查 CPU 占用过高怎么优化配置

HAProxy CPU 占用过高通常是因为 SSL 加解密开销大或单线程处理能力达到上限，优先检查是否启用了多线程模式并调整缓冲区大小。

先说结论：大部分高 CPU 问题源于 SSL 握手频繁或配置未利用多核性能，调整线程数和缓冲区是首要手段。

先定位：确认是用户态 CPU 高还是内核态高，检查 HAProxy 版本是否支持多线程。
先做：在配置文件中启用 nbthread 参数，优化 SSL 会话缓存和日志写入方式。
再验证：观察系统负载变化及 HAProxy 统计页面中的连接处理延迟。

命令速用版

# 查看 HAProxy 进程 CPU 占用细节
 top -H -p $(pidof haproxy)

# 查看 HAProxy 版本及编译选项
 haproxy -vv

# 通过 Socket 查看运行时信息（需配置 stats socket）
 echo "show info" | socat /var/run/haproxy/admin.sock stdio

# 查看当前网络连接状态
 ss -s

为什么会这样

HAProxy 作为负载均衡器，CPU 飙升通常不是代码缺陷，而是 workload 超出了当前配置的处理能力。最常见的原因是 SSL/TLS 终止。加密和解密是数学密集型操作，如果 HAProxy 负责处理 HTTPS 握手，CPU 占用会显著高于纯 HTTP 转发。其次，早期版本或默认配置可能只运行在单线程模式下，无法利用多核 CPU 的优势，导致单个核心满载而其他核心空闲。此外，复杂的 ACL 规则（尤其是正则表达式）和同步日志写入也会阻塞处理线程，导致 CPU 等待。

分步处理

1. 确认版本与线程支持
执行haproxy -vv。如果版本低于 1.8，多线程支持可能不稳定或缺失，建议考虑升级。1.8 及以上版本支持nbthread参数。如果生产环境无法升级，只能尝试优化单线程效率或增加实例数量。

2. 启用多线程配置
在global段落中添加或修改nbthread。通常设置为 CPU 核心数，但不要超过物理核心数，以免上下文切换开销过大。在高并发场景下，建议使用cpu_map将线程绑定到特定核心，减少上下文切换，但需根据实际 NUMA 架构测试，盲目绑定可能适得其反。

global
    nbthread 4
    cpu_map nbthread 0-3
    maxconn 4096

修改后需重载配置：systemctl reload haproxy。

3. 优化 SSL 配置
如果启用了 SSL，确保开启了会话缓存以减少握手开销。在defaults或frontend中配置：

ssl-default-bind-options ssl-min-ver TLSv1.2
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

注意：配置中未包含no-tls-tickets，默认允许 TLS Tickets 复用会话以降低 CPU 负载。若安全合规要求禁用 Tickets，需接受握手 CPU 开销增加的权衡。推荐使用 AES-GCM 系列 cipher 利用 CPU 指令集加速，具体效果需压测验证，高负载建议卸载 SSL 到专用设备。

4. 调整缓冲区大小
如果处理大包或高吞吐，默认缓冲区可能不足导致频繁复制。调整tune.bufsize和tune.maxrewrite。

global
    tune.bufsize 16384
    tune.maxrewrite 1024

警告：增大tune.bufsize会显著增加内存占用。估算公式：总内存 ≈ tune.bufsize * maxconn * nbthread。例如 16KB * 4096 * 4 线程 ≈ 256MB，仅缓冲区就需预留足够内存，未明确警告可能导致 OOM。

5. 优化日志写入
同步写日志会阻塞线程。确保使用log指令指向本地 syslog 且配置为 UDP 或使用异步模式。避免在高频请求下记录每个请求的详细信息，仅记录错误或使用采样。

global
    log 127.0.0.1:514 local0 udp

怎么验证是否生效

修改配置重载后，不要立即判断效果，需观察至少一个业务周期。
1. 使用top命令观察haproxy进程是否分散到多个 CPU 核心上，而不是单核 100%。
2. 访问 HAProxy 的 stats 页面（如果已开启），查看Queue和Response Time是否下降。
3. 使用ss -s查看系统级连接统计，确认没有大量的TIME-WAIT堆积导致内核态 CPU 过高。
4. 如果 CPU 依然高但业务延迟未增加，可能是业务量自然增长，此时需评估扩容。

常见坑

1. 线程绑定不当
启用多线程后，如果操作系统调度频繁，可能产生锁竞争。CPU 绑定可减少上下文切换，但需根据实际 NUMA 架构测试，盲目绑定可能适得其反。

2. 日志磁盘 IO 瓶颈
有时 CPU 高是因为进程在等待磁盘 IO 完成日志写入。检查iostat，如果%iowait高，应改为远程 syslog 或减少日志量。

3. 正则 ACL 滥用
在acl中使用复杂的正则表达式匹配 URL 或 Header 会消耗大量 CPU。尽量使用精确匹配或前缀匹配代替正则。

4. 忽略内核参数
HAProxy 性能受限于内核网络栈。确保net.core.somaxconn和net.ipv4.ip_local_port_range已根据高并发场景调整，否则 HAProxy 可能因无法快速接受连接而空转等待。