CPU长期100%负载场景下如何处理RabbitMQ心跳丢失导致的连接断开问题

你的猜测符合该场景下的典型故障特征：

• pika默认的心跳逻辑依赖I/O循环调度，当计算进程（包括graph-tool派生的所有并行子进程）占满所有可用CPU核心时，pika所在的线程/进程完全拿不到CPU时间片，确实会无法按时发送心跳包，超过RabbitMQ配置的心跳超时阈值后连接就会被服务端强制断开。
• 你观察到的偶现、nice值不生效的特征也能佐证这个判断：graph-tool的底层计算是基于OpenMP并行实现的，默认会占满所有CPU核心，父进程设置的nice值不会自动继承给OpenMP派生的工作线程，因此优先级调整无效。

方案1：限制graph-tool的并行计算核心数 #

graph-tool的全局并行度可以通过环境变量提前控制，预留1-2个核心给系统和心跳逻辑使用，从根源避免CPU被完全打满：
在启动Python进程前先设置环境变量：
export OMP_NUM_THREADS=N
其中N为「你的服务器CPU核心数-1或2」，也可以在Python代码最开头（import graph-tool之前）设置：

import os
os.environ["OMP_NUM_THREADS"] = str(os.cpu_count() - 2)
import graph_tool.all as gt

这个方案改动最小，不需要调整现有业务逻辑，优先推荐使用。

方案2：拆分RabbitMQ消费进程和计算进程，使用完全隔离的进程组 #

• 单独启动一个轻量消费进程，只负责从RabbitMQ拉取任务、维持心跳、持久化任务进度
• 消费进程拿到任务后，通过IPC（管道、本地队列等方式）将任务参数传递给独立的计算进程执行，计算进程的优先级和资源限制可以单独配置，完全不影响消费进程的心跳调度
• 计算完成后消费进程负责向RabbitMQ发送ACK、上报结果
  这个方案的隔离性最好，即使计算进程完全占满CPU，也不会影响心跳逻辑。

方案3：调整RabbitMQ心跳超时阈值 #

如果上述方案暂时无法落地，可以临时调大RabbitMQ服务端的心跳超时时间，或者在pika连接时手动设置更长的心跳间隔：

import pika
parameters = pika.ConnectionParameters(
    host='你的RabbitMQ地址',
    heartbeat=3600 # 单位秒，设置为大于你单次最长计算任务的耗时即可
)
connection = pika.BlockingConnection(parameters)

注意该方案属于临时兜底，会导致RabbitMQ无法及时识别真的异常断开的连接，不建议长期使用。

方案4：给计算进程绑定CPU核心 #

使用cgroup或者taskset命令给计算进程绑定固定的N-2个核心，强制预留2个核心给操作系统和消费进程使用，完全避免计算进程抢占心跳所需的CPU资源，适合生产环境长期稳定运行的场景。

内容的提问来源于stack exchange，提问作者uylmz