workflow - 由于对作业完成情况进行冗长的顺序检查，Snakemake 处理大型工作流程速度缓慢？ >100 倍减速

Question

我正在开发一个相当复杂的snakemake工作流程，该工作流程会产生数十万个作业。一切正常...工作流程执行，DAG 创建(感谢新的检查点实现)，但速度慢得难以忍受。我认为瓶颈在于检查已成功完成的工作，然后再继续下一个工作。更烦人的是，它对一批中启动的所有作业按顺序执行此操作，并且仅当所有检查都成功时才执行下一批。每个作业的执行时间大约需要 1 到 2 秒，并且是并行完成的(每个作业 1 个核心)，但是 Snakemake 会一次循环执行一个作业完成检查，每个作业需要 5 到 10 秒。因此每批的整个过程需要几分钟。请参阅下面的部分日志，其中显示了同一批处理中运行的连续作业的不同时间戳。时间戳之间大约有 11 秒的差异

已完成作业 42227。
已完成 5853 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:41:09]
已完成作业 119645。
已完成 5854 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:41:21]
已完成作业 161354。
已完成 230419 步中的 5855 步 (3%)
[2019 年 2 月 28 日星期四 09:41:32]
已完成作业 160224。
已完成 5856 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:41:42]
已完成作业 197063。
已完成 5857 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:41:53]
完成工作 200063。
已完成 5858 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:42:04]
已完成工作 45227。
已完成 5859 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:42:15]
已完成作业 44097。
已完成 5860 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:42:26]
完成工作 5387。
已完成 5861 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:42:37]
已完成作业 158354。
已完成 5862 步(共 230419 步)(3%)
[2019 年 2 月 28 日星期四 09:42:48]

因此，对于 20 个并行进程，2 秒用于计算，但随后会空闲 20x11 = 220 秒，然后再继续处理接下来的 20 个作业。

在上面的运行中，我有大约 20 万多个作业。如果我缩小日志之间的时间会变得更短:

已完成作业 2630。
已完成 25857 步中的 5 步 (0.02%)
[2019 年 2 月 28 日星期四 10:14:31]
完成工作886。
已完成 25857 步中的 6 步 (0.02%)
[2019 年 2 月 28 日星期四 10:14:31]
完成任务 9606。
已完成 25857 步中的 7 步 (0.03%)
[2019 年 2 月 28 日星期四 10:14:31]
完成工作 4374。
已完成 25857 步中的 8 步 (0.03%)
[2019 年 2 月 28 日星期四 10:14:32]
完成工作 6118。
已完成 25857 步中的 9 步 (0.03%)
[2019 年 2 月 28 日星期四 10:14:32]
完成工作 7862。
已完成 25857 步中的 10 步 (0.04%)
[2019 年 2 月 28 日星期四 10:14:32]
完成工作278。
已完成 25857 步中的 11 步 (0.04%)
[2019 年 2 月 28 日星期四 10:14:32]
2022年完成工作。
已完成 25857 步中的 12 步 (0.05%)
[2019 年 2 月 28 日星期四 10:14:33]

对于 25K 作业，检查时间现在为 < 1 秒。

我希望我在这里遗漏了一个参数，或者一些参数，但我担心这可能是一些不平凡的事情。

我使用以下标志运行snakemake:Snakemake --keep-going --snakefile My.Snakefile --configfile config.yaml -j 23 --每秒最大作业数 23

我在具有 256 GB 内存的 24 核系统上本地运行我的工作流程。

任何加快速度的帮助将不胜感激!

约翰

Answer 1

通过调用 GNU 并行替换工作流程中的“一对多对一”部分，我现在已经“解决”了我的问题。

专业人士:

• 没有文件检查，因此消除了 Snakemake 开销
• 不再需要检查点
• 简化的 DAG

缺点:

• 没有文件检查，因此失败的作业不太容易检索，并且必须重做工作流程的整个计算密集部分，而不仅仅是失败的文件。
• 需要深入研究其他日志才能找到到底出了什么问题。

我建议使用带有“now,fail=1”的 --halt 选项和并行的 --joblog 选项来捕获有问题的文件。

在测试集上，我将计算时间从 4 小时减少到 15 分钟。

我仍然认为 Snakemake 应该能够以某种方式处理这个问题，但我需要继续我的项目。