![LAN 上的目标网络速度](https://linux22.com/image/44177/LAN%20%E4%B8%8A%E7%9A%84%E7%9B%AE%E6%A0%87%E7%BD%91%E7%BB%9C%E9%80%9F%E5%BA%A6.png)
我有一个 Solaris 11 系统,它有多个 NFS 导出,可以访问 LAN 中的其他系统。我使用Linux系统作为客户端进行测试。
我编写了一个快速脚本来测试读取速度,在千兆位 LAN 上的平均读取速度约为 110Mbps(或 13MB/s)。我本以为它会变得更快。 SSH (scp) 仅提供 3.8MB/s,但这是加密的。
http给我11.5M/s,类似于NFS比。这不是很低吗?
这些数字的瓶颈可能是什么?
答案1
NFS 无法真正最大化吞吐量,因为客户端不断发送请发给我这么多数据到服务器(这么多被限制为几千字节)并在询问更多之前等待完整的答案,这意味着死的当所有队列都为空时。网络上的所有 FS(CIFS、SSHFS)都有相同类型的问题(还有 IIRC scp,或者可能只是sftp
,我不记得了)
除了加密开销之外,ssh
还存在一些更多的性能限制(请参阅这里了解详情)。
HTTP,除非您使用执行分块请求的客户端,否则应该是直接的 TCP,因此不应该有这种限制。 TCP 应使用其拥塞控制算法来最大化吞吐量,同时避免拥塞。虽然最初的几千字节传输速度可能很慢,但如果两台计算机通过同一交换机连接,您应该能够在十分之几秒内最大化带宽。可能存在一些网络质量较差的情况(例如奇怪的数据包丢失)。
您可能想尝试的事情:
/dev/zero
通过普通 TCP 连接(使用socat
或例如)传输内容nc
,以排除 FS 访问的瓶颈。- 检查网络接口统计数据是否存在传输错误以及 TCP 堆栈统计数据 (
netstat -s
) - 使用
iperf
(TCP 和 UDP)进行测试。
答案2
我过去也遇到过类似的情况,我的解决方法是强制Solaris和Linux挂载NFS v3而不是v4。
从 Solaris 端,您可以编辑 /etc/default/nfs 并将服务器端的变量设置为 server 并仅接受 NFS v3 端。
不记得变量名称,但它是不言自明的。
您所做的测试是复制单个大文件还是多个文件?如果它是多个文件,我不会感到惊讶,但如果它是单个文件,那就更好了。
另外,你有什么样的底层存储?单盘?突袭设置?这也会影响你的表现。
答案3
底层文件系统提供数据的速度有多快? NFS 本身移动数据的速度比您看到的要快,这表明还存在其他瓶颈。您可以通过使用 iperf 确认网络可以传输更高的带宽来说服自己这一点。
我将登录到 Solaris 系统,并将文件从要导出的文件系统复制到 /dev/null,以查看流式传输的速度。请注意,您需要做出一些努力,不要对文件系统缓存中已有的文件执行此读取测试。对于其他文件系统,您可以 umount/mount 以使缓存失效,但仅此一点对于 ZFS 来说还不够。
答案4
您必须了解堆栈每个部分的功能。 NFS 共享的文件系统由哪些类型的磁盘组成? SAS? SATA?固态硬盘?每种类型和尺寸以及转速是什么?旋转延迟?是4k硬盘吗? ZFS 针对 512 字节驱动器进行了优化,并且使用新的“高级格式”磁盘存在已知的性能问题。
您的 I/O 工作负载有多大?这也会影响存储的显示速度。
从纯粹的存储角度来看,这些问题将影响后端磁盘写入和读取数据的速度。例如,假设您的 NFS 共享来自 7200 RPM 1TB SATA 磁盘上的文件系统,并且您的工作负载大小为 64KB 并且大部分是随机的。
Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time: 8.4 ms
Average Write Seek Time: 8.9 ms
Rotational latency: .120 ms
Average Latency: 4.166 ms
Average Read Service Time: 12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs: 79.000
Best Case Write IOPs: 76.000
--------------------------------------------------------------------------------
Best Case Read Throughput: 4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs: 55.300
Real World Write IOPs: 53.200
--------------------------------------------------------------------------------
Real World Read Throughput: 3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------
这将使您了解在特定工作负载大小下可以从单个磁盘获得的实际性能。
您可以通过使用写入缓存或异步挂载 NFS 文件系统来提高性能,这样在下一个 I/O 开始之前就不需要写入确认(我不建议这样做,因为这会使您的数据面临风险)。
一旦您了解了后端存储的性能,您就可以开始查看由 NFS(是 v3?v4?tcp?udp?)或 SSH(您使用哪种加密算法?您可以使用更轻量级的算法)创建的额外开销。像 arcfour 这样的算法来提高性能),或者网络本身。您有便宜的 1GbE NIC 吗?或者更高端的服务器质量网卡?您是否在多个服务之间共享该网卡?还有其他什么东西会在您的网络上产生流量吗?网络拥塞、冲突或高重传率怎么样?
所有这些加在一起会进一步降低后端存储的表观性能,这实际上意味着它们加起来会使客户端显得非常慢。
现在,上面的数字是最坏的情况,对吧? 100%随机同步工作负载。如果您有顺序工作负载,或者可以提高 IO 工作负载大小,则可以显着提高性能。例如,如果您可以将 IO 大小提高到 128k,您的性能就会加倍,并且根据您的 NFS 客户端,您可以将 rsize 和 wsize 设置为各种设置来测试性能。毕竟存在收益递减点。
如果您有多个磁盘、镜像或 RAID,则必须为此调整数字。
真实世界的磁盘性能几乎从来都不是磁盘包装盒侧面印刷的内容。