我有一个可以简单并行化的应用程序，但它的性能在很大程度上受 I/O 限制。应用程序读取存储在文件中的单个输入数组，该文件的大小通常为 2-5 GB（但我预计这个数字将来会增长）。典型的计算将相同的操作应用于该数组的每一行或每一列。对于 CPU 密集型操作，我可以很好地扩展到大约 100 个处理器，但对于较慢的操作，I/O 和相关通信（NFS 访问）占主导地位，我不能有效地使用多个处理器。
在这种情况下，什么是高效和便携（理想情况下是便携高效）的选择？并行 HDF5 似乎很有希望。有没有人有它的真实经历？
MPI-I/O 是否值得研究？它可以有效地使用给定的文件布局，还是我必须调整所有内容？
在这种情况下，并行 I/O 可以为您提供帮助，但如果您使用（本质上非常串行的）NFS 来提供文件，那么它不会产生您可能想要的全部效果 - 将会出现串行瓶颈文件服务器并拥有数百个向单个服务器发出请求的进程不会为您提供数百个通过单个进程执行此操作的加速因素。尽管如此，它在一定程度上还是有帮助的，特别是因为听起来瓶颈是读取而不是写入，如果您的系统升级到完全并行的文件系统，这将是一个很大的改进。
MPI-IO 非常底层；值得了解一些关于它的东西，以了解并行 HDF5、NetCDF4或ADIOS的“幕后”发生了什么，但自己使用它实际上只适合在编译时结构众所周知的原始二进制数据。HDF5 和 NetCDF4 更加灵活。
请注意，如果您的数据相对简单——例如，大数据结构主要是 n 维数组或向量——我推荐 NetCDF4（也是并行的，基于 HDF5）而不是 HDF5；它使用起来要简单得多。HDF5 更复杂，作为复杂性的交换，允许使用非常复杂的数据模型。但如果这是您不需要的功能，那么在 NetCDF4 中开始使用会更快。
在我们中心，我们有一个下午和一天的并行 I/O 课程，我们讨论基本概念、MPI-IO、HDF5 和 NetCDF4；幻灯片可以在这里找到。
我假设您的可扩展性问题与输出有关，而不是与输入有关。并行输入相当简单 - 我所做的是每个 CPU 打开输入 NetCDF 文件并读取属于其 tile 的数组部分（可能有多少阅读器可以打开同一个 NetCDF 文件但我不确定）。并行输出问题更大。
我目前正在做的事情不是很理想，但现在可以工作。我在一个 CPU 上收集所有内容并进行串行输出。与此同时，其他玩家等待作者完成。这对我来说效果很好，因为我设法将计算与输出的比率保持在相当高的水平——因此可扩展性对于超过 200 个 CPU 来说是很好的。但这不是您正在寻找的解决方案。
另一种解决方案是 Yann 建议的 - 串行写入 N 个文件并让无人机 CPU 将这些图块组装成一个块 - 如果 RAM 允许的话。
除了先前答案中建议的并行 I/O 库外，您可能还想查看 Parallel NetCDF http://trac.mcs.anl.gov/projects/parallel-netcdf，因为您已经熟悉 NetCDF 和 MPI。我在实践中没有使用它，但是当我用收集 + 串行 I/O 碰壁时，我确实打算朝那个方向走。