☰

네트워크 전송에 왜 그러한 차이가 있는지 이해하십니까?

tag-icon • tag-icon networking freebsd rsync performance file-transfer
네트워크 전송에 왜 그러한 차이가 있는지 이해하십니까?

요약:

네트워크 전송의 특별한 차이점을 이해할 수 없습니다.

  • 한 컴퓨터에서 다른 컴퓨터로 또는 그 반대의 동기화에 왜 그렇게 큰 차이가 있습니까?

반품:

  • 최대 네트워크 전송 속도가 약 110M/초이고 유사한 작업에 대한 로컬 디스크 속도가 약 200M/초인 경우(따라서 병목 현상이 없음) 두 시스템 간의 rsync가 이론적인 100M보다 빠른 이유는 무엇입니까? /비서?

세부 사항:

먼저 서버는

# 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를 수행하면 적어도 이 경우 예상되는 디스크 속도에 대한 아이디어를 얻을 수 있습니다.

FreeBSD 서버에서 바이너리 파일 test.bin, 732M을 사용하면 로컬 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

따라서 네트워크 연결(두 네트워크 카드 사이의 직선 Cat 7 케이블)은 약 110M/초라고 가정할 수 있습니다.

이제 혼란스러운 상황은 다음과 같습니다.

FreeBSD 서버에서 Mac Mini로 재동기화하면 약 50M/초의 전송 속도를 얻습니다.

# 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

내 두 가지 질문:

  • 한 컴퓨터에서 다른 컴퓨터로 또는 그 반대의 동기화에 왜 그렇게 큰 차이가 있습니까?

반품:

  • 최대 네트워크 전송 속도가 약 110M/초이고 유사한 작업에 대한 로컬 디스크 속도가 약 200M/초인 경우(따라서 병목 현상이 없음) 두 시스템 간의 rsync가 이론적인 100M보다 빠른 이유는 무엇입니까? /비서?

누군가 이것을 이해하는 데 도움을 주고 전송 속도를 높이는 방법에 대한 조언을 제공할 수 있습니까?

netcat업데이트: @dhag의 답변을 바탕으로 압축을 사용하지 않고 파일 복사를 시도했습니다 .

"서버"(푸시) 측:

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 사용(daemon 및 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의 아이디어를 확인시켜줍니다.

답변1

두 호스트의 서로 다른 컴퓨팅, 메모리, 캐시 또는 디스크 특성으로 인해 차이점이 설명된다고 추측할 수 있습니다.

  • CPU가 병목 현상을 일으킨다고 가정하면 느린 시스템이 더 느리게 전송하는 것이 합리적입니다(이는 암호화가 암호 해독보다 계산 집약적이라고 가정함). 이는 계산하기 쉬운 비밀번호로 전환하여 테스트할 수 있습니다( -c arcfourSSH 명령줄에 추가해 보세요. 이 경우 에 전달 --rsh="ssh -c arcfour") rsync.

  • 파일을 디스크에서 디스크로 직접 읽고 쓴다고 가정하면 디스크가 병목 현상을 일으킬 수 있습니다. 최신 컴퓨터에서는 100MBps 읽기 속도를 완벽하게 달성할 수 있지만 구형 컴퓨터나 노트북급 드라이브에서는 그렇지 않습니다. 컴퓨터에서는 그렇지 않습니다. (예를 들어 Mac Mini라고 생각합니다)에서 실행됩니다.

  • 운영 체제가 파일 시스템 캐시를 사용한다고 가정하면 상황은 더욱 복잡해질 수 있습니다.

    • 소스 파일이 RAM의 파일 시스템 캐시에 포함되어 있으면 읽기 속도가 100MBps보다 훨씬 빠를 수 있습니다.

    • 대상 시스템이 쓰기 캐싱을 적용하고 파일의 상당 부분을 RAM에 넣을 수 있는 경우(RAM이 테스트 파일보다 훨씬 크기 때문에 반드시 그래야 함) 쓰기가 완료되기 전에 완료된다고 주장할 수 있습니다. 실제로 도달된 디스크를 수행합니다(아마도 200MBps를 측정했음을 의미).

디스크와 캐시 알 수 없는 항목은 읽기 전에 파일 시스템 캐시를 플러시하여 테스트할 수 있습니다(이 작업을 수행하는 방법은 OS에 따라 다름). 그런 다음 파일 전송 속도는 최소한 디스크가 나타내는 속도만큼 느려집니다. 대신, 파일 cat file.bin >/dev/null을 보내기 전에 파일을 완전히 읽어(아마도 .

topCPU 문제가 있는지 추가로 조사하려면 전송이 진행되는 동안 실행하는 것이 좋습니다. rsyncOR ssh프로세스가 코어의 100%를 차지하는 경우 병목 현상이 발생합니다.

관련 정보