概要:
ネットワーク転送特有の食い違いがわかりません。
また:
詳細:
まず第一に、サーバーは
# uname -a
FreeBSD das 10.1-RELEASE-p8 FreeBSD 10.1-RELEASE-p8 #25 d0fb866(releng/10.1): Thu Nov 13 07:57:26 EST 2014 root@bellicose:/usr/obj/root/pcbsd-build-10-STABLE/git/freebsd/ sys/GENERIC AMD64
クライアントは:
# uname -a
Darwin compute.internal 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
どちらのマシンにも16GBのRAMが搭載されています。
サーバー上でローカルrsyncを実行することにより、少なくともその状況では、ある種のディスク速度として何が期待できるかがわかります。
バイナリファイルtest.bin、732Mを使用すると、FreeBSDサーバーのローカルrsyncは約200M /秒を示します。
# rsync --stats -h test.bin copy.bin
[....]
sent 732.54M bytes received 35 bytes 209.30M bytes/sec
total size is 732.36M speedup is 1.00
それは約200M /秒です。
Mac miniクライアントでは、ほぼ70M /秒です。
# rsync --progress --stats -h test.bin copy.bin
test.bin
732.36M 100% 70.06MB/s 0:00:09 (xfr#1, to-chk=0/1)
[....]
sent 732.54M bytes received 35 bytes 69.77M bytes/sec
total size is 732.36M speedup is 1.00
ここで、iperf
を使用してネットワーク速度テストを実行します。
サーバー(FreeBSDサーバー):
# iperf -f M -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.5 port 5001 connected with 192.168.1.226 port 50757
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 3356 MBytes 112 MBytes/sec
クライアント(OS X mac mini)の場合:
# iperf -f M -M 9000 -c 192.168.1.5 -t 30 -w 80K
WARNING: attempt to set TCP maxmimum segment size to 9000 failed.
Setting the MSS may not be implemented on this OS.
------------------------------------------------------------
Client connecting to 192.168.1.5, TCP port 5001
TCP window size: 0.08 MByte (WARNING: requested 0.08 MByte)
------------------------------------------------------------
[ 4] local 192.168.1.226 port 50757 connected with 192.168.1.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 3356 MBytes 112 MBytes/sec
したがって、ネットワーク接続(2つのNIC間のストレートcat 7ケーブル)は約110M /秒であると想定できます。
さて、これは不可解な状況です:
FreeBSDサーバーからmacminiにrsyncすると、転送速度は約50 M /秒になります。
# rsync --progress --stats -h test.bin -e "ssh -l gsl" '192.168.1.226:/tmp/'
Password:
test.bin
732.36M 100% 57.10MB/s 0:00:12 (xfr#1, to-chk=0/1)
[....]
sent 732.45M bytes received 46 bytes 50.51M bytes/sec
total size is 732.36M speedup is 1.00
しかし、反対方向のrsyncは、はるかに低い転送速度、20M /秒を提供します。
# rsync --progress --stats -h test.bin -e "ssh -l gsl" '192.168.1.6:/tmp/'
test.bin
732.36M 100% 19.55MB/s 0:00:35 (xfr#1, to-chk=0/1)
[....]
sent 732.54M bytes received 35 bytes 20.07M bytes/sec
total size is 732.36M speedup is 1.00
私の2つの質問:
また:
誰かがこれを理解するのを手伝ってくれませんか、おそらく転送速度を改善する方法についていくつかのアドバイスを提供しますか?
更新:@dhagの回答に基づいて、netcat
を使用してファイルをコピーしようとしました。つまり、圧縮を使用しませんでした。
「サーバー」(プッシュ)側:
time cat test.bin | nc -l 2020
nc -l 2020 0.25s user 6.29s system 77% cpu 8.462 total
受信側(FreeBSD):
time nc 192.168.1.226 2020 > test.bin
nc 192.168.1.226 2020 > test.bin 0.09s user 4.00s system 62% cpu 6.560 total
私が間違っていなければ、それは732M/6.29s = 117M/secを意味するはずであり、これはiperf
統計を超えています。おそらくキャッシュの問題ですか?
更新2:暗号化をまったく行わずにrsyncを使用する(デーモンとrsync://プロトコルを使用する場合にのみ可能):
# rsync --progress --stats -h test.bin rsync://[email protected]/share ⏎
test.bin
732.36M 100% 112.23MB/s 0:00:06 (xfer#1, to-check=0/1)
[....]
sent 732.45M bytes received 38 bytes 112.69M bytes/sec
total size is 732.36M speedup is 1.00
これは@dhagのアイデアも裏付けています。
私が推測できるのは、2つのホストの計算、メモリ、キャッシュ、またはディスクの特性を変えることで不一致が説明されるという推測だけです。
CPUがボトルネックであると仮定すると、遅いマシンの送信が遅い場合はある程度意味があります(これは、暗号化が復号化よりも計算量が多いことを前提としています)。これは、計算が軽い暗号に切り替えることでテストできます(SSHコマンドラインに-c arcfour
を追加してみてください。この場合、--rsh="ssh -c arcfour"
をrsync
に渡します)。
ファイルがディスクから/ディスクに直接読み取られたり書き込まれたりしていると仮定すると、ディスクがボトルネックになる可能性があります。 100 MBpsの読み取り速度は、最近のコンピューターには十分に届きますが、古いコンピューターやラップトップクラスのドライブ(Mac Miniなど)で実行されているコンピューターには届きません。
オペレーティングシステムがファイルシステムキャッシュを使用しているとさらに想定すると、状況はさらに複雑になる可能性があります。
ソースファイルがファイルシステムキャッシュのRAMに含まれている場合、100MBpsよりもはるかに高速に読み取ることができます。
ターゲットシステムが書き込みキャッシュを適用し、ファイルの大部分をRAMに収めることができる場合(あなたの場合は、RAM isテストファイルよりもはるかに大きい)、実際にディスクに到達する前に書き込みが完了したと主張できます(これは、測定された200MBpsがそうであることを意味する可能性があります)。
不明なディスクとキャッシュは、読み取る前にファイルシステムキャッシュをフラッシュすることでテストできます(その方法はOSによって異なります)。その後、ファイルの送信は少なくともディスクの指示と同じくらい遅くなります。逆に、送信する前にファイルを完全に読み取ることにより(おそらく、cat file.bin >/dev/null
を使用して)、OSに影響を与えてファイルをキャッシュすることができます。
CPUが問題であるかどうかをさらに調査するには、転送の進行中にtop
を実行するのが理にかなっています。 rsync
またはssh
プロセスがコアの100%を使用している場合、それがボトルネックになります。