在运行令人尴尬的并行作业时,避免重载并行文件系统的最佳方法是什么？

Question

我们遇到一个令人尴尬的并行问题 - 我们运行一个单个程序的大量实例,每个程序都有不同的数据集; 我们只需将应用程序多次提交到具有不同参数的批处理队列即可.

但是,由于有大量工作,并非所有工作都完成.它似乎不是队列中的问题 - 所有作业都已启动.

问题似乎是,随着应用程序的大量实例运行,许多作业大致同时完成,因此所有人都试图在几乎同时将其数据写入并行文件系统.

然后问题似乎是程序无法写入文件系统并以某种方式崩溃,或者只是坐在那里等待写入,批处理队列系统在等待太长时间后就会终止作业.(从我收集的问题来看,大多数未能完成的工作,如果不是全部,都不会留下核心文件)

调度磁盘写入以避免此问题的最佳方法是什么？我提到我们的程序是令人尴尬的并行突出显示每个进程都不知道其他进程的事实 - 他们不能互相交谈以某种方式安排他们的写入.

虽然我有程序的源代码,但我们希望解决问题而不必在可能的情况下修改它,因为我们不维护或开发它(加上大多数注释都是意大利语).

我对此事有一些想法:

1. 每个作业首先写入节点的本地(暂存)磁盘.然后我们可以运行另一个工作,它会立即检查已完成的作业,并将文件从本地磁盘移动到并行文件系统.
2. 在主/从系统中使用围绕程序的MPI包装器,其中主服务器管理作业队列并将这些作业关闭到每个从属服务器; 从属包装器运行应用程序并捕获异常(我可以为C++中的文件系统超时可靠地执行此操作,或者可能是Java吗？),并将消息发送回主服务器以重新运行作业

与此同时,我需要纠缠我的主管以获取有关错误本身的更多信息 - 我从未亲自遇到过它,但我还没有将程序用于大量数据集(尚未).

如果它有用:我们在HPC系统上使用SGE(Sun GridEngine)批处理队列系统运行Solaris.文件系统是NFS4,存储服务器也运行Solaris.HPC节点和存储服务器通过光纤通道链路进行通信.

Answer 1

大多数并行文件系统,特别是超级计算中心的系统,都是针对HPC应用程序而不是串行场类型的.因此,他们对带宽进行了精心优化,而不是针对IOP(每秒I/O操作) - 也就是说,它们针对的是大量(1000多个进程)作业,编写了一些庞大的文件,而不是数以万计的少量文件.工作输出小小的文件.用户可以轻松地在桌面上运行运行良好(ish)的东西,并且天真地扩展到数百个同时工作,使IOP系统挨饿,挂起他们的工作,通常是同一系统上的其他工作.

你在这里可以做的主要是聚合,聚合,聚合.最好是告诉我们你在哪里运行,这样我们就可以获得有关系统的更多信息.但是一些经过验证的策略:

1. 如果要为每个作业输出多个文件,请更改输出策略,以便每个作业写出一个包含所有其他文件的文件.如果你有本地ramdisk,你可以做一些简单的事情,比如将它们写入ramdisk,然后将它们转移到真正的文件系统.
2. 用二进制写,而不是用ascii.大数据永远不会出现在ascii中.二进制格式写入速度提高约10倍,略小,您可以一次编写大块而不是循环中的几个数字,这会导致:
3. 大写比小写更好.每个IO操作都是文件系统必须执行的操作.少量,大,写,而不是循环小写.
4. 同样,不要写入要求您在不同时间在文件的不同部分进行写入的格式.寻求缓慢而无用.
5. 如果您在节点上运行多个作业,则可以使用与上面相同的ramdisk技巧(或本地磁盘)来设置所有作业的输出,并将它们全部发送到并行文件系统.

以上的建议将有利于你的代码的I/O性能无处不在,而不是嘉世通并行文件系统.IO在任何地方都很慢,你在内存中做的越多,你执行的实际IO操作越少,它就会越快.有些系统可能比其他系统更敏感,因此您可能不会在笔记本电脑上注意到这么多,但它会有所帮助.

同样,拥有较少的大文件而不是许多小文件将加速从目录列表到文件系统备份的所有内容; 它周围都很好.