内存配置基础：--memory参数详解、单位换算、进程内与全局内存设置

内存配置，是Nextflow调优里最容易被忽视的环节。很多人上来就把内存设得很大，觉得越大越快。其实不是这么回事。我见过太多的作业因为内存配置不合理，要么被集群kill掉，要么资源浪费严重，排队排到天荒地老。

这一讲，咱们就把内存配置这件事彻底说清楚。--memory 参数到底怎么用？单位怎么换算？进程内和全局设置有什么区别？搞懂了这些，你的流水线才算真正上了道。

一、--memory 参数：它到底在控制什么？

--memory 不是 Nextflow 自己的参数，而是给执行器（比如 SLURM、SGE、AWS Batch）的一个资源请求。说白了，你告诉集群：“我这个任务需要这么大内存，请帮我分配。”

在进程定义里，你通常这么写：

process ALIGNMENT {
    memory '8 GB'
    script:
    """
    bwa mem -t $task.cpus reference.fa read1.fq read2.fq > aligned.sam
    """
}

看到没？这里的 memory '8 GB'，就是向调度器申请 8GB 内存。执行器拿到这个请求后，会把它转换成对应的参数。比如 SLURM 下，Nextflow 会自动生成 #SBATCH --mem=8GB。AWS Batch 下则会设置容器内存限制。

关键点：--memory 是进程级别的最大内存限制，不是 Nextflow 本身占用的内存。很多人搞混了这一点，以为是给 Nextflow 管理进程用的。

二、单位换算：别在单位上翻车

单位换算听起来简单，但我在项目中遇到过好几次因为单位搞错导致的线上事故。有一次同事写了个 memory '1 gb'，结果调度器完全不认，作业直接失败。后来查了半天，才发现大小写都有讲究。

Nextflow 支持的单位列表如下：

单位 含义 字节数 备注
B 字节 1 几乎不用，太小
KB 千字节 1,000 十进制
K 千字节 1,024 二进制
MB 兆字节 1,000,000 十进制
M 兆字节 1,048,576 二进制
GB 吉字节 1,000,000,000 十进制
G 吉字节 1,073,741,824 二进制
TB 太字节 1,000,000,000,000 十进制
T 太字节 1,099,511,627,776 二进制

避坑指南：我曾经在一个生产流水线里看到 memory '16 gb'（小写 gb），结果 SLURM 直接把任务拒绝了。Nextflow 对单位大小写很敏感，推荐统一使用大写的 GB、MB、G、M。大写不会出错。

嗯，这里要特别说一句：G vs GB 差别有多大？在 1GB 时差别只有 7.3%，但当你要 128G 时，实际比 128GB 多了将近 1GB。对于基因组数据跑 BWA 或 STAR 这种大任务，1GB 的偏差可能就是任务失败的原因。

三、进程内内存设置：精准控制每个步骤

每个进程可以独立设置内存，这是最细粒度的控制方式。

基本语法：

process ALIGNMENT {
    memory '16 GB'
    
    script:
    """
    your_command
    """
}

process SORT_BAM {
    memory '8 GB'
    
    script:
    """
    your_command
    """
}

但是——真正写代码的时候，很少有人硬编码内存值。你想想看，如果是 RNA-seq 流程，有的样本 100M reads，有的才 10M，内存需求天差地别。所以更常见的写法是用动态表达式：

process ALIGNMENT {
    memory { 4.GB * task.attempt }
    
    script:
    """
    bwa mem -t $task.cpus reference.fa read1.fq read2.fq > aligned.sam
    """
}

这个 task.attempt 是个好东西。第一次失败后，Nextflow 会自动重试，内存会翻倍。对于内存边界不清晰的任务，这是一种自动试探的机制。

我的习惯：对于不确定内存的任务，我会设置初始值偏小，然后开启自动重试。比如 memory { 8.GB * task.attempt }，maxRetries 设为 3。这样既能避免浪费，又能自动适应。

四、全局内存设置：一劳永逸还是陷阱？

全局设置是在 nextflow.config 里配的，对所有进程生效。如果你所有进程的内存需求都差不多，用全局确实省事。

全局配置示例：

process {
    memory = '8 GB'
}

这会让每个进程默认申请 8GB。但是——你想想看，如果你的流程里既有比对（要 16GB），又有质控（只要 2GB），这个设置就会出大问题。比对任务拿不到足够内存会崩溃，质控任务则白白浪费 6GB。

更合理的做法是分层覆盖：

process {
    // 全局默认值
    memory = '8 GB'
    
    withName: ALIGNMENT {
        memory = '16 GB'
    }
    
    withName: FASTQC {
        memory = '2 GB'
    }
    
    withName: '*_FOO_*' {
        memory = '12 GB'
    }
}

优先级规则：withName > withLabel > 进程内定义 > 全局默认。Nextflow 有一套完整的覆盖机制，理解这个优先级才能避免“为什么我的配置不生效”的问题。

五、全局 vs 进程内：选择策略

我个人习惯遵循这么几条原则：

  • 全局默认值：设为流程中最常见的需求，比如 4GB
  • 进程内覆盖：只有个别特殊进程才单独写 memory，不要全流程硬编码
  • withLabel：适合按功能分组，比如所有比对相关的进程用同一个 label
  • 动态表达式：对于内存需求随数据量变化的任务，一定要用表达式

下面这张图能帮你理清决策逻辑：

内存配置决策流程 任务资源需求 所有进程内存需求相近？ 是 全局配置默认 process.memory = '8 GB' 否 差异是否可分类？ 可分类 withName / withLabel 分组设置 逐组明确配置 不可分类 动态内存表达式 memory { 4.GB * task.attempt } 最终内存分配 💡 优先级：withName > withLabel > 进程内 > 全局默认

六、实战中的内存配置方案

下面是我常用的几个模板，你可以直接拿来用：

场景1：标准 RNA-seq 流程

process {
    // 全局默认 4GB
    memory = '4 GB'
    
    // 比对工具单独分配
    withName: STAR_ALIGN {
        memory = { 8.GB * task.attempt }
        errorStrategy = { task.exitStatus in 137..140 ? 'retry' : 'terminate' }
        maxRetries = 3
    }
    
    // 质控工具给少一点
    withName: FASTQC {
        memory = '2 GB'
    }
}

场景2：大规模 WGS 变异检测

process {
    // GATK 工具对内存敏感
    withName: HaplotypeCaller {
        memory = { 16.GB * task.attempt }
    }
    
    withName: BaseRecalibrator {
        memory = '8 GB'
    }
    
    // 其他工具默认
    memory = '4 GB'
}

小技巧：如果任务因为内存不足被 kill（通常 exit code 137），可以在 errorStrategy 里设置重试并加倍内存。我怕的是你们不设这个，看着任务一遍遍失败还不知道怎么回事。

七、常见错误与排查

  1. 单位写错：'16 gb' 会出错，'16 GB' 才是正确写法
  2. 全局覆盖了进程配置：检查是否有全局 process.memory 覆盖了 withName 的配置
  3. 超出集群上限：确认集群单个节点的最大内存，别写个 512GB 却跑到只有 128GB 的节点上
  4. 忘记写 memory：默认值可能是 1GB，对于大任务根本不够用

排查时可以用 nextflow log 查看每个任务的资源实际使用情况，这是最直接的方法：

nextflow log -f name,status,memory,realtime

看到内存使用率，你就能判断给多了还是给少了。我个人习惯是保留 20%-30% 的余量，但要避免翻倍式的过度分配——毕竟集群资源是要排队的，你多占一分，别人就晚一分。好了，这一讲的内存配置就到这，记住：精准配置比盲目加内存重要得多。

← 上一章 📖 返回目录 下一章 →