동일한 호스트에서 실행되는 두 Xen 가상 머신(클라이언트 및 서버) 간의 nfs 성능 저하 원인을 확인하려고 합니다. 특히, 클라이언트에서 1GB 파일을 순차적으로 읽을 수 있는 속도는 두 VM 간의 측정된 네트워크 연결 속도와 서버에서 직접 파일을 읽는 측정된 속도를 기반으로 예상되는 것보다 훨씬 느립니다. VM은 Ubuntu 9.04를 실행 중이고 서버는 nfs-kernel-server 패키지를 사용하고 있습니다.
다양한 NFS 튜닝 리소스에 따르면 nfsd 스레드(제 경우에는 커널 스레드) 수를 변경하면 성능에 영향을 미칠 수 있습니다. 일반적으로 이 조언은 사용량이 많은 서버에서 기본값인 8에서 숫자를 늘리는 방식으로 구성됩니다. 현재 구성에서 찾은 내용은 다음과 같습니다.
RPCNFSDCOUNT=8: (기본값): 클라이언트에서 1GB 파일을 분류하는 데 13.5~30초, 즉 35~80MB/초
RPCNFSDCOUNT=16: 파일을 60MB/s로 변환하는 데 18초
RPCNFSDCOUNT=1: 8~9초파일을 고양이하려면 (!!?!) 125MB/s
RPCNFSDCOUNT=2: 파일을 12MB/s로 변환하는 데 87초
내보낼 파일은 Xen의 PCI 패스스루를 사용하여 서버에 마운트된 RevoDrive SSD에 있다는 점을 언급해야 합니다. 서버에서는 몇 초 안에 파일을 처리할 수 있습니다(> 250MB/s). 각 테스트 전에 클라이언트에 캐시를 삭제합니다.
여러 클라이언트가 있을 때 제대로 작동하지 않을 것이라고 생각하기 때문에 단 하나의 스레드로 구성된 서버를 그대로 두고 싶지는 않지만 작동 방식을 오해할 수 있습니다. 테스트를 몇 번 반복했는데(사이에 서버 구성 변경) 결과는 상당히 일관되었습니다. 그래서 내 질문은 다음과 같습니다왜 스레드 1개로 성능이 가장 좋은가요?
제가 변경하려고 시도한 몇 가지 다른 사항은 거의 또는 전혀 효과가 없었습니다.
/proc/sys/net/ipv4/ipfrag_low_thresh 및 /proc/sys/net/ipv4/ipfrag_high_thresh 값을 기본 192K, 256K에서 1M, 512K로 늘립니다.
/proc/sys/net/core/rmem_default 및 /proc/sys/net/core/rmem_max 값을 기본값 128K에서 1M로 늘립니다.
클라이언트 옵션 rsize=32768, wsize=32768을 사용하여 마운트
sar -d의 출력에서 기본 장치로 이동하는 실제 읽기 크기는 다소 작지만(100바이트 미만) 클라이언트에서 로컬로 파일을 읽을 때 문제가 발생하지 않는다는 것을 알고 있습니다.
RevoDrive는 실제로 두 개의 "SATA" 장치 /dev/sda 및 /dev/sdb를 노출한 다음 dmraid는 /mnt/ssd에 마운트한 다음 /export/ssd에 바인드 마운트한 이들에 걸쳐 스트라이프된 fakeRAID-0을 선택합니다. 두 위치를 모두 사용하여 내 파일에 대한 로컬 테스트를 수행했으며 위에서 언급한 좋은 성능을 확인했습니다. 답변/의견에서 더 자세한 내용을 요청하면 추가하겠습니다.
답변1
클라이언트 요청이 들어오면 스레드 중 하나로 전달되고 나머지 스레드는 미리 읽기 작업을 수행하도록 요청됩니다. 파일을 읽는 가장 빠른 방법은 하나의 스레드가 순차적으로 읽도록 하는 것입니다. 따라서 하나의 파일에 대해 이는 과잉이며 본질적으로 스레드는 스스로 더 많은 작업을 수행합니다. 그러나 1개의 클라이언트가 1개의 파일을 읽는 경우에 대한 사실은 실제 배포 시에도 반드시 사실인 것은 아니므로 대역폭/CPU 사양에 따라 스레드 수와 미리 읽기 수를 기준으로 하는 공식을 따르십시오.