我有许多用于 HPC/集群计算的服务器，我注意到，由于它们运行的部分计算使用 NFS 上的大文件，这会导致严重的瓶颈。我想知道如何解决这个问题。
设置：
- 34 台配备 Debian Squeeze 的服务器（每台 42 Gb RAM）
- 每台机器 12 个物理核心 + HT
- 2 台“头部”机器（头部 1 和头部 2），每台配备 500 Gb 驱动器
- 32 台“从属”机器从 head1 进行 PXE 引导
- head1 为 32 个 PXE 服务器导出 NFS 文件系统
- head2 通过 NFS 导出一个“数据”目录，其中包含所有其他机器的数据文件
- “数据”目录包含非常大的文件（5+ Gb）
- 机器之间的连接：千兆以太网
- 大多数机器不在同一物理机架上
- 使用 Open Grid Scheduler（又名 Grid Engine）进行批处理作业
该集群运行的计算之一涉及，对于每个“从属”，在开始各种计算之前，读取非常大的文件集（3Gb + 3Gb + 1.5 Gb + 750M）。我注意到，当发生这种情况时，大多数从属实际上在读取这些文件时花费了大量时间（几分钟）（而实际计算要快得多）。
目前，我已经增加了 head2 的 NFS 守护进程中的线程数，并在从属挂载选项中将其rsize设置为 32k，但这仍然是一个严重的瓶颈。wsize
我该怎么做才能提高性能，还是应该让从属服务器将这些文件托管在其硬盘上？还是应该使用完全不同的 FS 进行存储？
答案1
由于您正在进行性能分析，所以第一个问题应该是：“我基于什么数据做出这个假设？是否有网络跟踪或其他性能数据可以支持这一假设？”
这样的系统中存在很多可能的瓶颈，而且我会质疑最后选择网络文件系统，特别是因为您似乎没有写入大量数据和锁定/并发以及伴随的延迟问题可能是 NFS 最有可能的瓶颈原因。
另一方面，由于单个磁盘的 IOPS 等级相当有限，32 个并发请求（每个请求 8 GB）可能会使任何单个 SATA 磁盘过载。简单计算一下，假设每个请求的读取块大小为 64 KB，磁盘的 IOPS 为 100，则随机读取请求的速率仅为 6.4 MB/s - 除非您大量缓存数据，否则您将通过该数量的同时读取器获得该速率。
您应该仔细查看提供的性能指标，iostat看看您的磁盘是否超载。如果是，请采取适当措施（即获得能够应对负载的优质存储子系统）来补救这种情况。
答案2
这很可能不是您在此处遇到的 NFS 限制。
还要考虑到，对于每个客户端来说，这 5 GB 至少需要 40 秒才能以千兆线速传输。您有 32 个客户端在敲打 head2，并且它们不太可能同时请求相同的块。加上以太网、TCP/UDP 和 NFS 开销，您很快就会遇到您描述的几分钟。
因此，在尝试用其他协议替换 NFS 之前（是的，有开销更少的协议），请检查数据所经过的路径的每个部分（从磁盘子系统开始）是否存在任何可能的瓶颈。如果有疑问，请进行基准测试。
使用附加的或更好的硬件来消除这些瓶颈（如果有的话）比改变整个软件设置更容易。
答案3
我有一个非常相似的环境（许多刀片服务器作为工作节点，每个节点都有几 GB 甚至 TB 的巨量文件）。我使用 Hadoop 分布式文件系统 (HDFS)。请查看：
http://en.wikipedia.org/wiki/Hadoop_Distributed_File_System#Hadoop_Distributed_File_System
http://hadoop.apache.org/docs/r0.18.0/hdfs_design.pdf
不过，您可能会发现它的设置比 NFS 稍微复杂一些。