NFS를 통해 ZFS 데이터 세트를 내보내는 FreeBSD 스토리지 서버가 있지만 작은 파일 전송 성능이 허용 가능한 한도보다 낮습니다.
일부 배경 정보:
- 내보내기는 ZFS의 sharenfs 속성을 통하지 않고 /etc/exports를 통해 처리됩니다.
- 서버에는 128GB RAM 및 2x8 코어 CPU가 있습니다.
- NFS 서버는 192개의 스레드(vfs.nfsd.maxthreads: 192)를 사용하도록 구성됩니다.
- zpool은 SSD를 SLOG로 사용하는 4x4TB 10,000rpm SAS HDD를 지원합니다.
나는 항상 다음 매개변수를 사용하여 fio를 사용하여 시스템 성능을 테스트했습니다.
fio --ioengine=posixaio --bs=4k --directory=/mountpoint --refill_buffers --iodepth=1 --file_service_type=sequential --create_on_open=1 --fallocate=0 --unlink=1 --name=benchmark1 --rw=randwrite --numjobs=1 --nrfiles=500000 --filesize=20KB
시험현지의서버의 쓰기 속도는 약입니다.55MB/초.
동일한 워크로드 테스트NFS를 통해미미한 성능만 표시됩니다.6000KB/초. 클라이언트의 마운트 옵션은 다음과 같습니다.
myserver:/export/path on /mnt/tmp type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=clientip,local_lock=none,addr=serverip)
또한 네트워크 제한 사항을 확인하기 위해 단일 대용량 파일에 대한 순차적 쓰기를 테스트했습니다. 이 워크로드의 경우 123MB/s를 얻었는데, 이는 NFS 클라이언트가 기가비트 이더넷으로 제한되기 때문입니다.
또한 NFS(vfs.nfsd.async=1) 및 ZFS(zfs setsync=disabled /myzpool/dataset)에서 동기 쓰기가 비활성화된 상태에서 성능을 측정했습니다. 동기식 쓰기가 없으면 6000이 아닌 9000kB/s를 얻습니다. 이는 여전히 허용할 수 없는 수치입니다.
건물의 특정 라우터/스위치에 액세스할 수 없기 때문에 1500보다 큰 MTU를 사용할 수 없습니다.
답변1
- NFS 읽기 및 쓰기 버퍼 크기 늘리기
sudo mount -o remount,rsize=262144,wsize=262144 myserver:/export/path /mnt/tmp
- NFS 스레드 수 조정
sudo sysctl -w vfs.nfsd.maxthreads=256
- ZFS 설정 최적화
sudo zfs set recordsize=4K myzpool/dataset
답변2
3년 6개월 전 질문
async
및 sync
nfs 서버측 내보내기 옵션이 있으며 클라이언트는 을 전달합니다 mount
. 서버측에서는 또는 exportfs -s
인지 확인 하고 를 통해 조정합니다 . 예를 들어 파일은 다음과 같이 간단할 수 있습니다.sync
async
/etc/exports
/etc/exports
/data *(rw,async)
sync
사이에 편집한 다음 변경 사항을 async
실행 하고 확인하면 NFS에서 2배의 속도 차이가 즉시 관찰됩니다. 이것은 내가 찾은 가장 중요한 NFS 속도 향상입니다. 비동기식 데이터 손실 위험에 유의하세요.exportfs -arv
exportfs -s
클라이언트 측 에 rsize=1048576,wsize=1048576
표시되는 것은 mount
얻을 수 있는 최대값이라고 생각합니다.오늘, 이는 NFS 버전 4.1/4.2 및 RHEL 7.9 또는 8.8의 경우입니다. 누구든지 더 알고 있다면 알려주시기 바랍니다. 기본적으로 최대값(적어도 RHEL에서는)으로 설정되어 있으며 그 이유는 다음과 같습니다.
~에서https://www.ibm.com/docs/en/aix/7.2?topic=client-read-write-size-adjustment
최종 업데이트: 2023-03-24; 모든 제품/AIX/7.2 rsize 및 wsize 값을 줄이면 각 NFS 읽기 응답 및 쓰기 요청에 대해 더 짧은 패킷을 전송하여 혼잡한 네트워크에서 NFS 성능을 향상시킬 수 있습니다. 그러나 이로 인한 부작용은 네트워크를 통해 데이터를 전송하는 데 더 많은 패킷이 필요하므로 서버와 클라이언트의 전체 네트워크 트래픽과 CPU 사용률이 증가한다는 것입니다. NFS 파일 시스템이 고속 네트워크(예: 기가비트 이더넷)를 통해 마운트된 경우 읽기 및 쓰기 패킷 크기가 크면 NFS 파일 시스템 성능이 향상될 수 있습니다. NFS 버전 3 및 NFS 버전 4의 경우 네트워크 전송이 TCP인 경우 rsize 및 wsize 값을 최대 65536까지 설정할 수 있습니다. 기본값은 32768입니다. NFS 버전 2의 경우 rsize 및 wsize 옵션의 최대값은 8192이며 이는 기본값이기도 합니다.
rsize
나는 오늘날 wsize
기가비트와 더 나은 네트워크를 갖는 것이 그다지 가치가 없다고 생각합니다 . scp test.tar
단일 1GB 이상의 파일에서 110MB/초 이상의 일관된 속도를 얻을 수 있다면 참고로 네트워크 정체는 문제가 되지 않습니다. SSH를 통한 단일 파일 SCP(안전 복사본)는 약 112MB/초입니다. 1기가비트 네트워크에서 볼 수 있는 최고 속도입니다. 느린 속도에는 네트워크 정체뿐만 아니라 여러 가지 원인이 있을 수 있으므로 nfs 서버에 최소한의 CPU 및 I/O 로드가 있는지 확인하십시오.
내 경험에 따르면 RHEL 7.9에서는 NFS가 작동하지 않고 vers=4.2
RHEL 7.9에서만 작동하지만 vers=4.1
RHEL 8.8에서는 작동합니다. vers=4.2
따라서 특정 Linux 운영 체제 및 해당 NFS 버전에서 이러한 상황이 발생할 수 있습니다. 이 기사에서는 nfs 4.2가 4.1에 비해, nfs4가 nfs3에 비해 크게 향상된 점을 지적합니다. 저는 이러한 개선 사항이 NFS를 통해 초당 MB/초 단일 파일 복사 속도를 높이는 것보다 트래픽이 많은 환경에 더 적합하다고 생각합니다. 또한 선택할 수 있는 3가지 프로토콜은 udp
, tcp
, 및 입니다 rdma
. vers=rdma
CPU 주기를 절약할 수 있으므로 가장 좋지만 이를 지원하려면 네트워크 하드웨어(예: infiniband)가 필요합니다. RHEL 8.8 vers=3
과 RHEL 8.8 vers=4.2
사이에 단일 파일 NFS 속도 차이가 있는지 개인적으로 테스트하지 않았습니다 . proto=tcp
와 에는 차이가 없으나 proto=udp
원칙적으로 udp
는 보다 빨라야 합니다 udp
. RHEL 8에서 답을 찾는 데 문제가 있습니다 udp
.
클라이언트에서 사용fsc
파일 시스템 캐시, 설치 옵션을 사용하면 성능이 향상될 수 있습니다. '현재' fsc
를 '하는 것'의 선택사항으로 간주하여 확인 합니다 mount
. 그러나 제로 로드 및 단일 nfs 복제 속도 테스트의 경우 이것이 도움이 되지 않는다고 생각합니다.
rsync -P
저는 MB/초 속도 값을 얻기 위해 단일 파일을 복사 하곤 했습니다 .