1Gbit LAN의 scp 성능

실제로 가정용 하드웨어에서 더 빠른 전송을 본 적이 없지만 서류상으로는 느리게 보입니다.

가능한 제한 요인을 배제하기 위해 몇 가지 실험을 시도해 볼 수 있습니다.

• /dev/zero에서 복사하여 원래 SSH 속도를 평가하십시오 /dev/null. 이는 HD 병목 현상을 제거합니다.

  ssh remote_host cat /dev/zero | pv > /dev/null
  

• HTTP와 같은 암호화되지 않은 다른 프로토콜을 확인하십시오. HTTP는 실제로 파일을 보내기 위해 헤더만 보냅니다. HTTP를 통해 대용량 파일을 보내는 것은 TCP 속도를 측정하는 합리적인 방법입니다.
• 트래픽이 라우터를 통과하지 않고 이더넷 스위치를 통과하도록 강제하고 있는지 확인하십시오. 예를 들어 컴퓨터에 공용 IP와 로컬 IP가 있는 경우 로컬 IP로/에서 scp를 수행합니다. 이는 일반적으로 홈 라우터가 CPU를 통해 WAN 트래픽을 처리해야 하므로 병목 현상이 발생하기 때문입니다. 두 시스템이 모두 LAN에 있더라도 공용 IP를 사용하면 패킷이 마치 WAN으로 가는 것처럼 CPU를 통과하게 됩니다.
• 이번에도 IPv4를 사용하겠습니다. 일부홈 라우터는 IPv6에서 이상한 동작을 합니다. 여기서 모든 로컬 트래픽을 라우터로 전달해야 합니다.
• 가능하다면 사용해 보세요기가비트 크로스오버 케이블라우터보다는요. 그러면 라우터가 제외됩니다.

1Gbit LAN의 일반적인 scp 전송 속도는 무엇입니까?

112MB/초

Micosoft Windows 팝업 또는 scpLinux에서와 마찬가지로 복사 속도는 초당 MB(메가바이트) 단위로 보고됩니다. 와 조합하지 않도록 주의해 주세요인터넷 속도초당 비트 수로 보고됩니다. 이제부터 표준화하자면, 복사 속도는 초당 비트(Mb/s)가 아닌 초당 바이트(MB/s) 단위여야 합니다.

이유:

• 초당 1GB = 초당 1000메가비트(mbps), 이는 광고된 네트워크 속도입니다.
• 1000Mbps / 8 = 125MB/s(초당 바이트)이론적 인최대 기대값.
• 1gpbs 유선 네트워크에서 견고한 112MB/초를 관찰했습니다(이보다 더 빠른 속도는 본 적이 없습니다). 계산된 효율성은 89.6%로 이는 합리적으로 보입니다.
  • 이것은 scp리눅스에서, 리눅스에서 리눅스 시스템까지 입니다.
  • 이는 Linux의 삼바 공유에서도 작동하며 Microsoft Windows의 복사 팝업에도 112MB/초가 보고됩니다.
  • 저는 지난 10년 동안 Windows 7 이상에서 이 현상을 관찰했으며 현재는 RHEL/CentOS 7에서도 이러한 현상을 관찰했습니다. 다른 트래픽이 있어서 전송을 수행 중입니다. 10달러짜리 Tigerdirect 4포트 유선 스위치도 있습니다.
• Samba를 통해 Windows에서 Linux로 전송할 때 동일한 ~10% 손실(125MB/초에서 112MB/초)이 관찰되었으므로 SSH가 너무 많은 오버헤드를 유발한다고 생각하지 않습니다. 내 생각에는 이 ~10% 손실(125MB/초에서 112MB/초까지)은 단지 TCP/IP 오버헤드일 뿐입니다. 나는 112MB/초보다 더 나은 것을 본 적이 없습니다.
• 때때로 전송 시작 ​​시 최대 115MB/초가 표시되며 110-115 사이에서 변동할 수 있지만 거의 항상 평균을 내며 112MB/초에 고정됩니다.
• Samba를 통한 Windows와 Linux 간, 그리고 Linux와 Linux 간 전송 속도는 두 시스템이 모두 처리 중인 경우에도 112MB/초로 유지될 수 있습니다 scp(예: 실제 산술 작업을 보여주는 60개 코어가 있는 64개 시스템에서 100%). 코어 서버).
• 참고: rhel 7.x를 실행하기 전, SLES 11.4 사용자였을 때 scp약 80MB/초를 계속 관찰했지만 이유는 알 수 없었지만 삼바를 통해 Windows로 이동하는 SLES 11.4 속도는 여전히 112MB/초였습니다.

당신도 잊지 마세요디스크 캐시. 예를 들어 서버에 128GB RAM이 있고 win10 PC에 32GB RAM이 있고 단일 10GB 파일을 7-zip tar로 압축하면 해당 10GB 단일 tar 파일은 모두 디스크가 아닌 RAM에 있을 수 있습니다. 따라서 이 경우 복사할 파일의 크기에 비해 RAM이 소진될 때까지 디스크 I/O로 인해 복사 전송 속도가 방해받지 않습니다.디스크 캐시따라잡을 수 없으면 디스크 I/O로 인해 일정한 112MB/초 복사 속도가 직접적으로 더 낮은 속도로 떨어지는 것을 볼 수 있습니다(회전 디스크와 SSD의 경우 더욱 그렇습니다). 112MB/초의 전송 속도는 1Gbps 유선 네트워크 및 관련 네트워크 하드웨어와 관계없이 다른 요인으로 인해 감소될 수 있습니다.

비교를 위해 제가 주장한 112MB/초는 896Mb/초입니다.

주목할 만한 점: 하위 폴더가 많고 [작은] 파일이 있는 폴더를 복사하는 것은 전송 속도를 크게 저하시키며 전송 속도를 112MB/초에서 초당 킬로바이트로 줄일 수 있으므로 속도를 전송하려면 이 작업을 수행하지 마십시오. 이 경우 파일 크기에 관계없이 먼저 모든 파일을 하나의 파일로 tar 또는 iso한 다음 해당 파일만 전송하고 대상에서 추출하는 것이 좋습니다.

2022년 1월 20일에 업데이트됨:

• 이것비밀번호그리고맥in은 /etc/ssh/sshd_configssh scp 속도에 중요한 역할을 할 수 있습니다.
• scp저는 1gbps보다 100배 빠른 100gbps HDR 인피니밴드 네트워크에서 수행된 테스트를 알고 있으며 두 RHEL 7.9 서버 사이에서 다음을 관찰했습니다.
  • Ciphers aes256-ctr,aes192-ctr,aes128-ctr나는 and 를 사용하는 것이 가장 안전하다고 생각 MACs hmac-sha2-512,hmac-sha2-256하지만 최고의 성능은 아닙니다.
    • 1gbps LAN에서 여전히 112MB/초를 얻으므로 2.9ghz xeon CPU가 아닌 LAN이 약한 링크입니다.
    • HDR 인피니밴드에서는 112 x 100 = 11,200MB/sec에 가까울 줄 알았는데, 최대 속도가 270MB/sec 정도라서 2.9ghz CPU로는 충분히 빠른 속도로 암호화를 할 수 없는 것 같습니다. 인피니밴드 네트워크의 요구 사항
    • 이는 테스트할 때 설정되고 Ciphers각각 MACs에 따라 다르므로 해당 항목을 사용하고 있다는 것을 알고 있습니다. 그렇지 않으면 지정된 첫 번째 비밀번호를 선택하고 그것이 작동하지 않으면 지정된 다음 비밀번호 또는 Mac이 시도될 것이라고 믿습니다.
    • 변경 Ciphers하고 (죄송하지만 잊어버렸습니다) MACs100gbps HDR 인피니밴드가 넘는 최대 속도는 약 700MB/초였습니다. 2.9GHz CPU는 선택한 SSH 암호화를 충분히 빠르게 처리할 수 없기 때문에 최대 700MB/초이며 11,200MB/초에 가깝지 않습니다. 이 경우 약한 링크는 HDR 인피니밴드 네트워크가 아닌 CPU입니다.sshd_configscp
    • 100gbps HDR 인피니밴드에서도 일부 Ciphers선택에 따라 속도가 60MB/초만큼 낮아질 수 있습니다.scp

다른 답변 외에도:

• 유선 연결이 모두 전이중(첫 번째 시스템에서 대상 시스템까지)인지 확인하세요.
• scp와 협상된 패킷 및 반환 패킷(ack 등)을 제외하고 다른 어떤 것도 1gps 링크를 사용하고 있지 않은지 확인하세요.
• 그리고 scp에 사용하는 암호화는 양쪽 끝의 CPU 성능을 압도하지 않습니다.
• 더 많은 패킷을 허용하고 더 적은 tcp 오버헤드 패킷을 허용하기 위해 더 큰 tcp 창(및 홉이 처리할 수 있는 다른 모든 것)이 있습니다.
• 파일이 아직 압축되지 않았고 두 CPU 모두를 압도하지 않는 경우 즉시 압축을 시도할 수 있습니다.

모든 것이 완전히 유리하다면 1gbps의 70-80%(초당 1024MB의 80%, 즉 초당 0.8*1024/8MB)에 가까워야 하지만 이는 다른 유형의 연결에 해를 끼칠 수 있습니다( 더 작은 패킷 크기 또는 더 높은 응답성과 더 짧은 대기 시간이 필요함)

마지막으로, USB 키(또는 드라이브)를 휴대하는 대역폭을 결코 과소평가하지 마십시오...(걷는 것도 건강상의 이점입니다)

38MB/s는 304Mbps와 동일하며, 이는 1Gbps 링크에서 꽤 좋은 전송 속도입니다.

- 전송 속도가 느린 경우 다음과 같은 몇 가지 요인이 관련되어 있습니다.

1- 서버 자체의 처리량.

2- 서버의 I/O 성능 [#iostat -xm 1 사용] 읽기/쓰기 활용도가 90%를 초과하는 디스크가 있는지 확인하세요.

3- 중간에 있는 L2 장치는 속도를 느리게 만들 수 있습니다. [이를 방지하려면 직접 연결해 보십시오].