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

Question

我们有一个令人尴尬的并行问题——我们运行一个程序的大量实例，每个实例都有不同的数据集；为此，我们只需多次将应用程序提交到批处理队列，每次使用不同的参数即可。

然而，由于工作数量众多，并非所有工作都能完成。队列中似乎没有问题 - 所有作业都已启动。

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

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

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

虽然我有该程序的源代码，但我们希望尽可能在不修改源代码的情况下解决问题，因为我们不维护或开发它(而且大部分评论都是意大利语)。

我对这件事有一些想法:

1. 每个作业首先写入节点的本地(暂存)磁盘。然后我们可以运行另一个作业，不时检查哪些作业已完成，并将文件从本地磁盘移动到并行文件系统。
2. 在主/从系统中对程序使用 MPI 包装器，其中主管理作业队列并将这些作业分配给每个从属；从属包装器运行应用程序并捕获异常(我可以可靠地为 C++ 或可能的 Java 中的文件系统超时执行此操作吗？)，然后将消息发送回主控器以重新运行作业

与此同时，我需要纠缠我的主管以获取有关错误本身的更多信息 - 我个人从未遇到过它，但我还没有不得不将程序用于大量数据集(目前)。

万一它有用:我们在 HPC 系统上运行 Solaris，带有 SGE (Sun GridEngine) 批处理队列系统。文件系统是 NFS4，存储服务器也运行 Solaris。 HPC 节点和存储服务器通过光纤 channel 链路进行通信。

Answer 1

大多数并行文件系统，尤其是 super 计算中心的并行文件系统，都是针对 HPC 应用程序的，而不是串行农场类型的东西。因此，它们针对带宽进行了精心优化，而不是针对 IOP(每秒 I/O 操作)——也就是说，它们针对的是大型(1000 多个进程)作业，编写少量庞大的文件，而不是无数的小文件作业输出 octillions 个小文件。用户可以轻松地在他们的桌面上运行运行良好(差不多)的东西，并天真地扩展到数百个并发作业以耗尽系统的 IOP，将他们的作业和通常其他作业卡在同一系统上。

您在这里可以做的主要事情是聚合、聚合、聚合。如果您能告诉我们您在哪里运行，那将是最好的，这样我们可以获得有关该系统的更多信息。但是一些行之有效的策略:

1. 如果您为每个作业输出许多文件，请更改您的输出策略，以便每个作业写出一个包含所有其他文件的文件。如果你有本地 ramdisk，你可以做一些简单的事情，比如将它们写入 ramdisk，然后将它们 tar-gzing 到真正的文件系统。
2. 用二进制写，而不是ascii。大数据从不以ascii 格式存储。二进制格式的写入速度快 10 倍，体积更小，您可以一次写入大块而不是循环写入几个数字，这导致:
3. 大写入优于小写入。每一个IO操作都是文件系统要做的事情。少写大写，而不是循环小写。
4. 同样，不要以需要您在不同时间四处寻找以在文件的不同部分写入的格式进行写入。搜索缓慢且无用。
5. 如果您在一个节点上运行许多作业，您可以使用与上面相同的 ramdisk 技巧(或本地磁盘)来压缩所有作业的输出，并立即将它们全部发送到并行文件系统。

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

同样，大文件比小文件少将加快从目录列表到文件系统备份的一切；到处都很好。