디스크 없는 시스템 설정이 두 개 있습니다. 이들은 모두 /home
동일한 서버의 마운트 디렉터리에서 나옵니다. 내보내기는 /home
Kerberos를 사용하여 문제 없이 작동하지만 성능에만 문제가 있는 것 같습니다. 모든 것이 동일한 케이블, 동일한 포트 구성 등을 사용하여 동일한 스위치에 연결됩니다. fstab
NFSv3과 NFSv4의 하위 집합이 다르기 때문에 설치 옵션이 약간 다릅니다.
약 25000개의 작은 파일(10kb 미만)을 /dev/shm/dir
각 클라이언트에 복사한 다음(서버와 클라이언트 간에 물리적으로 복사) rsync
이를 내 파일로 편집했습니다 ~
. 시간 차이는 약 15초였습니다. 왜 이런 일이 일어나는지 아는 사람이 있나요? NFSv4는 NFSv3보다 느립니까? 아니면 이 상황을 개선할 수 있는 특정 옵션이 있습니까? 도움을 주시면 정말 감사하겠습니다.
섬기는 사람
Debian "Bullseye", 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12)
NFS Export: /home 1.2.3.4/24(rw,async,no_subtree_check,sec=krb5:krb5i:krb5p)
# cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2
NFSv3을 사용하는 클라이언트 1
Debian "Bullseye", 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12)
# cat /etc/fstab
5.6.7.8:/home /home nfs rw,nodev,nosuid,hard,nolock,proto=tcp,nfsvers=3,sec=krb5 0 0
# findmnt
└─/home 5.6.7.8:/home nfs rw,nosuid,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=krb5,mountvers=3,mountport=40531,mountproto=tcp,local_lock=all
[client1] /dev/shm ➽ $ time rsync --links -r dir ~/dir1/
real 0m33,835s
user 0m0,582s
sys 0m6,062s
NFSv4.2를 사용하는 클라이언트 2
Debian "Bookworm", 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08)
# cat /etc/fstab
5.6.7.8:/home /home nfs rw,nodev,nosuid,ac,hard,proto=tcp,nfsvers=4.2,sec=krb5 0 0
# findmnt
└─/home 5.6.7.8:/home nfs4 rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,local_lock=none
[client2] /dev/shm ➽ $ time rsync --links -r dir ~/dir2/
real 0m48,155s
user 0m0,671s
sys 0m8,472s
편집: 9월 10일, 11:53
나는 통계를 읽었습니다 mountstats
. 또한 암호화가 처리량에 눈에 띄는 영향을 미치지 않는 것으로 나타났습니다 /home
. krb5p
방법론:
cat /proc/self/mountstats > /dev/shm/mountstats.start
- 달리기
rsync
mountstats mountstats --since /dev/shm/mountstats.start > nfs.mountstats.rsync.txt
mountstats iostat --since /dev/shm/mountstats.start > nfs.iostat.rsync.txt
NFSv3 client
ops/s rpc bklog
1874.078 0.000
read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
0.000 0.000 0.000 0 (0.0%) 0.000 0.000
write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
159.312 228.017 1.431 0 (0.0%) 0.720 0.843
NFSv4.2 client
ops/s rpc bklog
1436.392 0.000
read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) avg queue (ms) errors
0.025 0.062 2.449 0 (0.0%) 0.500 0.500 0.000 0 (0.0%)
write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) avg queue (ms) errors
129.076 201.433 1.561 0 (0.0%) 0.322 0.407 0.061 0 (0.0%)
편집: 9월 11일, 9:33
Debian "Bookworm" 12를 사용하여 추가 NFS 서버를 만들고 nvme 드라이브에 간단한 비Kerberized NFS 4.2 공유를 만들었습니다. 차이는 없으며 rsync
약 50초 정도 소요됩니다. 그래서 이것은아니요분명히 OS/커널/하드웨어 문제이지만 NFS와 관련되어 있습니다.
그런 다음 NFSv3을 사용하여 동일한 공유를 마운트했는데, 이는 rsync
약 26초가 걸렸습니다.그렇다면 NFSv4는 NFSv3에 비해 정말 느린가요??
편집: 9월 11일 18:29 (@ron의 답변에 대한 응답)
당신이 시스템(nfs 서버 및 nfs 클라이언트)의 유일한 다른 사람입니까?
현재 두 개의 설정이 있는데 하나는 다른 컴퓨터와 공유되지만 테스트 당시에는 공유를 사용하는 사람이 거의 없었고 I/O는 유휴 수준이었습니다. 두 번째 설정은 비공개입니다.
다른 네트워크 부하가 있습니까?
"유휴" 트래픽만 테스트하세요. 10Gbps 코어 파이버 업링크가 있고 워크스테이션에는 1Gbps 업링크가 있습니다. HP 엔터프라이즈 스위치. 네트워크 문제를 최소화하기 위해(또한 이 트래픽을 라우터를 통해 푸시하고 싶지 않음) NFS 서버와 모든 워크스테이션은 동일한 서브넷에 있고 동일한 스위치에 연결됩니다. 이것은 새로운 설정이 아니며 NFSv3에서 NFSv4로 전환하려고 합니다.
네트워크를 설정하고 스위치/라우터를 완전히 제어할 수 있습니다. > 또는 한 번도 만난 적이 없는 사람이 모두 설정하고 관리합니다.
하드웨어를 제어하고 설정합니다.
또한 Kerberos 보안 설정을 사용하면 성능을 향상시키기 위해 보안을 추가할 수도 있습니다. 아무도 그런 말을 한 적이 없습니다.
Kerberos가 적용된 마운트와 Kerberos가 적용되지 않은 마운트를 모두 시도했는데 둘 다 NFSv3이 NFSv4보다 빠르다는 것을 나타냅니다.
나는 넘어졌다이것은 우연입니다. 우리는 거의 200개의 디스크 없는 부팅 워크스테이션을 보유하고 있습니다. 전반적으로 모든 것이 잘 작동합니다. 올해 NFSv4를 사용하여 새 시스템(최신 Debian 12)을 설정할 때 압축이 풀린 아카이브(많은 작은 파일, 아이콘, 일부 심볼릭 링크 포함)를 복사하는 데 시간이 약간 길다는 것을 알았습니다. 그래서 복사가 필요한지 확인해 보기로 했어요~에 대한(그래요아니요작은 변경 사항에 주의) 이전 NFSv3 시스템에서는 NFSv4에서는 시간이 더 오래 걸리는 것으로 나타났습니다. 저는 항상 TCP( )를 사용하여 Kerberos를 사용하거나 사용하지 않고 시도해 보았습니다 proto=tcp
.
방정식에는 변수가 많다고 생각하므로 Kerberos 등은 잠시 잊어버리도록 하겠습니다. 저는 다음과 같은 개인 시스템을 설정했습니다.
- Kerberos 없음
- 서버는 NVME 드라이브에 있는 단일 디렉터리를 내보냅니다.
- 클라이언트는 kerberos 없이 내보낸 디렉터리를 마운트합니다.
nfsvers=4.2,ac,rw
- 클라이언트와 서버 모두 1Gbps 이더넷을 갖춘 Dell 워크스테이션입니다.
- 클라이언트와 서버 모두 동일한 스위치에 연결되어 있고 동일한 서브넷(VLAN)에 있으므로 네트워크 트래픽에 라우터가 없습니다.
- 클라이언트와 서버 모두 동일한 운영 체제와 커널을 실행합니다: Debian 12 "Bookworm"
6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07)
그런 다음 나는 다음과 같은 간단한 테스트를 여러 번 수행했습니다.
- 복사할 파일이 포함된 아카이브를 가져옵니다
/dev/shm
. 이것:https://github.com/vinceliuice/Tela-icon-theme/archive/refs/tags/2023-06-25.tar.gz - 아카이브 압축을 푼다
rsync --links -r unpacked_archive /path/to/mounted/nfsshare/dest
약 50초 정도 걸렸습니다.
- 그런 다음 NFSv3를 사용하여 공유를 다시 마운트했습니다.
- 그리고 같은 테스트를 반복합니다
약 30초 정도 걸렸습니다.
따라서 동일한 머신, 동일한 네트워크, Kerberos 없음, 동일한 시스템, 동일한 커널, NFS 버전만 다릅니다. 그리고 큰 차이가 있습니다. 재미있었고 무슨 일이 일어나고 있는지 알고 싶었고 뭔가를 배우고 싶었습니다. 현시점에서는 이러한 모든 요소를 고려하면 NFSv4가 느리다는 것 외에는 답이 없습니다. NFSv4 성능에 대한 아주 오래된 기사를 찾았고 그 이후로 많은 변화가 있을 것으로 예상했지만 이 경우에는 그렇지 않을 수도 있습니까?
NFSv4 파일 생성 속도는 실제로 NFSv3 파일 생성 속도의 절반 정도이며, https://www.linux.com/news/benchmarking-nfsv3-vs-nfsv4-file-Operation-performance/
제 경우에는 마운트된 NFS 공유에 작은 파일을 많이 생성했습니다.
많은 작은 파일을 시도해 보는 것이 왜 중요한가요? 학생들은 Git을 사용하기 때문에 대규모 IDE는 작은 파일을 많이, 때로는 수백 개 이상 생성하고, 학생들은 많은 소프트웨어를 컴파일하는 등의 작업을 수행합니다. 그리고 많은 학생이 있습니다. 수천 개의 작은 파일이 있습니다.
9월 12일 10시 55분 (테스트 결과)
대용량 파일을 전송하는 데 문제가 발생한 적이 없으며 매일 수행하며 속도는 최대 업스트림 속도에 가깝습니다. 하지만 어쨌든 대용량 파일로 복사 테스트를 해봤습니다. /nvme
NFS 공유입니다.
/dev/shm ➽ $ dd status=progress if=/dev/zero of=test.file bs=1M count=6000
3488612352 bytes (3,5 GB, 3,2 GiB) copied, 1 s, 3,5 GB/s
6000+0 records in
6000+0 records out
6291456000 bytes (6,3 GB, 5,9 GiB) copied, 1,80348 s, 3,5 GB/s
[orange14] /dev/shm ➽ $ rsync --verbose --progress test.file /nvme/test.file
sent 6.292.992.082 bytes received 35 bytes 105.764.573,39 bytes/sec
total size is 6.291.456.000 speedup is 1,00
저도 몇 장 복사해서 scp
시간을 기록해 봤습니다.
[orange14] /dev/shm ➽ $ time scp test.file /nvme/test.file6
real 0m59,463s
real 0m59,700s
real 0m59,780s
약 105MB/s.
더 큰 메모리가 있는 시스템에서 테스트하는 경우 현재 이 목적에 사용할 수 있는 예비 서버가 없으며 현재 NFS에 대한 자세한 테스트를 수행할 시간이 많지 않습니다. 작은 파일에 대해 몇 가지 테스트를 반복하고 플롯했습니다. 서버와 클라이언트는 모두 Dell 워크스테이션, 동일한 운영 체제, 동일한 커널, Kerberos 없음, 단순한 NFSv3 또는 NFSv4.2 공유입니다. 같은 파일을 계속해서 복사했습니다.
친절한 안부
답변1
... 25,000개의 작은 파일
나의 첫 번째 성향은 일반적인 시스템 오버헤드와 파일 시스템 I/O입니다.디스크tmpfs에서 실행 중이므로 I/O는 아마도 Kerberos 보안 설정과 함께 가변성의 원인입니다.보안을 추가하면 성능이 향상된다고 말한 사람은 아무도 없습니다.
하지만, 실행하지 않는 한실시간 커널변동성을 제외하려면 약간의 변동성이 표시됩니다. 그런 다음 NFS v3과 v4 또는 기타 NFS 매개변수가 대부분 부정확할 수 있으므로 자신의 꼬리를 쫓게 될 것이라고 결론을 내립니다.
당신이 언급하지 않은 다른 중요한 것들이 많이 있습니다 -
- 당신이 시스템(nfs 서버 및 nfs 클라이언트)의 유일한 다른 사람입니까?
- 다른 네트워크 부하가 있습니까?
- 어떤 네트워크 레이아웃과 하드웨어가 관련되어 있으며 가능한 영향이 있습니까? 네트워크를 설정하고 스위치/라우터를 완전히 제어할 수 있습니다. 또는 한 번도 만난 적이 없는 사람이 모두 설정하고 관리합니다.
나는 데비안에 익숙하지 않지만 RHEL에는동조기본 구성 파일은 다음과 같습니다.처리량 성능그중에는* 다양한 일반 서버 작업 부하에 걸쳐 뛰어난 성능을 제공하는 광범위하게 적용 가능한 조정 사항이 있습니다. * 도움이 될 수 있는 기타 구성 파일은 다음과 같습니다.대기 시간 성능,네트워크 지연, 또는네트워크 처리량. 이것이 제가 말씀드릴 수 있는 최선의 내용입니다. 더 자세히 조사해 보아야 합니다.https://www.redhat.com/sysadmin/linux-tuned-tuning-profiles
https://www.redhat.com/sysadmin/linux-tuned-tuning-profiles
당신은 말한다파일 25,000개(각각 10kb 미만). 총 약 250MB입니다. 제 생각에는 두 시스템이 하드웨어와 OS 설정 및 구성이 동일하지 않는 한 참조로 사용하기에는 너무 적습니다. 유일한 변수는 NFS v3 대 v4.0/4.1/4.2입니다. 그렇지 않으면 숫자로 당신의 꼬리를 쫓을 것입니다.
어쨌든, 마운트 프로토콜에 대해 NFS v3과 v4.0/4.1/4.2 및 udp와 tcp 사이에 성능 차이가 있는지 이해하려고 합니다. Xeon 24 코어 CPU와 768GB RAM을 갖춘 동일한 서버에서 RHEL 8.8을 사용하여 test.tar
약 25GB 크기의 파일을 복사하여 속도를 보여주고 디스크 I/O를 제외하는 rsync -P
데 tmpfs
도움을 주었지만 성능은 보이지 않았습니다. InfiniBand에서는 차이가 100gbps 이상입니다. , Mellanox 스위치를 사용하여 실험실 환경의 내 서버와 네트워크에서만 사용합니다. 몇 분 동안 복사한 후에는 모든 다른 NFS 매개변수가 관찰된 최대값 약 490MB/s 및 평균 약 470MB/s에 도달할 수 있습니다. 흥미롭게도 재부팅 후 첫 번째 복사본의 속도는 340MB만큼 느려질 수 있습니다. /s이지만 후속 복사본에서는 490MB/s로 최고치를 기록합니다. 여기서는 클러스터 설정에서 UDP와 v4.2 및 TCP와 함께 NFS v3을 사용해야 하는지 이해하기 위해 시간을 할애하고 싶습니다. proto=rdma
내 파일 복사본 중 하나가 TCP보다 5%~15% 더 빠르다는 사실을 발견했습니다. ;그래서 proto=rdma
최고네요. 1gbps 네트워크에서 내가 찾은 것은 nfs 서버 측에 있었고 속도가 크게 증가하는 async
대신 sync
인피니밴드에서는 효과가 없었습니다. NFS 매개변수의 일부 조합으로 인해 NFS v4.2가 v3보다 느려지는지 여부는 아마도 모르겠습니다. 하지만 물어보세요NFS v4.2는 v3보다 느립니까? 내가 이해하려고 하는 바에 따르면, 나는 아니오라고 말하고 싶습니다. 그리고 v3이 포함된 nfs v.2의 문서화된 개선 사항에 따르면 더 좋을 것입니다. pnfs
nfs v4도 지원됩니다.
또한 Infiniband와 NFS 측면에서 RHEL 7.9와 8.8 사이에는 상당한 속도 차이가 있다는 것을 발견했습니다. scp
RHEL 8.8에서는 1.0GB/초, RHEL 7.9에서는 600MB/초 미만에 도달하며 NFS에도 비슷한 차이가 있습니다. , 그중에서도 nfs-utils-1.3
rhel8.8에 비해 RHEL 8.8이 더 좋습니다. nfs-utils-2.whatever
최신 NFS 버전과 다른 OS를 실행하는 경우 데비안, 너드 또는 불스아이에 대해 잘 모릅니다. 제 생각에는 모두 중요합니다. 관리자가 구성이 올바른지 또는 문제가 있는지 이해하기 위해 확인해야 하는 데이터로 더 많은 NFS v4.2 성능 데이터가 게시되는 것을 보고 싶습니다.
NFS 속도 테스트의 첫 번째 단계에 대한 권장 사항:
- 1gbps 네트워크의 경우 파일을 만드세요
test.tar
. 2GB에서 10GB 사이로 설정하겠습니다.dd if=dev/zero of=test.tar bs=10G count=1
du -sh test.tar
rsync -P <source> <destination>
nfs_server 및 nfs_client에서 `test.tar를 복사하는 데 사용됩니다 .- 보고된 최대 속도를 준수하십시오.
- 완료 후 평균 보고 속도 관찰
- 두 번째 및 후속 호출을 관찰하십시오. 첫 번째 호출은 NFS와 관련 없는 최초의 오버헤드일 수 있습니다.이후 3번 이상 시도해야 합니다.시대의 발전을 보장합니다.
mount -t tmpfs -o size=100G tmpfs /scratch
nfs_server 및 nfs_client에서 작업을 수행하고test.tar
각 시스템에서 복제할 때 해당 위치에 배치하여 디스크 I/O 문제를 해결하는 데 도움을 줍니다. 따라서 크기는 128GB 이상의 RAM을 갖춘 서버라고 가정합니다. 당신은 분명히 이 tmpfs가 당신의 것보다 더 커지기를 원합니다test.tar
.exportfs -s
서버 측에서 동기 또는 비동기와 같은 내보내기 옵션에 주의하세요.mount
vers
nfs 및proto
of 와 같은 클라이언트 측 마운트 옵션mountproto
에 주의하세요.udp|tcp|rdma
- 하나에 주목하세요
scp
안전 사본온전성 검사로 두 시스템 간에 SSH를 통해 전송하는 경우 전송 속도는 1gbps 네트워크에서 약 112MB/초여야 합니다. 그렇지 않은 경우 약 105MB/초보다 훨씬 낮지만 다른 이유로는 속도가 느려지지 않습니다. 문제가 발생하므로 NFS가 100% 속도로 실행될 것이라고 기대하지 마십시오. 10GB test.tar는 112MB/초로 실행하는 데 89초가 소요됩니다. 나는 또한 Windows 10 컴퓨터에 대한 삼바 복사를 통해 이것을 보았습니다. - 이 모든 것은 사과와 사과를 쉽게 비교할 수 있도록 하기 위한 것이며, 여기부터 2단계에서는 더 큰 파일과 작은 파일이 많이 있는 시나리오를 배치합니다.