smb跑不满千兆分析

缘起

最近在尝试使用磁带机冷备数据，磁带机本身可以达到150MB/s的速度，但是在局域网内使用smb挂载备份的数据时，只能达到30多MB的速度。

这是不能接受的，会大幅提升备份单盘磁带的时间，比如2.5T的lto6磁带，备份时间需要18小时，这是非常非常非常慢了。

之前使用硬盘备份时无所谓速度，因为挂在那运行就行了，而磁带备份是需要换磁带的，而如果写一盘磁带需要18小时，意味着每天只能写一盘磁带2.5T，备份效率极低。

理想情况下，一天至少在晚上和白天2个时段，写满2盘磁带，这样在工作日场景下非常友好，一天5T的备份速度也可以接受。

因此有了本次折腾过程，目标是smb或网络挂载的速度能达到80MB/s左右。

折腾过程

初始的smb速度

初始在备份机器上直接通过linux的cifs命令挂载

sudo mount -t cifs  //x.x.x.x/xxx /xxx -o username=xxx,password="xxx",rw,vers=2.1

挂载后测试速度就只有33MB/s，即使是大文件测试也是这个较低的速度（排除小文件多的影响），因此本质上就是这里的性能差。

而网络上讲的提升smb的挂载协议版本到3.0之类的，测试了下作用非常有限，基本还是这个速度范围波动。

还有说法是增加cifs的挂载cache参数，设置成cache=loose，但我这试了下基本没改善。

使用高性能pc的smb速度

既然备份的linux机器很慢，那可能是这台机器的cpu比较差（退役下来的十来年前的配置），换个高性能的windows机器试试。

试了下发现这台机器同样的网络链路下，速度可以达到70MB/s，但是也没法达到性能正常千兆网络的100MB/s的速度。

这里是什么原因呢？

通过iperf测度发现，网络的链路速度只有600Mbps了，这样的话是不满千兆的。

因此除了smb的性能问题，网络链路的速度也不行。

华硕mesh导致的性能问题

经过一些排查，发现网络链路的速度是由于华硕路由器组建mesh网络导致的性能损耗（在之前日记里也有分析）。

尝试把windows的高性能机器，放到非mesh节点直接和主路由器连接，把smb服务器也直连到主路由器上后再次测速。

发现速度恢复了正常，能够稳定的达到100MB/s的速度，这样看来网络链路的问题解决了。

那么把备份的Linux设备也改成和windows机器一样的网络链路，能解决问题吗？

测试了一下，速度只有微弱的提升，能到接近50MB/s，但是远远达不到像windows下的100MB。

到这里，基本就确认了在linux下的cifs实现的smb协议，性能是有较大问题的，在低性能平台上速度就是很慢。

在网上查了下也有不少吐槽cifs性能的，但是目前在linux下只有这个实现了，也是没办法改善的。

关于巨型帧

按网上查到的资料，smb可以开启巨型帧来提升速度，但是实测下来对网络链路要求有点高，由于局域网中使用了傻瓜交换机，整体测试下来开启路由器的巨型和nas的巨型帧没有正常工作。

因此这方案就没有继续研究了。

rsync的性能优势

既然smb的性能差，那换一下rsync协议试试，毕竟这个不走文件传输协议，直接怼在ssh链路上的，更加低级可能性能更高的性能。

尝试使用rsync直连备份源主机的方式，测试下来性能还是较好的，能达到60MB/s的速度。

nfs的性能尝试

另外也尝试了下nfs协议的性能，经过测试也能达到70MB/s的速度，算是不错的了。

其中nfs有一些参数可以优化性能，可以直接设置。

1、设置系统的网络参数

sudo vi /etc/sysctl.conf

# 加入下面的行

# Ref: https://gist.github.com/mizanRahman/40ba603759bfb5153189ccdc9dbbd1e4
# Disable TCP slow start on idle connections
net.ipv4.tcp_slow_start_after_idle = 0

# Increase Linux autotuning TCP buffer limits
# Set max to 16MB for 1GE and 32M (33554432) or 54M (56623104) for 10GE
# Don't set tcp_mem itself! Let the kernel scale it based on RAM.
net.core.rmem_max = 56623104
net.core.wmem_max = 56623104
net.core.rmem_default = 56623104
net.core.wmem_default = 56623104
net.core.optmem_max = 40960
net.ipv4.tcp_rmem = 4096 87380 56623104
net.ipv4.tcp_wmem = 4096 65536 56623104
# TCP Congestion Control
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = cake

# 保存后使用下面命令生效

sudo sysctl -p

2、挂载nfs时，增加下面的nconnect参数，可以提升点速度

sudo mount -t nfs  x.x.x.x:/xxx /xxx -o nconnect=16

最终方案

最终部分可以直接rsync传输的文件，直接用rsync直连源服务器进行了操作，部分不好这么操作的直接使用nfs进行了传输。

虽然没有达到100MB的千兆跑满，但是也有较好的性能提升，暂时够用了，实现8-9小时传输2.5T单盘磁带的目标。

总结

这次折腾基本上测试了在低性能冷备机器上，smb的性能问题，基本也定位到时linux下cifs驱动实现的性能不好。

而解决的方案，除了换rysnc和nfs协议，当然也可以更换高性能的服务器了。。。这里不多讨论

另外之前居然一直没发现有这个问题，挺神奇的，可能之前传输就挂在那里不大用关注性能吧。

参考文档

https://unix.stackexchange.com/questions/390093/very-slow-cifs-smb-performace

https://monsoon-cs.moe/2024-02-16-nfs-tuning/