V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
wniming
V2EX  ›  Linux

Linux 性能分析问题: 2 台配置相近的台式机 scp 拷贝大文件的速度有差距

  •  
  •   wniming · 2023-07-08 16:18:35 +08:00 · 2547 次点击
    这是一个创建于 498 天前的主题,其中的信息可能已经有所发展或是发生改变。

    楼主家里有三台台式机,配置如下:

    192.168.1.5: amd 5700x + b550 + 16G x2 ddr4 3200 ram

    192.168.1.6: amd 5700x + b550 + 8G x2 ddr4 3200 ram

    192.168.1.7: intel 13100 + b760 + 8G x2 ddr4 3200 ram

    这三台机都有板载 2.5G 网口,型号都是 rtl 8125 ,操作系统都是 fedora 38 ,并通过 tp-link 的 2.5g 交换机相连,问题如下:

    在 1.5 这台机上通过 scp 往 1.6 这台机拷贝大文件,不管试多少次速度都能一开始就稳定在 279MB/s , 但往 1.7 这台机上拷贝大文件大部分情况下都是一开始只有 259MB/s ,然后会慢慢增加到 279MB/s ,偶尔一上来也能达到 279MB/s 。

    我通过 iperf3 测试这三台机的网络速度完全一样,均为 2.35 Gbits/sec ,拷贝过程中这三台机的 cpu 单核占用都不到 50%,我尝试过更换网线,把 fedora 默认的 r8169 驱动升级成专门的 r8125 驱动都不行

    1.7 这台机的配置比 1.6 弱的地方只有 2 点,分别是 cpu 的多核性能以及 cpu 的缓存大小,scp 拷文件用不着多核,难道这个速度差别是因为 13100 的缓存太小或 intel 处理器的缓存策略导致的?

    希望有大佬给个排查这个问题的方法。

    26 条回复    2023-08-10 15:44:03 +08:00
    dode
        1
    dode  
       2023-07-08 19:34:11 +08:00
    1.7 接的网线,交换机接口都相互换换
    wniming
        2
    wniming  
    OP
       2023-07-08 19:58:47 +08:00 via Android
    @dode 都试了,我还买了 tp link 的另一款 2.5g 交换机以及独立 pcie 2.5g 网卡都试了效果都一样。
    akira
        3
    akira  
       2023-07-08 20:47:28 +08:00
    7 的网速和 cpu 占用率有明显的相关性么
    dode
        4
    dode  
       2023-07-08 21:02:03 +08:00 via Android
    试试 nfs 拷贝,ssh 配置有影响吗
    shijingshijing
        5
    shijingshijing  
       2023-07-08 21:07:42 +08:00
    螃蟹卡是这样的,你都换成 Broadcom 的试试,Intel 的他们说也有问题。
    wniming
        6
    wniming  
    OP
       2023-07-08 21:12:12 +08:00
    @shijingshijing 能发一下相关的链接吗?
    wniming
        7
    wniming  
    OP
       2023-07-08 21:33:54 +08:00
    @shijingshijing intel 的 I225-v 芯片的网卡也有这样的问题吗?
    wniming
        8
    wniming  
    OP
       2023-07-08 21:57:30 +08:00
    @dode 1.5 这台机开启 nfs-server, 1.6 和 1.7 分别挂在 1.5 的目录,分别从 1.5 读大文件到本机的 /dev/shm/ 目录,各测了三次两者每次的速度都是 280MiB/s 。
    wniming
        9
    wniming  
    OP
       2023-07-08 21:58:04 +08:00
    @dode ssh 均为默认配置
    shijingshijing
        10
    shijingshijing  
       2023-07-08 22:09:36 +08:00   ❤️ 1
    @wniming

    Intel 的断流好像是通病,前段时间也是听人说的,Intel 自己的人都推荐碰到问题先用螃蟹卡替代了试试

    https://www.chiphell.com/thread-2492351-1-1.html
    https://www.chiphell.com/thread-2488250-1-1.html
    https://www.chiphell.com/thread-2409917-2-1.html

    螃蟹卡后面的那个字母 RTL8111B/RTL8111C/RTL8111D/RTL8111E/RTL8111F/RTL8111G(S)/RTL8111H(S)//RTL8118(A)(S)/RTL8119i/RTL8111L/RTL8111K 这种,除了工艺制程的区别,据说是通过 offloading 一部分计算让 CPU 来实现的,不是后面的字母越往后越好。

    反正我前面研究了一通,结果就是,普通人凑合用用螃蟹卡吧,不缺钱闭着眼睛买 Broadcom ,实在钱多的慌直接上 Mellanox 吧。。。
    wniming
        11
    wniming  
    OP
       2023-07-08 22:13:46 +08:00
    @akira 不管是 scp 还是 nfs 拷文件,1.6 的 cpu 占用率都要比 1.7 低一些

    往 1.6 scp 时 1.6 的 sshd 和 sftp-server 的 cpu 占用大约是 23% ,8%
    往 1.7 scp 时 1.7 的 sshd 和 sftp-server 的 cpu 占用大约是 32% ,15%

    1.6 通过 nfs 从 1.5 读文件时 1.6 的 cpu 占用大约是 17%
    1.7 通过 nfs 从 1.5 读文件时 1.7 的 cpu 占用大约是 38%

    1.6 的 cpu 占用在整个拷贝期间较为稳定,1.7 的波动较大。
    nuk
        12
    nuk  
       2023-07-08 22:20:23 +08:00
    至少需要一个同配置的硬件来确定是不是普遍的硬件问题吧,反正我想到的就是硬盘 IO 限制了。
    wniming
        13
    wniming  
    OP
       2023-07-08 22:24:32 +08:00
    @nuk 我所有的测试场景只涉及从硬盘读取,硬盘都是 ssd 读取速度都不会是瓶颈,写入都是写入到 /dev/shm , 这个是内存文件系统来着。
    jklove123bai
        14
    jklove123bai  
       2023-07-08 22:40:40 +08:00
    你硬盘都是 SSD ,但是又没说型号,有可能就是硬盘差异导致的吧
    wniming
        15
    wniming  
    OP
       2023-07-08 22:50:17 +08:00
    @jklove123bai 1.5 和 1.6 都是 sn770 ,1.7 是 英睿达的 CT250P2SSD8 ,顺序读取 2100MB/s ,scp 这个测试场景只涉及到从 1.5 的硬盘读取,target 是 1.6 和 1.7 的 /dev/shm/ ,所以 1.6 和 1.7 的 硬盘差别不会影响测试结果。
    zizon
        16
    zizon  
       2023-07-08 23:06:42 +08:00
    反向拷贝呢?
    dode
        17
    dode  
       2023-07-08 23:23:20 +08:00
    scp -vvvv
    u20237
        18
    u20237  
       2023-07-08 23:25:11 +08:00
    缺少很多有必要的信息,暂不回复
    dode
        19
    dode  
       2023-07-09 00:55:11 +08:00 via Android
    1.6 通过 nfs 从 1.5 读文件时 1.6 的 cpu 占用大约是 17%
    1.7 通过 nfs 从 1.5 读文件时 1.7 的 cpu 占用大约是 38%

    这时候 1.5cpu 占用是多少
    wniming
        20
    wniming  
    OP
       2023-07-09 01:13:04 +08:00
    @dode 1.5 的 cpu 占用这两种情况没区别,nfsd 进程都是平均 4%左右,我这个 cpu 占用率是看 top 的输出,每秒更新一次,我不是把每次输出都记录下来算一个严格的值,而是通过多次观察取一个差不多平均的值。
    documentzhangx66
        21
    documentzhangx66  
       2023-07-09 07:57:05 +08:00
    1.在没有专用测速硬件的情况下,测速以 iperf3 作为结论。
    你 iperf3 测试没问题,那就说明不存在 CPU 与网络设备瓶颈。

    2.文件传输速度有差别,你需要考虑其他问题。

    iostat -x -m -d 1

    观察一下 %util 。
    tailf
        22
    tailf  
       2023-07-09 13:20:31 +08:00
    指定一下加密算法,这个对速度的影响超级大
    szzonly
        23
    szzonly  
       2023-07-10 10:09:56 +08:00 via Android
    你要测试,就从内存读取,写入内存。
    wniming
        24
    wniming  
    OP
       2023-07-16 12:35:44 +08:00   ❤️ 1
    @dode @akira @shijingshijing @zizon @tailf @szzonly

    感谢各位关注这个问题,我已经找到原因了,是 intel 平台默认的节能策略导致的,intel cpu 在系统空闲时大多数核心只会以 800Mhz 的频率运行,有负载时才频率才往上升(原来那些玩 3A 游戏的人为了保持游戏帧率稳定就去锁 cpu 频率是有道理的),而 5700x 的最低频率不会低于 2200Mhz 。

    我用的是华硕的 b760m 重炮手主板,做以下操作这个问题就没有了:

    在华硕 Intel 芯片组的主板上,如何关闭 CPU 的睿频功能
    在 BIOS 设置菜单的 CPU Configuration--CPU-Power Management Control 下,默认情况下, Intel (R) SpeedStep(tm)为 Auto, Intel (R) Speed Shift Technology 为 Auto,CPU C-states 为 Auto,将这三个项目都设置为 Disabled, CPU 就不再发生频率跳变睿频了。

    不过这样的话 cpu 就只会保持在默认的 3.4Ghz 频率上运行,不能睿频了。
    shijingshijing
        25
    shijingshijing  
       2023-07-16 14:14:39 +08:00
    但是这样的话,CPU 一直保持满载功耗,电费也受不了,节能还是开着吧。

    节能方面还有一些设定,比如微星主板一般都有 ErP ,还有一些主板 BIOS 里面可以关闭没插板卡的 PCI-E 插槽供电,这些设定好像除了节能还能减少 EMI 干扰,如果是 HomeLab 挂机下载什么的,我觉得还是省电更重要,速度能跑就行。
    nuk
        26
    nuk  
       2023-08-10 15:44:03 +08:00
    @wniming 这个让我想起来我的一台 NAS ,ryzen 2200g ,网口直通给虚拟机,DNS 丢包必现,开始百思不得其解,后来发现是为了省电开了动态频率调整后才出现,把频率拉满就行了,不知道是不是因为虚拟机丢了中断,除了 cpu 其他策略一模一样。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   922 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 22:33 · PVG 06:33 · LAX 14:33 · JFK 17:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.