동일한 서버의 NFS/CIFS 디렉터리 간 복사 속도가 느림

Question

흠... 몇 가지 문제를 발견한 것 같은데 스모킹 건 한두 개를 발견한 것 같아요. 하지만 먼저 몇 가지 질문을 하고 귀하의 예상 답변에 대해 가정하겠습니다. 처음에는 관련 없어 보이는 몇 가지 데이터를 제시하겠지만, 읽어볼 가치가 있을 것이라고 약속합니다. 그럼, 조금만 기다려주세요... :-)

나는 raid10까지 총 4개의 드라이브가 스트라이프+중복이라고 가정합니다.
그리고 Linux autoraid(하드웨어 RAID 컨트롤러와 비교)를 사용하고 있습니다.
또한 모든 SATA 포트는 최대 전송 속도로 양방향으로 서로 독립적으로 전송할 수 있으며 모든 SATA 포트의 속도는 동일하다고 가정합니다. 즉, 단일 SATA 어댑터/컨트롤러가 있으면 연결된 모든 디스크를 정격 속도로 완벽하게 실행할 수 있습니다.
또한 최신 SATA 사양 드라이브 + 컨트롤러가 있다고 가정합니다. 즉, 6.0Gb/s입니다. 600MB/초입니다. 보수적으로 말하자면, 절반, 즉 300MB/초를 얻는다고 가정해 보겠습니다.
클라이언트-서버는 NIC 제한(100MB/s)이므로 드라이브에 충분한 스트레스를 줄 수 없습니다.
NIC보다 빠르게 진행하기 위해 NFS-to-NFS를 수행할 때 로컬 호스트를 사용한다고 가정하므로 NIC 제한 속도를 넘어설 수 있습니다. (내 생각에는 이것이 문제가 아니라는 것을 보여주기 위해 본딩을 했다고 말한 것 같습니다. )

문제 #1. 보고된 로컬 간 전송 속도도 낮은 것 같습니다. 이렇게 빠른 디스크를 사용하면 150MB/s보다 더 나은 속도를 기대할 수 있습니다. 저는 3.0Gb/s[어댑터 제한]만 수행하는 3디스크 raid0 시스템을 가지고 있으며 450MB/s 스트라이프를 얻을 수 있습니다. 귀하의 디스크/컨트롤러 속도는 내 속도의 2배이므로 [스트라이핑으로 인해] 로컬-로컬의 경우 150MB/초가 아니라 300MB/초를 얻을 것으로 기대합니다. 또는 600MB/초일 수도 있습니다. [논의를 위해 절반으로 줄일 수 있는 FS 오버헤드를 뺀]

귀하의 zpool 정보에서 귀하의 디스크 구성이 Western Digital이며 다음과 같은 것으로 나타났습니다.

미러-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
거울-1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

이제 이것을 iostat 정보와 비교해 보겠습니다. 모든 테스트에 대해 모든 드라이브에 대한 iostat 정보를 갖는 것이 좋을 수도 있지만, 귀하가 제공한 것만으로 문제를 진단할 수 있다고 믿습니다.
sdb와 sdd가 최대치에 도달했습니다.
당신이 지적했듯이 이것은이상한. 나는 기대할 것이다모두raid10에서 균형 잡힌 사용량/통계를 갖도록 드라이브합니다. 이것은 [나의] 스모킹 건입니다.
두 가지를 결합합니다. 최대 드라이브는 그렇지 않은 드라이브와 약간 다른 모델입니다. zpool 순서는 sda/sdb sdc/sdd라고 가정합니다. [하지만 반대일 수도 있습니다]
sda/sdc는 68AX9N0입니다.
sdb/sdd는 68EUZN0입니다.

문제 #2. WD20EFRX + 68AX9N0 + 68EUZN0에 대한 Google 검색에서 다음 페이지를 찾았습니다.http://forums.whirlpool.net.au/archive/2197640

68EUZN0 드라이브는 약 8초 후에 머리를 주차할 수 있는 반면 다른 드라이브는 이에 대해 더 똑똑해 보입니다(또는 그 반대).

따라서 NFS 캐싱 + FS 캐싱 + SSD 캐싱을 고려하면 기본 드라이브가 유휴 상태가 되어 헤드가 파킹될 수 있습니다. 내 생각엔 NFS의 추가 캐싱 계층이 이를 넘어선 것 같습니다.

FS 동기화 옵션을 다양하게 변경하여 이를 테스트할 수 있습니다. 어쩌면 동기화가 비동기보다 더 나을 수도 있습니다. 또한 가능하다면 SSD 캐싱을 끄고 테스트를 다시 실행하겠습니다. 아이디어는 주차가 가능하도록하는 것입니다.~ 아니다발생하고 결과를 확인하세요.

웹페이지에 언급된 대로 파크 지연 간격을 조정할 수 있는 몇 가지 유틸리티가 있습니다. 그것이 선택 사항이라면 철저하게 조사하십시오.

업데이트:

문제는 저장 및 전달(보장된 배달 포함) 네트워크를 통한 처리량 문제로 볼 수 있습니다. 참고로 저는~ 아니다NIC 또는 동등한 것에 대해 이야기합니다.

I/O 작업은 구조체에 저장되는 요청(예: 읽기/쓰기, buf_addr, buf_len)을 포함하는 패킷과 같다고 생각하세요. 이 요청 패킷/구조체는 NFS, ZFS, 장치 드라이버, SATA 컨트롤러, 하드 디스크 등 다양한 캐시 계층 간에 전달됩니다. 각 지점에는 해당 레이어의 도착 시간과 요청이 다음 레이어로 전달되는 출발 시간이 있습니다.

이러한 맥락에서 실제로 전송이 발생할 때의 실제 디스크 전송 속도는 링크 속도와 유사합니다. 대부분의 사람들은 디스크를 고려할 때 전송 속도만 고려하고 전송이 실제로 시작된 시기는 고려하지 않습니다.

네트워크 라우터에서는 패킷이 도착하지만 아웃바운드 링크가 깨끗하더라도 항상 즉시 전달되지는 않습니다. 라우터 정책에 따라 라우터는 다른 소스(또는 UDP의 경우 동일한 소스)에서 더 많은 패킷이 도착할 것을 기대하면서 패킷을 약간 지연시킬 수 있습니다. 아웃바운드 링크를 통해 보다 효율적으로 전송됩니다.

디스크의 경우 이 "지연"은 특정 FS 계층의 캐시 정책으로 특징지어질 수 있습니다. 즉, 요청이 시간 T에 레이어에 도착하면 T+1에 레이어를 떠나 T+1에 다음 레이어에 도착하는 대신 T+n에 출발/도착할 수 있습니다. FS 캐시 계층은 이를 수행하여 탐색 순서 최적화/정렬을 수행할 수 있습니다.

여러분이 보고 있는 동작은 혼잡으로 인해 창을 줄인 TCP 소켓과 매우 유사합니다.

테스트를 분할하는 것이 중요하다고 생각합니다. 지금 당신은 읽기와 쓰기를 하고 있습니다. 그리고 제한 요인/병목 현상이 무엇인지 알 수 없습니다. 테스트를 읽기 또는 쓰기로 나누는 것이 도움이 될 것이라고 생각합니다. 괜찮은 벤치마크 프로그램이 아마도 이를 수행할 것입니다. 내가 옹호하는 것은 [이것은 단지 대략적인 예일 뿐 정확한 논거는 아닙니다]:

쓰기의 경우 시간 dd if=/dev/zero of=/whatever_file count=64g
읽기의 경우 시간 dd if=/whatever of=/dev/null count=64g

64GB를 사용하는 이유는 물리적 RAM의 2배이고 블록 캐시 효과를 제거하기 때문입니다. 테스트 간에 동기화 명령을 수행합니다.

이를 로컬 FS에 적용하고 NFS에서 반복합니다.

또한 다음을 수행하십시오.읽다/dev/{sda,sdb,sdc,sdd} 각각에서 테스트

이 테스트 중에 iostat를 수행하십시오.

물리적 원시 디스크에서 읽기 테스트를 수행하면 하드웨어가 실제로 얼마나 빠르게 진행될 수 있는지에 대한 기준/최대값을 얻을 수 있습니다. 원시 장치 읽기는 드라이브 전송 사양의 최대 성능과 비슷해야 합니다. 예상되는 쓰기 속도는 하드 디스크와 유사해야 합니다. 그렇지 않다면 왜 안 됩니까? 모든 디스크는 거의 동일한 속도로 테스트되어야 합니다. 여기서 제가 하려는 것은 이전 테스트에서 두 개의 디스크만 최대로 사용된 이유입니다.

32GB로 계산하고 최대 전송 속도가 600MB/초라고 가정하면 이를 채우고 플러시하는 데 최소 50초가 걸립니다. 그렇다면 공원 제한 시간은 어떻게 설정되어 있나요?

또한 mem= 부팅 매개변수를 통해 커널이 허용하는 물리적 RAM의 양을 줄여 상황을 약간 변경할 수 있습니다. mem=8g와 같은 것을 시도하여 어떤 효과가 있는지 확인하세요. 블록 레이어 캐시 플러시 정책을 조정할 수 있는 일부 /proc 항목도 있습니다.

또한 내 FS는 ext4이고 noatime으로 마운트되었습니다. 고려해 볼 수도 있습니다.zfs set atime=off ...

또한 시스템 로그를 살펴보십시오. 때로는 드라이브가 감지 오류를 보고하고 시스템이 더 낮은 전송 속도를 사용하도록 재구성하는 경우도 있습니다.

또한 드라이브의 SMART 데이터를 살펴보세요. 뭔가 특이한 점이 보이나요? 특정 드라이브에서 과도한 소프트 재시도(예:)

앞서 말했듯이 로컬 디스크 성능은 예상보다 훨씬 낮습니다. NFS로 전체 시스템을 다루기 전에 먼저 이 문제를 해결해야 한다고 생각합니다. 레이드 디스크가 모두 균형 잡힌 활용도를 갖고 있고 야구장에 있었다면 그것에 대해 덜 걱정할 것입니다.

[WDC 디스크도 있는] 내 시스템은 NFS용으로 구성되지 않았습니다(저는 rsync를 많이 사용합니다). 앞으로 1~2일 동안 해야 할 급한 일이 있어요. 그 후에는 [저도 궁금할 것 같아요] 한번 해볼 시간을 갖겠습니다.

업데이트 #2:

ZFS 불균형 문제를 잘 파악했습니다. 이는 내 "문제 #1"을 설명하는 데 도움이 됩니다. 그것~할 것 같다재조정 작업이 대기 시간/타이밍과 관련하여 NFS를 혼동하여 "TCP 창/백오프" 동작을 유발하는 경우에도 NFS의 결함을 설명하십시오. 매우 높은 확률은 아니지만 가능성은 적지 않습니다.

rsync 테스트를 사용하면 NFS를 사용할 필요가 없습니다. 서버에 SSH로 연결할 수 있으면 rsync그리고NFS는 중복됩니다. NFS에서는 cp 등을 사용하면 됩니다. rsync를 수행하려면 ssh를 통해 기본 ZFS로 직접 이동하세요. 이는 NFS 마운트 없이도 작동합니다. [내가 사용하는 rsync 구성은 다음과 같습니다]:

RSYNC_SSH="/usr/bin/ssh" 내보내기
SSH_NOCOMPRESS=1 내보내기
rsync /wherever1 서버:/zfsmount/whatever

이 localhost 또는 bonded를 수행하면 기대한 성능을 얻을 수 있습니다(ZFS 불균형 문제가 없음). 그렇다면 문제의 범위를 NFS로 확실히 좁힙니다.그 자체.

나는 NFS용 커널 소스 중 일부를 정독했습니다. 제가 조금 살펴본 결과 적시성에 관해 본 것이 마음에 들지 않았습니다. NFS는 링크가 느렸던 80년대에 시작되었으므로 [여전히] NIC 대역폭을 보존하기 위한 많은 코드가 있습니다. 즉, 꼭 필요한 경우에만 작업을 "커밋"합니다. 반드시 우리가 원하는 것은 아닙니다. 나의 환상적인 네트워크 라우터 정책 비유에서 NFS의 캐시는 "T+n" 지연이 있는 것으로 보입니다.

NFS 캐시를 비활성화하고 해당 요청을 최대한 빨리 ZFS에 전달하도록 할 수 있는 모든 작업을 수행하는 것이 좋습니다. ZFS를 똑똑한 것으로 만들고 NFS를 "멍청한 파이프"로 만드십시오. NFS 캐싱은 본질적으로 일반적일 수 있습니다(예: 백업 저장소가 RAID인지 또는 탑재된 기본 FS의 특별한 특성에 대해 너무 많이 알지 못함). ZFS는 RAID와 이를 구성하는 디스크에 대해 자세히 알고 있습니다. 따라서 ZFS의 캐시는 선택에 대해 훨씬 더 지능적일 수 있습니다.

NFS에서 동기화 마운트를 수행하도록 시도하면 성공할 수 있습니다. 그리고 noatime에 대한 내용도 봤으니 해당 옵션도 켜주세요. 다른 NFS 조정/마운트 옵션이 있을 수 있습니다. NFS가 일반적인 의심이라면 충분히 잘 작동하도록 재구성할 수 있기를 바랍니다.

반면에 NFS를 뒤흔드는 옵션이 없다면 SSH를 통한 rsync가 실행 가능한 대안이 될까요? 실제 사용 사례는 무엇입니까? NFS를 고성능이 필요한 대규모 대량 전송을 위한 통로로 사용하고 있는 것 같습니다(예: 사용자 홈 디렉토리의 자동 마운트 지점과 비교). 서버에 대한 클라이언트 백업 등과 같은 작업에 사용됩니까?

Answer 1