我有一个 NetApp 作为 nfs 服务器，还有两个 Linux 服务器作为 nfs 客户端。问题是，两个服务器中较新的那个极其每次同时对 nfs 服务器进行读写操作时，读写速度都会有所不同。另外，这台新服务器的读写性能都很好。旧服务器没有这个问题。
老东道主：Carp
Sun Fire x4150，8 核，32 GB RAM
SLES 9 SP4
网络驱动程序：e1000
me@carp:~> uname -a
Linux carp 2.6.5-7.308-smp #1 SMP Mon Dec 10 11:36:40 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux
新主持人：Pepper
HP ProLiant Dl360P Gen8，配备 8 核、64 GB RAM
CentOS 6.3
网络驱动程序：tg3
me@pepper:~> uname -a
Linux pepper 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
我将跳到一些说明读/写测试的图表。以下是 Pepper 及其不平衡的读/写：
这是鲤鱼，看上去不错：
测试
以下是我正在运行的读/写测试。我单独运行了这些测试，它们在 pepper 上看起来很棒，但当一起运行时（使用&），写入性能保持稳定，而读取性能则受到很大影响。测试文件的大小是 RAM 的两倍（pepper 为 128 GB，carp 为 64 GB）。
# write
time dd if=/dev/zero of=/mnt/peppershare/testfile bs=65536 count=2100000 &
# read
time dd if=/mnt/peppershare/testfile2 of=/dev/null bs=65536 &
NFS 服务器主机名为 nfsc。Linux 客户端在与其他任何设备分开的子网上有一个专用 NIC（即与主 IP 不同的子网）。每个 Linux 客户端都将服务器 nfsc 中的 nfs 共享安装到 /mnt/hostnameshare。
恩夫西罗司他
这是 pepper 的模拟读/写测试中的 1 分钟样本：
me@pepper:~> nfsiostat 60
nfsc:/vol/pg003 mounted on /mnt/peppershare:
op/s rpc bklog
1742.37 0.00
read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
49.750 3196.632 64.254 0 (0.0%) 9.304 26.406
write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
1642.933 105628.395 64.293 0 (0.0%) 3.189 86559.380
我尚未在旧主机 carp 上安装 nfsiostat，但正在努力。
/proc/mounts
me@pepper:~> cat /proc/mounts | grep peppershare
nfsc:/vol/pg003 /mnt/peppershare nfs rw,noatime,nodiratime,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0
me@carp:~> cat /proc/mounts | grep carpshare
nfsc:/vol/pg008 /mnt/carpshare nfs rw,v3,rsize=32768,wsize=32768,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,timeo=60000,retrans=3,hard,tcp,lock,addr=nfsc 0 0
网卡设置
me@pepper:~> sudo ethtool eth3
Settings for eth3:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 4
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
Link detected: yes
me@carp:~> sudo ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
卸载设置：
me@pepper:~> sudo ethtool -k eth3
Offload parameters for eth3:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
me@carp:~> # sudo ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
这一切都在 LAN 上，nfs 客户端和 nfs 服务器之间有一个全双工千兆交换机。另一方面，我发现 pepper 的 CPU IO 等待时间比 carp 要长得多，这是意料之中的，因为我怀疑它在等待 nfs 操作。
我使用 Wireshark/Ethereal 捕获过数据包，但我在这方面并不擅长，所以不确定要寻找什么。我没有在 Wireshark 中看到一堆以红色/黑色突出显示的数据包，所以这就是我所寻找的全部 :)。这种糟糕的 nfs 性能已在我们的 Postgres 环境中体现出来。
还有其他想法或故障排除技巧吗？如果我可以提供更多信息，请告诉我。
更新
根据@ewwhite 的评论，我尝试了两个不同的 tuned-adm 配置文件，但没有变化。
我的红色标记右侧还有另外两个测试。第一座山上有throughput-performance，第二座山上有enterprise-storage。
enterprise-storage 配置文件的 nfsiostat 60
nfsc:/vol/pg003 mounted on /mnt/peppershare:
op/s rpc bklog
1758.65 0.00
read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
51.750 3325.140 64.254 0 (0.0%) 8.645 24.816
write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
1655.183 106416.517 64.293 0 (0.0%) 3.141 159500.441
更新 2
答案1
在 fstab 中添加noacnfs 挂载选项是灵丹妙药。总吞吐量没有变化，仍然在 100 MB/s 左右，但现在我的读写更加平衡了，我不得不想象这对 Postgres 和其他应用程序来说是个好兆头。
您可以看到我标记了测试时使用的各种“块”大小，即 rsize/wsize 缓冲区大小挂载选项。令人惊讶的是，我发现 8k 大小在 dd 测试中具有最佳吞吐量。
这些是我现在正在使用的 nfs 挂载选项/proc/mounts：
nfsc:/vol/pg003 /mnt/peppershare nfs rw,sync,noatime,nodiratime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0
仅供参考，noac选项 man 条目：
ac / noac
选择客户端是否可以缓存文件属性。如果未指定任何选项（或指定了 ac），则客户端将缓存文件属性。
为了提高性能，NFS 客户端会缓存文件属性。每隔几秒钟，NFS 客户端就会检查每个文件属性的服务器版本是否有更新。在这些小间隔内服务器上发生的更改将无法检测到，直到客户端再次检查服务器。noac 选项可防止客户端缓存文件属性，以便应用程序可以更快地检测到服务器上的文件更改。
除了阻止客户端缓存文件属性之外，noac 选项还会强制应用程序写入同步，以便文件的本地更改立即在服务器上可见。这样，其他客户端在检查文件属性时就可以快速检测到最近的写入。
使用 noac 选项可在访问相同文件的 NFS 客户端之间提供更高的缓存一致性，但会显著降低性能。因此，我们鼓励明智地使用文件锁定。数据和元数据一致性部分详细讨论了这些权衡。
我在网上看到过关于属性缓存的褒贬不一的观点，所以我唯一的想法是，这是一个必要的选项，或者可以很好地与 NetApp NFS 服务器和/或具有较新内核 (>2.6.5) 的 Linux 客户端配合使用。我们在具有 2.6.5 内核的 SLES 9 上没有看到这个问题。
我还阅读了关于 rsize/wise 的不同意见，通常你会采用默认值，目前我的系统是 65536，但 8192 给了我最好的测试结果。我们还将对 postgres 进行一些基准测试，因此我们将看看这些不同的缓冲区大小表现如何。