我在Ubuntu 22.04上的Docker中运行一个Snakemake RNA-seq流水线（FastQC → fastp → STAR → samtools → Salmon）。

这个工作流能正确运行好几个小时，但最终一个或多个 fastp 作业停止推进。每次的样本都不同。

出现这种情况时：

• fastp 一直在运行且无法结束
• CPU使用率降至大约2–3%
• 进程状态为 SL+
• Snakemake会无限等待，因为该作业从不退出

然而，在相同的FASTQ文件上手动执行完全相同的 fastp 命令，通常在约6 分钟内就能完成。

我正在运行：

snakemake --cores 16 (previously --cores 24)

，使用：

• fastp：4线程（之前是8 线程）
• STAR：8线程

数据存放在本地NVMe驱动上，并被绑定挂载到Docker容器中。磁盘空间和内存并不构成瓶颈。

是否有人只在Snakemake下重复/并发执行时看到 fastp 挂起？这更可能是Snakemake调度问题、一个 fastp 问题，还是其他原因？

解决方案

这并不真正属于Snakemake调度问题。Snakemake会启动该进程并等待它退出；如果 fastp 仍然出现在进程表中并停留在 SL+，那么此时Snakemake已经没有太多可调度的任务了。

受影响的样本每次运行都不同这一点也很重要。这削弱了FASTQ文件损坏或输入中某些可重复的边缘情况的可能性，因为你会希望同一个文件会一直触发它。同样地，如果完全相同的 fastp 命令在工作流之外能正常完成，我会关注长时间运行的流水线环境里有哪些与命令本身不同的因素。

我会在终止其中一个挂起进程之前先检查它。一次快速的 strace 往往足以判断它是在对 futex 不断阻塞、还是在等待文件I/O，还是被卡在其他地方。这比通过改变线程数来期望行为变化要更有效地缩小问题范围。