CIFSマウントでのwgetダウンロード速度が悪すぎます。ローカルにダウンロードしてcpと共有します。

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%でほぼいっぱいです。

CIFS wget CPU使用率

SSD wget CPU使用率

N+2 編集:今日は新しいハードウェアを手に入れました。 I211の代わりにI210 NICSもあります。これで、送受信キューの数を2倍にする必要があります。今はハードウェアを設定しています。

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バッファ書き込みに分割します。

答え1

私の設定にもこの問題があります。

Artem S.Tashkinovが提案したようにカールwgetの代わりに奇跡が起こります。私は最高速度でcif fsに書き込みます。 ✅

だから得るそしてアクセルたとえば、各バイト書き込みの間にフラッシュできる書き込みメソッドがファイルシステムに存在する可能性があるため、非効率的なネットワーク呼び出しの往復が生成されます(これは推測です)。

編集する:

この投稿を見てからいくつかのクイック検索をして発見しました。このスレッド

wgetにバッファリングシステムを追加する方法を説明します。私が使用するコマンドは

wget https://abigfile.iso -O- | buffer -s 512k -b 10 -p 85 > ./outfile.iso

また、このコマンドを使用すると、ダウンロードにフル帯域幅を使用できます。

私は今axelとwgetにデフォルトの小さなバッファがあると思います。なし(08/23基準)公開されたオプションにより、ユーザーはそれを変更できます。

関連情報