NFS并发访问性能瓶颈分析与优化方案咨询

测试程序 #

#include <fcntl.h>
#include <unistd.h>
#include <string>
#include <stdexcept>
#include <cstring>
#include <iostream>

int main(int argc, char* argv[]) {
    if (argc != 2) {
        std::cerr << "Usage: " << argv[0] << " <filename>\n";
        return 1;
    }

    const std::string filename = argv[1];
    const int numIterations = 10000;

    for (int i = 0; i < numIterations; ++i) {
        int fd = open(filename.c_str(), O_RDONLY);

        if (fd == -1) {
            throw std::runtime_error("Failed to open " + filename + " (Iteration " + std::to_string(i + 1) + "): " + strerror(errno));
        }

        if (close(fd) == -1) {
            throw std::runtime_error("Failed to close " + filename + " (Iteration " + std::to_string(i + 1) + "): " + strerror(errno));
        }
    }

    return 0;
}

编译命令 #

g++ -O2 test.cpp -o test_open_close

单进程运行结果 #

$ time /tmp/test_open_close /mnt/nfs_mnt/xxxxxx

real    0m0.115s
user    0m0.003s
sys 0m0.066s

并行测试脚本及结果 #

测试脚本 #

#!/bin/bash

# 要执行的命令
command="/tmp/test_open_close /mnt/nfs_mnt/xxxxxx"

# 并发执行次数
num_executions=360

# 执行命令并捕获退出状态的函数
run_command() {
    $command 2>/dev/null
}

# 记录开始时间
start_time=$(date +%s.%N)

# 并发启动命令
for i in $(seq 1 $num_executions); do
    run_command &
done

# 等待所有后台进程完成
wait

# 记录结束时间
end_time=$(date +%s.%N)

# 计算耗时
duration=$(echo "$end_time - $start_time" | bc)

echo "Executed $num_executions processes in $duration seconds"

运行结果 #

$ bash /tmp/test.sh
Executed 360 processes in 35.127017601 seconds

并行运行总耗时几乎与串行一致。

额外异常现象 #

在test.sh运行期间，在另一个Shell执行time /tmp/test_open_close /mnt/nfs_mnt/xxxxxx时，不同用户执行的耗时存在明显差异：

1. 使用与test.sh相同的用户：

$ time /tmp/test_open_close /mnt/nfs_mnt/xxxxxx

real    0m22.753s
user    0m0.005s
sys 0m0.121s

2. 使用不同用户：

$ time /tmp/test_open_close /mnt/nfs_mnt/xxxxxx

real    0m0.197s
user    0m0.000s
sys 0m0.158s

3. 使用相同用户但在不同主机：

$ time /tmp/test_open_close /mnt/nfs_mnt/xxxxxx

real    0m3.055s
user    0m0.003s
sys 0m0.227s

系统环境 #

Rocky 8.8，内核版本4.18.0，测试主机拥有378核。

技术问询与解答 #

1. 该场景下的性能瓶颈是否为NFS客户端锁？ #

是。NFS客户端在处理文件元数据操作（如open/close）时，会对同一个文件的inode元数据加客户端级别的独占锁。当大量同用户进程并发打开/关闭同一个文件时，所有请求会串行等待这把锁释放，导致并行总耗时接近串行执行的总和（360*0.115≈41.4s，实际测试35.1s，差距源于部分锁竞争的优化）。

2. 为何不同用户执行会出现性能差异？ #

NFS客户端的元数据锁是按用户UID隔离的。不同用户的进程访问同一个文件时，客户端会为每个用户维护独立的元数据缓存和锁，因此不会触发跨用户的锁竞争。而同用户的进程共享同一套元数据锁，必须排队等待；不同主机的同用户进程，因为锁是客户端本地的，所以竞争只存在于同一主机内，跨主机的请求不会受本地锁影响，耗时仅受NFS服务器端的并发处理能力限制。

3. 如何优化该场景下的NFS并发访问性能？ #

• 调整NFS客户端缓存参数：
  • 增大acregmin/acregmax（文件属性缓存时间），减少元数据请求频率；
  • 启用lookupcache=all，提升文件查找缓存效率。
• 避免同用户大量并发操作同一文件：
  • 拆分任务到不同用户执行，利用UID隔离的锁机制；
  • 合并进程内的文件操作，减少open/close的调用次数（比如一次性打开文件完成所有操作再关闭，而非循环打开关闭）。
• 优化NFS服务器配置：
  • 启用NFSv4.1+的pNFS（并行NFS），分散元数据和数据处理压力；
  • 增大服务器端的文件系统缓存和连接数限制，提升并发处理能力。
• 内核参数调优：
  • 调整sunrpc.tcp_max_slot_table_entries，增大RPC请求队列长度；
  • 启用nfs.cto（close-to-open）缓存模式，优化文件关闭后的元数据同步逻辑。

内容的提问来源于stack exchange，提问作者Mingfei Gao