CPU配置基础：--cpus参数详解、超线程影响、多核利用率与任务绑定

做Nextflow调优，CPU配置是我每次都会反复检查的一环。很多人觉得核心数给够就行，其实这里头门道不少。你想想，一个流程跑得慢，不一定是代码不行，很可能是CPU资源没用好。这一节我们就把--cpus参数、超线程、多核利用率和任务绑定这几个关键点掰开揉碎讲清楚。

1. --cpus参数：到底在控制什么？

--cpus是Nextflow里每个进程默认的CPU资源请求。它直接对应每个任务可以使用的CPU核心数。我习惯把这个值理解为“任务的并行度”——也就是说，你的计算任务内部能用多少线程同时干活。

举个例子，一个序列比对工具BWA-MEM，它内部会用多个线程来加速比对。如果--cpus 4，BWA就会启动4个线程。但如果程序本身就只有一个线程，比如一些单线程的文本处理工具，你给再多CPU也没用，反而可能因为调度开销变慢。

// 在nextflow.config中设置默认值
process {
    cpus = 4   // 每个任务默认请求4个核心
    memory = '8 GB'
}

// 也可以在进程定义中单独覆盖
process align {
    cpus = 8
    script:
    """
    bwa mem -t ${task.cpus} reference.fa sample_1.fastq sample_2.fastq > aligned.sam
    """
}

我个人习惯在进程脚本里尽量把$task.cpus暴露给程序的多线程参数，比如-t、--threads、-p等。这样配置才能生效。

2. 超线程的影响：物理核心 vs 逻辑核心

现代CPU大多支持超线程（Hyper-Threading）。一个物理核心能提供两个逻辑核心。听起来白送了一倍核心？其实不是。

我遇到过最典型的问题：在超线程服务器上，直接让Nextflow用--cpus 16，但物理核心只有8个。结果是每个任务分到的两个逻辑核心实际上共享同一个物理核心的运算单元，计算密集型任务反而互相争抢资源，速度不升反降。

怎么办？我的建议是：以物理核心数为基准。具体来说，如果你的节点有16个逻辑核心（8物理核心×2超线程），那么--cpus设为物理核心数的一半或较少，或者通过executor.queueSize控制同时运行的任务数不超过物理核心数。

场景	推荐做法	常见误区
计算密集（BWA、STAR等）	--cpus = 物理核心数 / 2，避免超线程干扰	直接设满逻辑核心
IO密集（压缩、格式转换）	可以使用逻辑核心，但给少点（如物理核心 * 0.8）	给太少导致排队时间浪费
混合工作流	每个进程单独设置cpus，参考实际性能测试	一刀切统一值

3. 多核利用率：别让核心闲置

设了正确的--cpus，不代表核心利用率就高了。我见过不少任务，用top看CPU负载只有50%，剩下的核心空转。

常见的几个坑：

• 工具不支持多线程：比如samtools view（不加-@）、seqtk等，给再多cpus也没用。
• 多线程并行时内存不足：比如STAR alignment，每个线程需要额外内存。你给了8核但只给了4GB内存，线程可能被系统限制或触发OOM。
• CPU亲和性丢失：默认情况下Nextflow不绑定任务到特定核心，任务可能在不同核心间漂移，影响缓存命中率。

怎么检查利用率？我常用的办法：在任务脚本里加一行ps aux | grep ${task.process}记录CPU使用率到日志。或者直接在作业提交后用htop观察。

// 一个简单的检查片段
process check_cpu {
    cpus = 4
    script:
    """
    # 记录任务开始时的CPU信息
    echo "Start: \$(date)" >> ${task.process}.cpu.log
    # 运行你的主程序，比如
    your_program --threads ${task.cpus}
    # 记录结束时的CPU信息
    echo "End: \$(date)" >> ${task.process}.cpu.log
    """
}

4. 任务绑定（CPU Affinity）：让核心“长在”任务上

任务绑定就是将进程固定在特定CPU核心上运行。默认Nextflow不会做这个绑定，操作系统会动态调度。这会导致两个问题：

• 任务换核→缓存失效→性能损失
• 多个任务争用同一个物理核心（尽管逻辑核心是不同任务分配的）

在Nextflow中，你可以通过executor和process.withLabels结合taskset来实现绑定。但我更推荐的做法是利用集群调度器（如SLURM、PBS）的专用参数。

下面是一个SLURM集群上绑定任务的例子：

process {
    withLabel: 'heavy_cpu' {
        cpus = 8
        clusterOptions = '--cpus-per-task=8 --cpu-bind=cores'
    }
}
// 然后在进程定义中加上 label 'heavy_cpu'

如果本地执行，可以用taskset手动绑定：

process bind_example {
    cpus = 4
    script:
    """
    taskset -c $(( ${task.index} % 8 )) your_program -t ${task.cpus}
    """
}
// 这里用任务索引模8，将不同任务映射到不同核心组

注意：任务绑定的前提是你清楚节点的拓扑结构。最好先画个图。

5. 实践总结

回头看这几个知识点，其实核心一句话：理解你的CPU拓扑，再决定怎么分核心。我个人习惯在集群配置里加一个资源查询脚本，每次新节点上线就先跑一遍。

最后给个小清单，下次配置CPU时可以对照：

• 物理核心数是多少？超线程开了吗？
• 你的主要工具支持多少线程？是否需要在脚本里显式引用$task.cpus？
• 内存与CPU是否匹配？8核要配多少内存？我一般按每个线程2-4GB估算。
• 是否要绑定任务？本地执行可以用taskset，集群环境看调度器支持。