近期,我将家庭存储全面升级到UniFi UNAS Pro 8,并配备了Intel E610‑XT2 10千兆以太网卡,主力机器IRONHEART以及Minisforum MS‑01迷你PC也均接入同一10GbE网络。硬件标签全部显示10Gbps,Windows任务栏的网络速度指示灯也显示为10Gbps,但在日常文件复制时,Robocopy报告的速度常常在100至200Mbps之间徘徊,距离理想的千兆带宽相去甚远。 面对如此尴尬的实际表现,我首先把矛头指向了NAS本身。UNAS Pro 8内部有六块16TB的机械盘组成RAID 6,并配备了NVMe SSD缓存,理论上磁盘吞吐量应该足够支撑数Gbps的写入。系统日志、iostat均显示磁盘并未出现饱和,Immich的照片库也在后台进行大量小文件读写,这些都被我列为重点嫌疑对象。 我先后尝试将SSD缓存模式从读写切换为只读,甚至直接关闭Immich服务,但文件复制的速度没有任何变化。
随即检查了SMB签名、Windows Defender的网络扫描功能,确认没有因为安全策略导致额外的CPU开销。即使把所有可能的存储层因素排除后,速度仍然停留在200Mbps左右。 此时,我决定把测试范围从存储彻底抽离,直接在两台机器之间运行iperf3来测量纯粹的网卡性能。执行iperf3 -c 192.168.1.222 -P 4 时,正向带宽仅为133Mbits,而使用 -R 参数进行反向测试时,速率却达到了1.33Gbits,出现了明显的单向瓶颈。这一结果瞬间把问题定位到了网卡或驱动的配置上,磁盘、文件系统、RAID全部被排除在外。 为了进一步了解网卡内部状态,我在PowerShell中运行 Get‑NetAdapterStatistics -Name "Ethernet - 10 Gig Intel",发现 ReceivedDiscardedPackets 计数已接近一百万,并且在一次十秒的iperf3测试期间又新增了268个被丢弃的包。
数据包被大量丢弃往往意味着接收端缓冲区不足,导致后续帧被直接丢掉。 根据 Intel E610‑XT2 的官方文档,默认的接收缓冲区仅为512个,而该网卡最大支持4096个。我立即将其调至上限: Set‑NetAdapterAdvancedProperty -Name "Ethernet - 10 Gig Intel" -DisplayName "Receive Buffers" -DisplayValue "4096"。随后再次运行 iperf3,丢弃计数立即降为0,接收方向的吞吐量从1.33Gbps跃升至5.15Gbps,性能提升近四倍。 虽然接收端已经大幅改善,但发送方向仍然停留在约313Mbps,显示出与接收方向完全不对称的性能表现。于是我把目光转向了发送端的 "Large Send Offload V2 (IPv4)" 功能。
LSO 允许操作系统把大块的TCP数据块交给网卡自行分段,以降低CPU占用,但在某些硬件驱动与Windows的组合中,这个优化反而会导致分段错误或性能倒退。 我在同一网卡的高级属性中将 LSO V2 for IPv4 设为禁用: Set‑NetAdapterAdvancedProperty -Name "Ethernet - 10 Gig Intel" -DisplayName "Large Send Offload V2 (IPv4)" -DisplayValue "Disabled"。随后重新运行 iperf3 的单向发送测试,惊人的是带宽直接从313Mbps飙升至7.03Gbps,提升幅度超过二十倍。 结果验证后,我再次使用 Robocopy 将一个数十GB的大文件写入 UNAS Pro 8 的 RAID 6 卷,Robocopy 报告的写入速度为 350,201,354 Bytes/sec,约合 20,038 MB/min,换算为网络带宽约为 2.8Gbps。相较于先前的 200Mbps,提升幅度接近 14 倍,终于让 10千兆网卡在真实工作负载中发挥了应有的水平。 值得注意的是,Large Send Offload 本身是一项成熟且普遍有益的技术,大多数情况下它可以显著降低CPU使用率并提升吞吐。
出现本次瓶颈的原因可能涉及 Intel E610‑XT2 驱动与 Windows 10/11 在 IPv4 分段路径上的细微兼容问题,或者是固件版本的特定组合导致的边缘Bug。因此,盲目全局关闭 LSO 并不可取,必须在确认瓶颈后进行针对性调节。 在进一步验证时,我还检查了网络交换机端口的配置。UniFi Dream Machine Pro 上的 10GbE 端口默认开启自动协商,但在部分旧款 SFP+ 模块上出现不匹配的情况。通过在交换机侧手动将端口速率固定为 10G、全双工,并启用 Jumbo Frame (MTU 9000),我再次运行 iperf3,单向带宽提升至约 9.4Gbps,接近理论上限。 与此同时,TCP/IP 协议层面的其他 Offload 功能,如 Checksum Offload 和 Segmentation Offload,也会在特定驱动组合下产生冲突。
建议先在网卡属性中将所有 Offload 关闭,再逐项打开,以定位是哪一项导致性能下降。 如果你使用的是 Windows Server 2019/2022,还可以借助 netsh int tcp set global chimney=disabled 来禁用 TCP Chimney,它曾在早期的 Windows Server 2003 SP2 中导致类似的网络瓶颈。禁用后配合上述网卡的 Jumbo Frame,往往可以让 10GbE 网络在文件共享、虚拟化迁移等场景中保持稳定的高速。 总结来看,10千兆以太网在实际部署中最常见的性能瓶颈往往隐藏在驱动层面的 Offload 参数、缓冲区大小以及交换机的端口配置上。通过系统化的分层排查 - - 先排除物理链路和交换机设置,再使用 iperf3 等基准工具测量原始网络带宽,最后依据测得的丢包、延迟和吞吐量数据调节网卡的高级属性 - - 可以快速定位并解决从 300Mbps 恢复到接近 10Gbps 的问题。 在后续的运维中,我建议将关键网卡的统计信息加入监控。
例如,在 PowerShell 中定期执行 Get‑NetAdapterStatistics 并记录 ReceivedDiscardedPackets、OutboundDiscarded 等计数,配合 Performance Monitor 的相关计数器,一旦出现异常增长即可触发告警,提前防止性能回退。 此外,保持网卡固件与驱动版本同步也非常重要。Intel 官方会定期发布针对特定平台的微码更新,修复已知的 Offload 兼容性问题。若在升级后出现类似现象,可回滚至前一版本或等待下一个补丁发布。 。
