Nextflow是开发科学工作流程在HPC系统上使用的强大工具。它提供了一种简单的解决方案，以一种便携式的方式使用优雅的反应式/函数式编程模型来部署大规模的并行化工作负载。
它支持最流行的工作负载管理器，如Grid Engine、Slurm、LSF和PBS等，还提供了其他开箱即用的执行程序，并为每个执行程序提供了合理的默认设置。然而，每个HPC系统都是一个具有自己特点和限制的复杂机器。因此，在运行新的软件或计算密集型流程之前，您应该始终咨询您的系统管理员。
在这一系列的文章中，我们将分享我们学到的顶级技巧，这些技巧应该可以帮助您更快地获得结果，同时保持良好的系统管理员关系。
-
不要忘记设置你的HPC系统
默认情况下，Nextflow在运行它的计算机上生成并行任务执行。这通常对于开发目的是有用的，然而，在使用HPC系统时，您应该指定与您的系统匹配的执行程序。这将指示Nextflow将管道任务作为作业提交到您的HPC工作负载管理器中。例如，在启动目录中的nextflow.config文件中添加以下设置即可完成此操作：
process.executor = 'slurm'
使用上述设置，Nextflow将向您的Slurm集群提交作业执行，为管道中的每个作业生成一个sbatch命令。在此链接中查找与您的系统匹配的执行程序。更好的做法是，直接设置环境变量，从而为了防止在特定环境中意外使用本地执行程序（local executor），可以使用以下系统变量定义Nextflow要使用的默认执行程序：
export NXF_EXECUTOR=slurm
-
将Nextflow作为作业运行
系统管理员肯定已经警告过你，登录/头节点（login/head node）应该仅用于提交作业执行，而不是运行计算密集型任务。当运行Nextflow流程时，nextflow.nfz这个程序本身可以用于监视作业执行情况。（前提是你已正确指定了executor，如第1点所述）。
然而，长时间在登录节点上跑nextflow.nf这个脚本永远不是一个好习惯，因此一个好的做法是将Nextflow本身作为集群作业运行，即把nextflow.nf包装成一个shell脚本，作为任务投递到计算节点。一个pipleline的shell脚本可能需要分配2个CPU和2GB的资源。
假设下面的脚本名字为my_nf_test.sh
#！/usr/bin env bash
#slurm settings
...
source ~/.bashrc
conda activate nf
nextflow run your_nextflow.nf
#投递任务
srun my_nf_test.sh
-
使用queueSize指令
queueSize指令是在nextflow.config文件的一部分，它定义了在给定时间内排队的进程数量。默认情况下，Nextflow会同时提交最多100个作业进行执行。根据您的HPC系统配额和吞吐量，增加或减少此设置。例如：
executor { name = 'slurm' queueSize = 50 }
-
指定最大堆大小
Nextflow运行时在Java虚拟机之上运行，Java虚拟机的设计初衷是尝试分配尽可能多的可用内存。这在设计用于共享计算资源的HPC系统中不是一个好的实践。为了避免这种情况，请使用-Xms和-Xmx Java标志指定Java VM可以使用的最大内存量。这些可以使用NXF_OPTS环境变量指定。
例如：
export NXF_OPTS="-Xms500M -Xmx2G"
上述设置指示Nextflow分配500MB到2GB的Java堆内存。
-
限制Nextflow的提交速率
Nextflow会尽快提交作业执行，这通常不是问题。但是，在一些HPC系统中，提交作业的速度受限制，或者应该受限制以避免降低整个系统的性能。为了避免这个问题，你可以使用submitRateLimit来控制Nextflow作业提交吞吐量。该指令是执行器配置范围的一部分，它定义了每个时间单位可以提交的任务数。submitRateLimit的默认值为无限制。你可以像这样指定submitRateLimit：
executor { submitRateLimit = '10 sec' }
您还可以更明确地指定它为#进程/时间单位的速率：
executor { submitRateLimit = '10/2min' }
结论
Nextflow旨在使对工作流的每个方面都有控制。这些选项允许你塑造Nextflow如何与您的HPC系统通信。这可以使工作流更加强大，同时避免系统超负荷。
