dd, cp, rsync 및 macOS Finder 사이의 쓰기 속도 차이가 SMB3 드라이브에있는 이유는 무엇입니까?

Tl; dr – 두 개의 다른 Mac 클라이언트에서 SMB 및 AFP를 통해 NAS에 60MB / 초의 제한된 쓰기 속도가 필요한 이유를 찾을 수 없습니다. 이에 비해 : 동일한 네트워크에있는 오래된 Windows 7 랩톱은 초당 100MB의 안정적인 속도를 씁니다.

이 질문을 처음으로 읽으면 업데이트 4 섹션으로 건너 뛰십시오 . rsync왜 우리가 (단일 파일을 위해!) 이해하지 못하더라도 저속의 주된 이유입니다.

원래 질문 : Mac OS 10.11.5 이상에서 속도 병목 현상 SMB3 / NAS 찾기

우리는 rsync --progress -a /localpath/test.file /nas/test.filemacOS와 Windows의 복사 정보를 통해 테스트했습니다 .

NAS는 현재 DSM 6.0.2 (5.x로도 테스트)를 실행하는 DS713 +이며 기가비트 이더넷 구성 요소와 새로운 이더넷 케이블 (최소 Cat5e) 만있는 RAID1에 2 개의 HGST Deskstar NAS SATA 4TB (HDN724040ALE640)가 있습니다.

Mac 클라이언트는 먼저 20MB / 초만 만들었습니다. 그러나 signing_required=no수정 사항 ( 여기에 설명 됨 )을 적용하면 SMB2 및 SMB3을 통해 쓰기 속도가 60MB / 초로 증가했습니다. AFP는 또한 약 60MB / 초를 제공합니다. 결과는 프로토콜 및 (Mac) 클라이언트에 따라 약 5MB / 초입니다.

우리가 이미 시도한 것 :

회로망

1. iperf3를 통한 네트워크 성능 테스트 결과 : 926 Mbit / s. 좋아 보인다
2. 이중 링크 집계 / 결합 네트워크 인터페이스를 시도했습니다. 변경 없음.
3. MTU가 6000 및 9000으로 증가했습니다. 변경 사항이 없습니다.
4. 모든 케이블을 점검하십시오. 좋은 상태에서 적어도 Cat5e는 괜찮습니다.

디스크

1. 확인 된 스마트 건강하게 보입니다.
2. 와 디스크에 직접 쓰기 속도를 테스트 dd if=/dev/zero of=write.test bs=256M count=4다양한으로 bs와 count설정 (8분의 128, 512M / 2, 1분의 1,024). 결과 : 약 120MB / s (블록 크기 / 카운트에 따라 다름)

SMB / AFP

1. SMB2, SMB3 및 AFP가 서로 벤치 마크되었습니다. 거의 같습니다.
   아래 업데이트를 참조하십시오 . macOS의 SMB 구현을 배제하기 위해 잘못된 방법을 사용했습니다. Windows의 SMB가 빠르기 때문에 macOS 10.11 및 10.12와 함께 제공되는 새로운 SMB 설정이 그 이유 일 수 있습니다.
2. 소켓 옵션을 포함하여 SMB 설정을 조정하려고했습니다 (이 지침에 따름 )
3. 지연된 ack 설정과 rsync --sockopts=TCP_NODELAY(의견) 의 다른 버전을 시도했습니다

쓰기 속도에는 큰 변화가 없습니다. 우리는 설정이 실제로로드되었고 올바른 smb.conf를 편집하고 있는지 두 번 확인했습니다 .

체계

1. CPU 및 RAM로드를 감시했습니다. 최대치가 없습니다. 전송 중 CPU 약 20 %, RAM 약 25 %
2. 거의 즉시 사용 가능한 설정에서 DSM 5.xx로 동일한 NAS를 테스트했습니다. 추가 소프트웨어가 설치되어 있지 않습니다. 참고 : 우리는 서로 다른 위치에 두 가지를 가지고 있습니다. Synology의 CloudSync를 통해 동기화됩니다. 같은 결과입니다.
3. 시스템 리소스를 끌어 올 수있는 불필요한 모든 것을 비활성화했습니다.

우리는 이것이 기본 설정이며 멋진 적응, 클라이언트 또는 네트워크 구성 요소가 아니라고 생각합니다. Synology가 게시 한 지표에 따르면 NAS는 40MB / s ~ 75MB / s 더 빠른 성능을 보여야합니다. 그러나 병목 현상을 찾을 수 없습니다.

클라이언트 / NAS

Mac 클라이언트는 MacPro 5,1 (10.12.3 (16D32)을 실행하는 표준 유선 NIC) 및 MacBookPro10,1 (10.11.6을 실행하는 Thunderbolt 네트워크 어댑터)으로 NAS에서 약 2m 거리에 있으며 동일하게 실행됩니다 테스트에서 Windows 노트북으로 기가비트 스위치.

우리는 서로 다른 위치에이 두 개의 NAS가 있으며 결과는 동일합니다. NAS는 공장 출하시 기본 설정입니다 (타사 소프트웨어도 설치되지 않음). Synology CloudSync를 통해 다른 NAS와 동기화하는 RAID1, EXT4 포맷 디스크 2 개만 있습니다. 스위치없이 NAS에 직접 연결하는 것과 동일한 결과를 얻었습니다.

중요 업데이트

macOS / OS X의 SMB 구현을 배제하는 데 사용 된 방법이 잘못되었습니다. 자체 버전의 SMB를 사용한다고 가정하고 가상 머신을 통해 테스트했지만 트래픽이 SMB 버전을 통해 실행되는 macOS로 전달됩니다.

Windows 랩톱을 사용하여 이제 평균 100MB / s를 달성 할 수있었습니다. 10.11 및 10.12와 함께 제공되는 SMB 구현 / 업데이트를 표시하면 성능이 저하 될 수 있습니다. 심지어 경우 signing_required에 설정됩니다 no.

누군가 업데이트로 변경되어 성능에 영향을 줄 수있는 추가 설정을 지적 할 수 있다면 좋을 것입니다.

업데이트 2 – 새로운 통찰력

AndrewHenle 은 Wireshark를 사용하여 더 많은 통찰력을 얻으 려면 트래픽을 자세히 조사해야한다는 의견을 지적했습니다.

따라서 sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpNAS에서 2 개의 테스트 파일 (512MB 및 1GB)을 전송했습니다. Wireshark로 덤프를 검사했습니다.

내가 찾은 것 :

1. NAS에서 SMB3가 활성화되어 있지만 OS X와 ​​Windows 모두 SMB2 를 사용하는 것 같습니다 (적어도 Wireshark에 따름).
2. OS X은 MTU 를 고수하는 것 같습니다 . 패킷은 1514 바이트로 더 많은 네트워크 오버 헤드 와 전송 된 패킷 (덤프에서 볼 수 있음)으로 이어집니다.
3. MTU가 허용하지 않아야하더라도 Windows는 최대 26334 바이트의 패킷 을 보내는 것처럼 보입니다 ( NAT 에서 1500으로 설정되어 있기 때문에 최대 설정은 9000입니다 (Synology도) 테스트에서 1500 설정을 사용합니다).
4. /etc/nsmb.conf 에 추가 smb_neg=smb3_only하여 macOS가 SMB3 을 사용하도록하려는 시도가 작동하지 않거나 최소한 더 빠른 전송으로 이어지지 않았습니다.
5. rsync --sockopts=TCP_NODELAYTCP 지연 ack 설정 (0-3)의 다양한 조합으로 실행 해도 아무런 영향이 없었습니다 (참고 : 기본 ack 설정 3으로 tcpdump를 실행했습니다).

512MB (test-2.file)를 복사하는 동안 2 개, 1024MB (test.file)를 복사하는 동안 2 개, .csv 파일로 4 개의 덤프를 만들었습니다. Wireshark 내보내기를 여기에서 다운로드 할 수 있습니다 (25.2MB). 공간을 절약하기 위해 압축되었으며 자체 설명이 가능합니다.

업데이트 3 – smbutil 출력

의 출력 smbutil statshares -a의 요청에 따라 harrymc 코멘트에.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

참고 사항 : 여기에 SIGNING_SUPPORTED있다고 true해도 구성의 설정이 작동하지 않는다는 의미는 아닙니다. 그러나 NAS에서만 지원됩니다. signing_required구성 에서 설정 을 변경하면 쓰기 속도에 영향을 미치는지 세 번 확인했습니다 (켜져 있으면 최대 20MB / s, 꺼져 있으면 최대 60MB / s).

업데이트 4 – 삼바 전쟁 : 새로운 희망

다소 당황 스럽지만 여기서 가장 큰 문제는 다시 측정하는 것 같습니다.

rsync --progress -a약 30MB / s의 쓰기 속도 가 나옵니다 . ddSMB 공유에 직접 쓰고 사용 time cp /local/test.file /NAS/test.file하는 속도는 약 85-90MB / s로 빠르며 복사하는 가장 빠른 방법은 약 100MB / s의 macOS Finder입니다 (이는 측정하기가 가장 어려운 방법이기도합니다). 타이밍 또는 속도 표시기 – 누가 필요합니까? 스톱워치를 사용하여 먼저 1GB 파일을 복사 한 다음 10GB 파일을 복사하여 측정했습니다.

이 질문의 마지막 업데이트 이후 우리가 시도한 것.

1. Mac 클라이언트에서 Mac 클라이언트로 복사하십시오. 둘 다 SSD가 있습니다 (MacPro는 250MB / s의 디스크를 소유하고 MacBook Pro는 300MB / s의 디스크를 기록합니다). 결과 : ddMacBook Pro에서 MacPro ( rsync25MB / s)로 쓰기를 통해 빈약 한 65MB / s. 우리가 rsync에 질문하기 시작한 순간은 25MB / s를 보았습니다. 여전히 65MB / s가 매우 느립니다. 따라서 macOS의 SMB 구현은… 의심 스럽습니다.
2. dd와 cp로 다른 ack 설정을 시도했지만 운이 없습니다.
3. 마지막으로 사용 가능한 모든 nsmb.conf 옵션을 나열하는 방법을 찾았습니다. 간단 man nsmb.conf합니다. 주의 온라인 버전 이 오래되었습니다!

그래서 몇 가지 설정을 더 시도했습니다.

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

참고 : smb_neg=smb3_only이미 예상 한대로 올바른 설정이 아닙니다. protocol_vers_map=4유효한 동등한 것이어야합니다.

어쨌든 이러한 설정 중 어느 것도 우리에게 아무런 변화가 없었습니다.

한눈에 새로운 질문

1. rsync가 하나의 파일을 복사하는 데 비용이 많이 드는 이유는 무엇입니까? 동기화 / 비교할 것이 많지 않습니다. tcpdump는 가능한 오버 헤드를 나타내지 않습니다.

2. 왜 dd와 cp에 따라 SMB 공유에 전송할 때 파인더 맥 OS보다 느리다? Finder로 복사 할 때 TCP 통신에 대한 승인이 상당히 적습니다. (다시 : ack 설정은 예를 들어 delayed_ack=1우리에게 아무런 영향을 미치지 않았습니다.)

3. Windows가 MTU를 무시하고 왜 TCP 패킷을 크게 전송하여 더 적은 수의 TCP 패킷을 전송하여 macOS를 통해 가능한 모든 것에 비해 최고의 성능을 제공하는 것입니까?

이것이 macOS의 패킷 모양입니다 (일정 1514).

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

그리고 이것은 Windows에서 제공됩니다 (크기가 다양한 최대 26334).

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

여기에서 전체 .csv (25.2MB)를 다운로드 할 수 있으며 파일 이름에 복사 된 내용 (OS, 전송 방법 및 파일 크기)이 설명되어 있습니다.

1. 비슷한 질문이지만 흥미로운 답변이 있습니다. 주석 5에서 특히이 스레드를 확인할 수 있습니까 : https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

여기 "Peter van Hooft"가 인용됩니다. 그래도 나는 무엇을 어떤 Linux 기반으로 테스트하는지 확실하지 않습니다. rsync 버전도 있습니다. 그러나 : 1. 성능 향상을 위해 가능한 경우 --sparse 플래그 를 사용하려고 합니다. 2. NFS 프로토콜을 테스트했지만 동일한 속도 문제를 겪었으므로 IT는 프로토콜 (SMB2 / 3, AFP 등) 이유가 아닐 수 있습니다.

rsync를 사용하여 10Gb 링크를 통한 NFS3 마운트를 사용하여 한 파일 서버에서 다른 파일 서버로 데이터를 복사합니다 . 우리는 흐름이 완만 발견 버퍼 크기 (빠른 테스트로하는) 성능이 향상됩니다. --sparse를 사용하면 2MBps에서 100MBps까지 50 배로 성능이 향상됩니다.

2. rsync 성능에 대한 또 다른 흥미로운 검사가 있습니다. https://lwn.net/Articles/400489/

LWN.net은 2010 년에 게시 된 기사조차도 성능 문제가 커널과 관련이있을 수 있으며 NAS 또는 MacOS에서는 변경할 수 없다는 결론을 내 렸습니다. 그러나이 기사에서는 커널 문제가 체크섬 (나의 추측) 계산으로 인해 발생할 수 있다고 생각합니다 .

한가지 분명하다 : Mythtv 시스템에서 커널을 업그레이드해야한다. 일반적으로 2.6.34 및 2.6.35-rc3 커널은 이전 2.6.27 커널보다 더 나은 성능을 제공합니다. 그러나, 어설프게하지 않더라도 rsync는 여전히 100MiB / s 이상으로 복사하는 간단한 cp를 이길 수 없습니다. 실제로 rsync는 간단한 로컬 복사본을 위해 많은 CPU 성능을 필요로합니다. 가장 높은 주파수에서 cp는 rsync의 70 + 55 초와 비교하여 CPU 시간이 0.34 + 20.95 초만 필요했습니다.

또한 의견 코멘트에는 다음이 있습니다.

rsync는 항상 파일이 전송 될 때 생성 되는 전체 파일 체크섬 을 확인하여 전송 된 각 파일이 수신 측에서 올바르게 재구성되었는지 확인합니다.

업데이트 1 : 내 실수,이 설명은 --checksum입니다. 여기에서 확인하십시오 : [--checksum 옵션 설명 개선] PS, 2 개 이상의 링크를 게시 할만한 명성이 없습니다.

하지만 rsync 맨 페이지에서 동일한 설명을 찾을 수 없으므로 누군가 굵게 아래에 대해 이야기하고 있다고 생각합니다.

Rsync는 "빠른 검사"알고리즘 (기본적으로) 을 사용하여 크기 나 마지막 수정 시간에 변경된 파일을 찾는 파일을 찾습니다. 다른 보존 속성 (옵션에서 요청한대로)의 모든 변경 사항은 파일의 데이터를 업데이트 할 필요가 없음을 신속하게 확인할 때 대상 파일에서 직접 변경됩니다.

따라서 cp / tar / cat과 비교할 때 rsync를 사용하여 작거나 큰 파일을 복사하면 성능 문제가 발생할 수 있습니다. 그러나 rsync의 소스 코드를 읽을 수 없기 때문에 이것이 궁극적 인 이유임을 확인할 수 없습니다.

내 생각은 계속 확인하는 것입니다.

1. 어떤 rsync 버전이 테스트에 사용됩니까? 최신 버전으로 업데이트 할 수 있습니까?
2. --stats와 --v를 --debug = FLAGS와 함께 사용할 때 어떤 출력을 보자

깃발

--stats rsync에게 파일 전송에 대한 자세한 통계 세트를 인쇄하도록 지시하여 rsync 알고리즘이 데이터에 얼마나 효과적인지 알 수 있습니다.

--debug = FLAGS이 옵션을 사용하면보고자하는 디버그 출력을 세밀하게 제어 할 수 있습니다. 개별 플래그 이름 뒤에는 레벨 번호가 올 수 있습니다. 0은 해당 출력을 묵음, 1은 기본 출력 레벨이며 더 높은 숫자는 해당 플래그의 출력을 높이는 것입니다 (높은 레벨을 지원하는 경우). --debug = help를 사용하여 사용 가능한 모든 플래그 이름 , 출력 내용 및 자세한 레벨이 증가 할 때마다 추가되는 플래그 이름을 확인하십시오.

마지막으로, 나는이 추가 게시물을 읽고 더 많은 지식을 얻는 것이 좋습니다.
"네트워크를 통해 많은 양의 데이터를 전송하는 방법" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh는 내가 올바르게 기억하면 연결 smb가 암호화하지 않습니다. 파일이 하나 인 경우 한 시스템이 해당 파일을 읽을 수 있고 다른 시스템은 읽을 수 없습니다. 또한 1514 이상의 MTU를 사용하려면 "거인"/ "점보 프레임"패킷을 활성화해야합니다. 패킷을 추가로 줄여야한다는 사실은 패킷을 "재 포장"하는 오버 헤드가 있음을 의미 할 수 있습니다. 두 번째로 주목할 점은 "거인"/ "점보 프레임"을 양쪽 ​​끝과 양쪽 모두에서 활성화해야한다는 것입니다.

1514는 일반적인 이더넷 프레임입니다. OS / 응용 프로그램에 따라 6k-9k 프레임을 자이언트 또는 "점보 프레임"이라고합니다.

내 nas (VM 중 하나는 VM이있는 PC는 NAS 임)와 sftp가있는 내 스테이션 (pc) (sshfs 사용) [거인은 활성화되지 않음] 사이의 평균 80MB / s이며 그 사이에있는 장치는 2011 년 Microtik입니다 tru 스위치 칩만 해당)

MTU는 두 지점간에 협상되며 경로를 따라 서로 다른 용량의 여러 MTU가있을 수 있으며 MTU는 사용 가능한 최저 수준이됩니다.

편집 : SMB는 파일 전송에 매우 효율적이지 않습니다.