![Debian 和 Broadcom:通过网络传输文件性能不佳](https://linux22.com/image/794326/Debian%20%E5%92%8C%20Broadcom%EF%BC%9A%E9%80%9A%E8%BF%87%E7%BD%91%E7%BB%9C%E4%BC%A0%E8%BE%93%E6%96%87%E4%BB%B6%E6%80%A7%E8%83%BD%E4%B8%8D%E4%BD%B3.png)
我设置了一台运行 Debian Bullseye 和 Proxmox-kernel 的新服务器作为 NAS,主要托管视频内容(因此通常是大文件)。我注意到通过 SMB 传输文件的性能非常差,所以我尝试进行一些测试来找出系统的瓶颈。
我的服务器:
- Supermicro 主板 H12SSL-i
- AMD EPYC 7282(2.80 GHz,16 核,64 MB)
- 128MB 内存
- ZFS 根池镜像 2x 240 GB ATP N600Sc Superior M.2 NVMe SSD
- ZFS 数据池条带镜像 8x 16 TB Western Digital Ultrastar DC HC550 Helium 3.5 英寸 SAS HDD
- 25千兆Broadcom P225P网络适配器
我的客户:
- 苹果 MacBook Pro M1 Max(64GB RAM)
- Sonnet Solo10G 网络适配器
两个设备通过 UniFi Enterprise 交换机连接。
在所有情况下,我们都尝试将一个 30GBytes 的大文件从客户端传输到服务器。
- iPerf3(
iperf3 -c 192.168.109.244 -n 30720M
):给出最大网络速度(9.39 Gbits/s,~1173Mbytes/s) - rsync(
rsync --sparse --stats -hr -e 'ssh' test/ user@server:/data/pool/somewhere/
):导致传输速率出奇地差(~150 Mbytes/s) - scp(
scp test/30g.test user@server:/data/pool/somewhere/
):表现比 rsync 更好,但仍然比我预期的要差(~274Mbytes/s) - SMB 甚至更糟,但应该可以很好地工作,以使服务器发挥作用
当然,我怀疑糟糕的 ZFS 池性能是导致糟糕结果的罪魁祸首,但我无法证实:
fio --directory=/data/pool/somewhere --name=write --ioengine=libaio --iodepth=32 --rw=write --bs=1M --size=30G --numjobs=1 --direct=1
写入速度达到 900Mbytes/szpool iostat -v -y 1 1
表明池子平衡良好,写入负载均匀分布在 4 个镜像上。
我的主要问题是文件在网络上的传输速度,我找不到设置的瓶颈。网络似乎很快,池子也很快。
有人对如何进一步测试以找出瓶颈有什么建议吗?不幸的是,我现场没有配备 10G 网络适配器的 Windows 或 Linux 电脑,因此无法排除 macOS 是罪魁祸首。欢迎提出任何想法/建议。