LAN의 다른 시스템으로 여러 NFS를 내보내는 Solaris 11 시스템이 있습니다. 테스트를 위해 Linux 시스템을 클라이언트로 사용합니다.
읽기 속도를 테스트하기 위해 빠른 스크립트를 작성했는데, 기가비트 LAN의 평균 읽기 속도는 약 110Mbps(또는 13MB/s)였습니다. 더 빨라질 거라 생각했을 것 같아요. SSH(scp)는 3.8MB/s만 제공하지만 이는 암호화되어 있습니다.
http는 NFS 비율과 비슷한 11.5M/s를 제공합니다. 이거 너무 낮은거 아냐?
이 숫자의 병목 현상은 무엇입니까?
답변1
클라이언트가 계속 전송하기 때문에 NFS는 실제로 처리량을 최대화할 수 없습니다.나에게 보내주세요너무 많이데이터서버에 (너무 많이몇 킬로바이트로 제한됨) 더 많은 질문을 하기 전에 전체 답변을 기다리십시오.죽은모든 대기열이 비어 있을 때. 네트워크의 모든 FS(CIFS, SSHFS)에는 동일한 유형의 문제가 있습니다(그리고 IIRC scp 또는 어쩌면 그냥 sftp기억이 나지 않습니다).
암호화 오버헤드 외에도 ssh몇 가지 추가적인 성능 제한이 있습니다(참조:여기더 알아보기).
청크 요청을 수행하는 클라이언트를 사용하지 않는 한 HTTP는 바로 TCP여야 하므로 이러한 제한이 있어서는 안 됩니다. TCP는 혼잡을 피하면서 처리량을 최대화하기 위해 혼잡 제어 알고리즘을 사용해야 합니다. 몇 킬로바이트의 초기 전송은 느릴 수 있지만 두 컴퓨터가 동일한 스위치를 통해 연결되어 있으면 수십 분의 1초 내에 대역폭을 최대화할 수 있습니다. 네트워크 품질이 좋지 않은 경우(예: 이상한 패킷 손실)가 있을 수 있습니다.
시도해 볼 만한 것:
/dev/zeroFS 액세스의 병목 현상을 제거하려면 일반 TCP 연결(socat또는 예를 들어) 을 통해 콘텐츠를 전송하십시오.nc- 네트워크 인터페이스 통계에서 전송 오류 및 TCP 스택 통계를 확인합니다(
netstat -s). - (TCP 및 UDP)를 사용하여
iperf테스트되었습니다 .
답변2
과거에도 비슷한 상황이 발생했는데 해결 방법은 Solaris와 Linux에서 v4 대신 NFS v3을 강제로 마운트하는 것이었습니다.
Solaris 측에서는 /etc/default/nfs를 편집하고 서버 측 변수를 server로 설정하고 NFS v3 측만 허용할 수 있습니다.
변수 이름이 기억나지 않지만 설명이 필요합니다.
수행 중인 테스트가 하나의 대용량 파일을 복사하고 있습니까, 아니면 여러 파일을 복사하고 있습니까? 여러 파일이면 놀라지 않겠지만, 단일 파일이면 더 좋을 것 같습니다.
또한 어떤 종류의 기본 스토리지가 있나요? 단일 접시? 레이드 설정? 이는 귀하의 성과에도 영향을 미칩니다.
답변3
기본 파일 시스템이 데이터를 얼마나 빨리 제공합니까? NFS 자체는 보이는 것보다 더 빠르게 데이터를 이동하며 이는 다른 병목 현상이 있음을 나타냅니다. iperf를 사용하여 네트워크가 더 높은 대역폭을 전달할 수 있는지 확인하면 이를 확신할 수 있습니다.
Solaris 시스템에 로그인하고 스트리밍이 얼마나 빠른지 확인하기 위해 /dev/null로 내보내려는 파일 시스템의 파일을 복사하겠습니다. 이미 파일 시스템 캐시에 있는 파일에 대해 이 읽기 테스트를 수행하지 않으려면 약간의 노력이 필요합니다. 다른 파일 시스템의 경우 마운트 해제/마운트하여 캐시를 무효화할 수 있지만 ZFS에서는 이것만으로는 충분하지 않습니다.
답변4
스택의 각 부분의 기능을 이해해야 합니다. NFS 공유 파일 시스템은 어떤 유형의 디스크로 구성됩니까? SAS? SATA? SSD? 종류와 크기, RPM은 어떻게 되나요? 스핀 지연? 4k 하드인가요? ZFS는 512바이트 드라이브에 최적화되어 있으며 새로운 "고급 포맷" 디스크에는 알려진 성능 문제가 있습니다.
I/O 작업량이 얼마나 큽니까? 이는 저장소의 표시 속도에도 영향을 미칩니다.
순수한 스토리지 관점에서 이러한 문제는 백엔드 디스크에 데이터를 쓰고 읽는 속도에 영향을 미칩니다. 예를 들어 NFS 공유가 7200RPM 1TB SATA 디스크의 파일 시스템에 있고 워크로드 크기가 64KB이고 대부분 무작위라고 가정합니다.
Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time: 8.4 ms
Average Write Seek Time: 8.9 ms
Rotational latency: .120 ms
Average Latency: 4.166 ms
Average Read Service Time: 12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs: 79.000
Best Case Write IOPs: 76.000
--------------------------------------------------------------------------------
Best Case Read Throughput: 4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs: 55.300
Real World Write IOPs: 53.200
--------------------------------------------------------------------------------
Real World Read Throughput: 3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------
이를 통해 특정 워크로드 크기에서 단일 디스크에서 얻을 수 있는 실제 성능에 대한 아이디어를 얻을 수 있습니다.
다음 I/O가 시작되기 전에 쓰기 승인이 필요하지 않도록 쓰기 캐싱을 사용하거나 NFS 파일 시스템을 비동기식으로 마운트하면 성능을 향상시킬 수 있습니다. 이는 데이터를 위험에 빠뜨리므로 권장하지 않습니다.
백엔드 스토리지의 성능을 이해하고 나면 NFS(v3? v4? tcp? udp?) 또는 SSH(어떤 암호화 알고리즘을 사용하고 있습니까? 더 가벼운 알고리즘을 사용할 수 있음)에서 생성된 스토리지를 살펴보기 시작할 수 있습니다. 간접비. 성능 향상을 위한 arcfour와 같은 알고리즘) 또는 네트워크 자체. 저렴한 1GbE NIC가 있나요? 아니면 더 높은 최종 서버 품질의 네트워크 카드를 사용하시겠습니까? 여러 서비스 간에 네트워크 카드를 공유하고 있습니까? 네트워크에 트래픽을 생성하는 다른 것이 있습니까? 네트워크 정체, 충돌 또는 높은 재전송 속도는 어떻습니까?
이 모든 것이 백엔드 스토리지의 명백한 성능을 더욱 감소시키며, 이는 클라이언트가 매우 느린 것처럼 보이게 만든다는 의미입니다.
자, 위의 숫자는 최악의 시나리오죠? 워크로드의 100% 무작위 동기화. 순차적 워크로드가 있거나 IO 워크로드 크기를 늘릴 수 있는 경우 성능을 크게 향상시킬 수 있습니다. 예를 들어 IO 크기를 128k로 늘릴 수 있으면 성능이 두 배로 늘어나고 NFS 클라이언트에 따라 rsize 및 wsize를 다양한 설정으로 설정하여 성능을 테스트할 수 있습니다. 결국 수익이 감소하는 지점이 있습니다.
여러 개의 디스크, 미러 또는 RAID가 있는 경우 이에 대한 숫자를 조정해야 합니다.
실제 디스크 성능은 디스크 상자 측면에 인쇄된 성능과 거의 일치하지 않습니다.