返回文章

Node.js CPU 飙升分析：为什么一个慢任务会让整个服务卡死

3 分钟阅读时间
Node.js性能优化事件循环CPU
Edit

问题

在生产环境中，我们经常遇到一个奇怪的现象：CPU 使用率突然飙升到 100%，但应用程序似乎"什么都没做"。 没有活跃的计算，没有繁重的处理——只有挂起的请求和冻结的事件循环。

本文分析了一个大规模运营平台中的两个真实案例：

  1. RPC 批量处理超时导致 CPU 飙升
  2. 消息队列订阅者无限流导致 CPU 异常

案例 1：RPC 批量处理 - 隐形杀手

场景

我们有一个 getBatchCompleteModuleDiff 方法，批量处理 100 个组件。每个组件触发 4-5 个 RPC 调用到后端服务。

// 优化前 - 串行处理，没有超时
async getBatchCompleteModuleDiff(componentIds: number[]) {
  const chunks = chunk(componentIds, 5)  // 100 个组件分 20 批
  let result = []
  
  for (const chunkItem of chunks) {  // 串行执行！
    const res = await Promise.all(
      chunkItem.map(id => this.getCompleteModuleDiffInfo(id))
    )
    result.push(res)
  }
  return result
}

为什么请求挂起时 CPU 会飙升

根本原因是事件循环饥饿，由以下因素组合导致：

  1. 没有超时控制 - RPC 调用可能无限期挂起
  2. Promise 累积 - 20 批 × 5 组件 × 4 RPC 调用 = 400+ 并发 Promise
  3. 事件循环阻塞 - 所有 Promise 竞争事件循环周期

以下是发生的过程：

时间线：
├── 批次 1 开始（5 组件 × 4 RPC 调用 = 20 个 Promise）
├── 批次 1 挂起（后端数据库异常，没有超时）
├── 批次 2 开始（又 20 个 Promise）
├── 批次 2 挂起
├── ...
├── 批次 20 开始（又 20 个 Promise）
├── 事件循环：400+ 个等待中的 Promise
└── CPU：100%（事件循环不断检查 Promise 状态）

CPU 没有做有用的工作——它在空转检查 Promise 解决状态。

解决方案

// 优化后 - 并行批次带超时
async getBatchCompleteModuleDiff(componentIds: number[]) {
  const componentIdsChunks = chunk(componentIds, 10)  // 更大的批次
  
  // 并行处理带超时保护
  const batchPromises = componentIdsChunks.map(async (chunk) => {
    const promises = chunk.map(id => 
      this.withTimeout(
        this.getCompleteModuleDiffInfo(id),
        5000,  // 5s 超时防止无限期挂起
        `timeout for id: ${id}`
      )
    )
    return Promise.allSettled(promises)  // 隔离失败
  })
  
  return Promise.all(batchPromises)
}

private withTimeout<T>(promise: Promise<T>, timeoutMs: number, errorMsg: string): Promise<T> {
  return new Promise((resolve, reject) => {
    const timeoutId = setTimeout(() => reject(new Error(errorMsg)), timeoutMs)
    promise
      .then(result => { clearTimeout(timeoutId); resolve(result) })
      .catch(error => { clearTimeout(timeoutId); reject(error) })
  })
}

结果

指标优化前优化后提升
响应时间60s+5-8s87% ↓
CPU 使用率90-100%40-50%50% ↓
超时控制无5s防止挂起

案例 2：消息队列订阅者 - 限流问题

场景

我们的 CheckTaskResultSubscriber 处理消息队列消息用于巡检任务结果：

@MessageSubscriber({ topic: 'TASK_RESULT' })
export class CheckTaskResultSubscriber implements IMessageSubscriber {
  @Inject()
  checkReportService: CheckReportService

  async subscribe(msg: SubscribeMessage) {
    const messageBody = JSON.parse(msg.body.toString())
    
    if (this.INSPECTOR_TAGS.includes(messageTag)) {
      await this.handleInspectorResult(messageBody)  // 数据库操作
    } else if (this.DETECTION_TAGS.includes(messageTag)) {
      await this.handleDetectionResult(messageBody)  // 数据库操作
    }
  }
}

为什么无限流会导致 CPU 飙升

消息队列消费者默认以最快速度拉取消息。当：

  1. 消息突发（例如 1000 个任务同时完成）
  2. 每条消息触发数据库操作（查询、更新）
  3. 没有并发控制 - 所有消息并发处理
  4. 连接池耗尽 - 数据库连接达到上限
  5. 事件循环饱和 - 等待 I/O 操作
消息突发（1000 条消息）
    ↓
无限流
    ↓
1000 个并发异步操作
    ↓
数据库连接池（最大 50）耗尽
    ↓
949 个操作等待连接
    ↓
事件循环：不断轮询/等待
    ↓
CPU：100%（上下文切换 + 轮询开销）

为什么 Node.js 会这样

与 Java 的线程池模型不同，Node.js 使用单线程事件循环：

  • Java：线程池自然限制并发执行（如 50 线程 = 最大 50 个并发操作）
  • Node.js：没有自然限制——可以创建无限 Promise，全部竞争事件循环

当 Promise 等待 I/O（数据库连接）时，它们不会"暂停"——而是不断检查资源是否可用，消耗 CPU 周期。

缺失的限流

查看我们的消息队列配置：

// config.prod.ts
config.messageQueue = {
  enableDefaultProducer: true,
  pub: { /* ... */ },
  // 没有 sub 配置！消费者使用默认设置
}

订阅者在以下层面都没有并发控制：

  • 消息队列层面（没有预取限制）
  • 应用层面（没有信号量/瓶颈）

推荐解决方案

1. 在订阅者中添加并发控制

import { Semaphore } from 'async-mutex'

@MessageSubscriber({ topic: 'TASK_RESULT' })
export class CheckTaskResultSubscriber implements IMessageSubscriber {
  // 限制并发处理为 10
  private semaphore = new Semaphore(10)

  async subscribe(msg: SubscribeMessage) {
    await this.semaphore.runExclusive(async () => {
      // 处理消息
      await this.processMessage(msg)
    })
  }
}

2. 使用 p-limit 简化控制

import pLimit from 'p-limit'

const limit = pLimit(5)  // 最大 5 个并发

async subscribe(msg: SubscribeMessage) {
  await limit(() => this.processMessage(msg))
}

3. 配置消息队列消费者线程池

config.messageQueue = {
  enableDefaultProducer: true,
  pub: { /* ... */ },
  sub: {
    taskResult: {
      consumerGroup: 'CID_TASK_RESULT',
      topics: ['TASK_RESULT'],
      consumeThreadCount: 5,  // 限制消费者线程
      maxReconsumeTimes: 3
    }
  }
}

要点总结

为什么请求挂起会导致 CPU 飙升

因素解释
Promise 开销每个等待中的 Promise 都消耗事件循环周期
没有超时挂起的请求无限期累积
资源竞争数据库连接、内存、文件描述符耗尽
轮询成本事件循环不断检查 I/O 就绪状态
上下文切换V8 引擎在 Promise 状态转换中的开销

预防策略

  1. 始终设置超时 - 外部调用（RPC、HTTP、数据库）
  2. 实现限流 - 消息消费者需要限流
  3. 使用 Promise.allSettled - 而非 Promise.all 来隔离失败
  4. 监控事件循环延迟 - 作为早期预警指标
  5. 添加熔断器 - 防止级联失败

监控清单

// 事件循环延迟监控
const eventLoopLag = require('event-loop-lag')
setInterval(() => {
  const lag = eventLoopLag()
  if (lag > 100) {  // > 100ms 表示有问题
    console.warn(`Event loop lag: ${lag}ms`)
  }
}, 1000)

结论

Node.js 在请求挂起时的 CPU 飙升是反直觉但可以解释的：

  • 不是挂起本身消耗 CPU
  • 是累积的等待 Promise竞争事件循环的关注
  • 超时和并发控制是必要的防线

关键洞察：Node.js 需要显式的资源管理，而其他语言通过线程池隐式处理。没有它，“什么都不做"可能消耗一切。

本文基于一个大规模运营平台的真实生产事故。优化将 P99 延迟从 60 秒降低到 8 秒，并将 CPU 使用率稳定在 40-50%。

References