NFS 복사가 SSH scp보다 절반 빠른 이유는 무엇입니까?

NFS 복사가 SSH scp보다 절반 빠른 이유는 무엇입니까?
  • RHEL 7.9 x86-64
  • Xeon CPU, 512GB RAM, Intel 네트워크 카드를 갖춘 고급형 Dell 서버
  • 나는 서버의 유일한 사용자이고 다른 작업 부하가 없습니다.
  • 시스코1Gbps 유선랜
  • data.tar약 50GB
  • /bkupNFS는 vers=4.1로 설치되고 동기화됩니까?
  • a가 scp data.tar backupserver:/bkup/계속 달린다112MB/초나는 이것을 5년 넘게 계속해서 보아왔고 그것이 옳다고 믿습니다.
  • a가 rsync -P data.tar /bkup계속 달린다55MB/초지속적으로 이것은 NFS를 통해 복제됩니다.
  • 두 개의 복사본을 동시에 실행하면 scp가 112에서 55로 감소하고 NFS를 통한 rsync가 55에서 35로 감소했습니다.
    • 하나의 복사가 완료되면 다른 복사 속도는 원래 속도로 돌아갑니다.

왜? NFS 속도를 높이는 방법은 무엇입니까?

답변1

주된 이유는 아마도 sync이 옵션을 사용하여 NFS 공유를 마운트하기 때문일 것입니다. 이론적으로 이는 서버가 갑자기 사라지거나 클라이언트의 연결이 예기치 않게 끊어지는 상황에서 데이터 보안을 향상시키지만 성능을 저하시킬 수도 있습니다.

마운트 옵션을 사용하는 것은 매번 .IOW를 호출하는 sync애플리케이션과 같습니다 . 클라이언트가 IO 요청을 제출할 때마다 다른 요청을 제출하기 전에 요청이 완료될 때까지 기다려야 합니다. 이는 다음 명령과 함께 사용되는 경우에도 데이터 쓰기 속도에 상당한 영향을 미칠 수 있습니다.fsync()write()현지의파일 시스템이지만 네트워크 파일 시스템이 이 작업을 수행할 수 있습니다.많은더 나쁜 것은 각 IO 요청 후 다음 요청이 이루어지기 전에 적어도 한 번의 전체 네트워크 왕복이 필요하기 때문입니다. 시간이 있으면 TFTP(SCP와 비교)를 사용하여 수백 MB 크기의 파일을 복사해 보면 이 효과를 직접 경험할 수 있습니다. TFTP는 이러한 유형의 동기화를 기본 수준의 프로토콜에 통합하고 다음과 같은 방식으로 구현합니다.다음 패킷이 전송되기 전에 각 개별 패킷을 확인해야 합니다.이므로 NFS가 보는 것보다 성능이 훨씬 낮을 수 있습니다.

자동으로 파일을 교체하고 복사본을 적절하게 처리하는 책임 있는 소프트웨어를 사용하는 경우 asyncNFS 모드로 안전하게 전환하여 이 문제를 피할 수 있습니다.

관련 정보