CIFS 마운트로의 wget 다운로드 속도가 너무 나쁩니다. 로컬로 다운로드하여 cp와 공유하세요.

내 CIFS 공유 wget 다운로드 속도가 끔찍합니다.

이것은 wget이 공유에 직접 다운로드하는 속도입니다.

d64-18ef-43d5-b295-   2%[                    ] 100.18M  11.7MB/s    eta 6m 2s

로컬 FS로 wget을 다운로드하는 속도는 다음과 같습니다.

glish_x32.iso?t=cff   6%[>                   ] 253.20M  55.2MB/s    eta 70s

놀랍게도 로컬 FS에서 CIFS 공유로 복사하는 속도는 다음과 같습니다.

root@gw:/tmp# pv Win10_22H2_English_x32.iso > /opt/isos_rw/Win10_22H2_English_x32.iso
1.29GiB 0:00:25 [53.4MiB/s] [==============>                   ] 45% ETA 0:00:30

분명히 wget은 여기서 흥미로운 일을 하고 있는 것 같습니다. 이 문제를 어떻게 해결하나요? 다른 다운로드 도구도 옵션입니다.

편집하다:내 활성 마운트:

//172.16.8.232/Install/Isos on /opt/isos_rw type cifs (rw,relatime,vers=3.0,cache=strict,username=InstallRW,uid=0,noforceuid,gid=0,noforcegid,addr=172.16.8.232,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=8388608,wsize=8388608,echo_interval=60,actimeo=1)

문제의 머신은 2GB RAM을 갖춘 4코어 AMD GX-412TC SOC인 내 게이트웨이 머신입니다. 내 업링크는 CAT6e 1000BASE-T 구리를 통해 CIFS 공유에 연결된 0.5Gig 광섬유입니다.

게이트웨이에서 두 인터페이스는 모두 전이중입니다.

[   13.385878] igb 0000:01:00.0 enp1s0: igb: enp1s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[   14.325858] igb 0000:02:00.0 enp2s0: igb: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

하드웨어:

01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
        Subsystem: Intel Corporation I211 Gigabit Network Connection
        Flags: bus master, fast devsel, latency 0, IRQ 29
        Memory at f7b00000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at 1000 [size=32]
        Memory at f7b20000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 00-0d-b9-ff-ff-57-9b-8c
        Capabilities: [1a0] Transaction Processing Hints
        Kernel driver in use: igb
        Kernel modules: igb

내 LAN에 있는 CIFS 서버가 표시됩니다.

Intel I210 Gigabit Network Connection 1 Gbps

추가할 만한 다른 내용이 있으면 아래에 의견을 남겨주세요.

편집하다: 하드웨어 문제인지 확인하기 위해 새 하드웨어를 주문하겠습니다. 다시 보고하겠습니다.

N+1 편집: wget과 top을 실행합니다. 결과 보기. CIFS의 CPU 사용률은 약 33%인 반면 SSD는 95%로 거의 가득 찼습니다.

N+2 편집: 오늘 새 하드웨어를 얻었습니다. I211 대신 I210 NICS도 있습니다. 이제 보내기-받기 대기열 수를 두 배로 늘려야 합니다. 지금은 하드웨어를 설정하고 있어요.

N+3 편집: 새로운 하드웨어와 별 차이가 없습니다. 그래도 추적을 좀 하고 있어요.

wget to SSD (55 MB/s):

_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=949999}) = 1 (in [4], left {tv_sec=0, tv_usec=949994})
read(4, "\7\0\0H\213D$0L\213 H\270\0\0\0\0\0\0\0\0H\2138H\270\0\0\0\0\0\0"..., 8192) = 8192
write(3, "\7\0\0H\213D$0L\213 H\270\0\0\0\0\0\0\0\0H\2138H\270\0\0\0\0\0\0"..., 4096) = 4096
write(3, "_net_resolve_address\0grub_net_ro"..., 4096) = 4096
_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=949999}) = 1 (in [4], left {tv_sec=0, tv_usec=949995})
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
write(3, "\0\0\1\0\0\0\3\0\0\0Y\0\0\0\0\0\0\0\236\1\0\0\0\0\0\0\1\0\0\0\f\0"..., 4096) = 4096
_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=949999}) = 1 (in [4], left {tv_sec=0, tv_usec=949995})
read(4, "\0\0\225\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\240\0\0\0\20\0"..., 8192) = 8192
write(3, "\0\0\225\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\240\0\0\0\20\0"..., 4096^C) = 4096
strace: Process 12012 detached

wget to CIFS (13MB/s):

_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=949999}) = 1 (in [4], left {tv_sec=0, tv_usec=949994})
read(4, "ATH\213L$0H\213T$8H\213t$(L\215L$pH\270\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(3, "ATH\213L$0H\213T$8H\213t$(L\215L$pH\270\0\0\0\0\0\0\0\0"..., 8192) = 8192
_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=949999}) = 1 (in [4], left {tv_sec=0, tv_usec=949994})
read(4, "\0\0\0\0\0D\2138\351\202\6\0\0\200{\1\0\17\205d\4\0\0A\376\305\17\205[\4\0\0"..., 8192) = 8192
write(3, "\0\0\0\0\0D\2138\351\202\6\0\0\200{\1\0\17\205d\4\0\0A\376\305\17\205[\4\0\0"..., 8192) = 8192
_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=949999}) = 1 (in [4], left {tv_sec=0, tv_usec=949994})
read(4, "CRIPTION\0net_get_dhcp_option\0per"..., 8192) = 8192
write(3, "CRIPTION\0net_get_dhcp_option\0per"..., 8192^Cstrace: Process 12050 detached
 <detached ...>

따라서 cp는 최적의 write(2) 버퍼 크기인 131072를 사용하게 됩니다. 그러나 wget은 8192를 사용합니다. wget에서 FS로 직접 4096의 쓰기 버퍼 크기를 사용하는 것을 볼 수 있듯이 이 버퍼 크기는 컨텍스트에 따라 분명히 변경됩니다.

출력을 직접 버퍼링하는 경우:

root@gw:/opt/isos_rw/ubuntu# wget http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current/amd64/iso-cd/debian-9.7.0-amd64-xfce-CD-1.iso -O - | dd bs=100k > iso.iso
--2023-04-23 16:18:45--  http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current/amd64/iso-cd/debian-9.7.0-amd64-xfce-CD-1.iso
Resolving ftp.funet.fi (ftp.funet.fi)... 193.166.3.2, 2001:708:10:8::2
Connecting to ftp.funet.fi (ftp.funet.fi)|193.166.3.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 672137216 (641M) [application/x-iso9660-image]
Saving to: ‘STDOUT’

-                           100%[===========================================>] 641.00M  43.2MB/s    in 14s

2023-04-23 16:18:59 (46.0 MB/s) - written to stdout [672137216/672137216]

1+9203 records in
1+9203 records out
672137216 bytes (672 MB, 641 MiB) copied, 13.9526 s, 48.2 MB/s

나는 충분한 속도를 달성했습니다. 어떤 단서가 있나요?

이전에 커널 버전을 추가하는 것을 잊어버렸습니다. 여기 있습니다:

root@gw:/opt/isos_rw/ubuntu# uname -a
Linux gw 4.19.0-23-686-pae #1 SMP Debian 4.19.269-1 (2022-12-20) i686 GNU/Linux

그런데, 컬의 속도는 같습니다.

root@gw:/opt/isos_rw/ubuntu# curl http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current/amd64/iso-cd/debian-9.7.0-amd64-xfce-CD-1.iso -o iso.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  641M  100  641M    0     0  12.3M      0  0:00:51  0:00:51 --:--:-- 12.7M

컬은 strace 분석을 통해 4096바이트와 12288바이트를 SSD에 번갈아 쓰고, 이상하게도 CIFS에는 8192바이트를 쓰는 것으로 보입니다. 이 값을 얻기 위해서도 어떤 컨텍스트를 사용하는 것 같습니다. 컬은 102400바이트 수신 버퍼를 CIFS의 여러 8192 버퍼 쓰기로 분할합니다.