ZFS 스크러빙 튜닝, 15 일 동안 141KB / s 실행

14

7.2k rpm sas 디스크에서 미러 + 스트라이프를 실행하는 매우 기본적인 시스템이며 특별히로드되지는 않습니다. 모든 데이터 세트에서 중복 제거, 압축이 없습니다. 스크럽은 죽은 달팽이의 속도로 15 일 동안 실행되었습니다. 수행해야 할 최적화가 있습니까, 아니면 잘못된 hw 때문일 수 있습니까?

MD1200 인클로저가있는 Dell R510.
2x 제온 E5620
48GB
NexentaStor 3.1.3, 커뮤니티 에디션

몇가지 정보:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

spa_last_io는 이것을 실행할 때마다 변경됩니다.

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

5 초마다 약 20-25MB / s가 기록됩니다. 이러한 쓰기 사이에는 기본적으로 읽기 또는 쓰기가 없습니다.

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

iostats가 디스크를 기다리는 데 더 많은 시간을 소비하고 있다고 말하고 있습니까? 특히 % b 열

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0

대기 시간이 길어질까요?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

약간의 수정을 적용하여 약간의 차이를 만들었습니다. zfs_top_maxinflight는 127로 설정되고 zfs_scrub_delay는 0으로, zfs_scan_idle은 0으로 설정됩니다.

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

사전 mdb 조정, 다소 높은 b % 열에 주목

$ iostat -nx -M 5

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

mdb 조정 후, b % 열, 바쁜 대기 시간 80-85 %

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0

zfs nexenta

— 3 몰로
소스

iostat -XnE의 여러 발생 | grep 오류가 말합니다? 어떤 오류 카운트 증가합니까?

모든 열에 0

— 3molo

무엇합니까 smartctl -A /dev/disk각 드라이브에 대해 말을 (를 설치해야 할 수도 있습니다 smartctl이 기본 설치되어 있지 확실 경우).

— Chris S

1

하나의 디스크에서 "중간 오류 수 : 8071"외에는 관심이 없습니다. 모든 디스크는 동일한 (단일) sas 레인의 JBOD (Dell MD1200)에 있습니다

— 3molo

11

ZFS 스크럽 작업은 상당히 많은 뇌사 원칙에 따라 작동합니다. 특히, 다른 일이 없을 때만 문지르는 데 시간이 걸립니다. 상당히 일정한 데이터 액세스만으로 풀을 찌를 경우, 스크럽은 효과적으로 굶주리고 거의 아무것도하지 않습니다.

수행 할 작업에 대한 간단한 메모와 함께 탐색 할 수있는 튜너 블 (이전에는 마지막으로 살펴 봤음)

zfs_scan_idle-이 많은 클럭 틱 내에서 사용자 I / O가 발생하면 zfs_scrub_delay 클럭 틱으로 스크럽 I / O를 지연시킵니다.
zfs_scrub_delay-zfs_scan_idle에 의해 트리거되는 경우 스크럽 조작을 지연시키기위한 클럭 틱 수
zfs_top_maxinflight-최상위 vdev 당 최대 스크럽 I / O 수
zfs_scrub_limit-리프 vdev 당 최대 스크럽 I / O 수
zfs_scan_min_time_ms-제거 작업에서 TXG 당 소비하는 최소 ms
zfs_no_scrub_io-노트 없음
zfs_no_scrub_prefetch-메모가 없습니다. 이름은 스크럽 작업에서 프리 페치를 유발하지 않는 것으로 보입니다.

이러한 모든 설정은 "echo [tunable] / W0t [number]"를 사용하여 즉시 변경하고 "echo [tunable] / D"를 사용하여 현재 설정을 볼 수 있습니다 (변경하기 전에 권장).

따라서 이론 상으로는 일반적으로 zfs_scan_idle을 10 (또는 1 또는 0, 지원하는 경우 코드를 확인해야 함)으로 변경하고 zfs_scrub_delay를 1 (또는 0 인 경우)로 변경하십시오. txg_synctime_ms 설정이 5000 이상인 경우 zfs_scan_min_time_ms를 약간 변경하면 일부 수준의 사용자 I / O가 발생하더라도 실제로 스크럽 작업을 수행하는 데 훨씬 더 적극적이어야합니다.

특정 사례에서 % b 및 asvc_t는 매우 무작위적인 읽기 워크로드가 진행되고 있음을 나타냅니다 (실제로 순차 인 경우 회전 디스크가 그보다 더 나은 성능을 발휘해야 함). 위에서 설명한대로 "쉬운"작업을 이미 수행했습니다. . 먼저 zfs_no_scrub_prefetch를 켜서 스크럽 작업에서 프리 페치를 비활성화하고 이것이 도움이되는지 확인했습니다. 기쁨이 없다면 Nexenta의 버전에 따라 30/5, 5/1 또는 10/5를 실행 중일 수 있습니다 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000의 설정에 사용하는 약어)). zfs_txg_timeout을 10으로, zfs_txg_synctime_ms를 5000으로 변경 한 다음 zfs_scan_min_time_ms를 3000 또는 4000으로 올리십시오. 이렇게하면 ZFS가 5/1을 기본값으로 사용하는 이전 NexentaStor 설치의 기본 설정과 비교할 때 스크럽에 더 많은 시간을 소비 할 수 있습니다. 꼼꼼한,

도움이 되었기를 바랍니다. 행운을 빕니다!

— Nex7
소스

"echo <tunable> / W0t <number> | mdb -kw"를 사용하여 bash에서 이러한 설정을 수정한다고 가정합니다. 그리고 "echo <tunable> / D | mdb -k"로 현재 값을 봅니다. 내 메모에 따르면이 모든 것들이 비행 중에 변경 될 수 있다고 말하면 / etc / system 수정이 필요하지 않으며 재부팅하기 위해 재부팅 할 필요가 없습니다.

— Nex7

또한 응답하기 전에 전체 질문을 읽고 전화 회의 중에 ServerFault 탐색을 중지해야합니다. :)

— Nex7

% b와 asvc_t는 매우 무작위적인 읽기 워크로드가 진행되고 있음을 나타냅니다 (실제로 순차 인 경우 회전 디스크가 그보다 더 나은 성능을 발휘해야 함). 먼저 zfs_no_scrub_prefetch를 켜서 스크럽 작업에서 프리 페치를 비활성화하고 이것이 도움이되는지 확인했습니다. 기쁨이 없다면 Nexenta의 버전에 따라 30/5, 5/1 또는 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)를 실행 중일 수 있습니다. zfs_txg_timeout을 10으로, zfs_txg_synctime_ms를 5000으로 변경 한 다음 시도하십시오. ! 3000이 정상 I / O를 굶어 수, 스크럽에 더 많이 지출 할 수 ZFS를 알려줍니다 4000에 zfs_scan_min_time_ms 흐름이 완만

— Nex7

나는 당신이 매우 귀중한 의견을 제공한다고 생각하지만, 하나의 좋은 답변에 의견을 추가 할 수 있다면 훨씬 도움이 될 것입니다.

— 3molo

2

더 많은 튜닝이 도움이되었지만 반드시 그런 것은 아닙니다. ZFS 스크럽은 디스크의 섹터 별이 아니라 데이터 구조를 통해 롤링된다는 점에 유의해야합니다. 당신의 디스크에 어떻게 ZFS 데이터 구조의 외모에 따라 말을하는 것입니다 어느, 스크럽 작업이 믿을 수 없을만큼 무작위로 보일 수 있습니다 - 당신의 디스크> 1백메가바이트 할 수 있습니다 / s의 연속 읽기,하지만 완전히 랜덤 읽기는 완전히 다른 이야기가 될 것입니다 . 평균 블록 크기도 여기에 중요합니다.

— Nex7

3

하드웨어가 의심됩니다 ...

왜이 일을 15 일 동안 계속하게 하시겠습니까? 그것은 정상이 아닙니다. 스크럽을 중지하고 zpool scrub -s tank시스템을 점검하십시오.

어떤 컨트롤러를 사용하고 있습니까?
이 수영장에서 처음으로 실행 한 스크럽입니까?
처음에 스크럽을 실행하라는 문제가 있었습니까?

— ewwhite
소스

1

LSI SAS9200-8e (IT 펌웨어). 먼저 문지르지 마십시오. 아니요, 실제 문제는 없습니다 (그러나 잠시 동안 순차적 읽기 / 쓰기 성능에 의문을 제기했습니다).

— 3molo

대기 시간 및 대기 시간으로 업데이트되어 항상 서비스 요청 시간이 있고 스크럽의 우선 순위가 낮아 스크롤이 중단되도록 의심합니다. 통찰력은 매우 도움이됩니다!

— 3molo

스크럽은 정기적으로 실행하는 것이 중요합니다. 스크럽을 실행하는 데 문제가 생길 때까지 기다리는 것은 데이터 손실로 문제가 발생할 것을 요구합니다. 자동 데이터 손상 (비 트로트)을 포착하기 위해 스크럽이 있습니다. 느리게 실행되는 스크럽은 시스템 문제의 징후가 아니라 스크럽이 가속화되지 않을 정도로 사용중인 풀입니다.

— lschweiss

0

내 대답은 조금 늦었지만, 이런 종류의 일이 다른 사람에게 발생하면 여기에 내 생각이 있습니다. 단순히 "dmesg"를 사용해보십시오. 필자의 경우 스크럽을 수행하지 않았지만 파일을 디스크에 복사하는 중이었고 몇 초 동안 디스크가 활성 상태 인 것을 분명히 들었다가 모두 더 오랜 시간 동안 멈추었다가 다시 작동하는 등의 작업을 명확하게 듣고있었습니다. 이것은 하나의 SATA 컨트롤러의 고장으로 인한 것이며 dmesg는 모든 오류를 주었다. 처음에는 고장난 디스크라고 생각했지만 실제로는 컨트롤러라는 것을 깨달았습니다.

— jytou
소스

-3

스크럽은 언로드 된 서버에서도 사용 가능한 시스템 다운 타임을 사용합니다. 가용성에 관한 것입니다. 램과 프로세서는 디스크가 아니라 사용률을 제거하는 열쇠입니다. 이러한 기능이 많을수록 스크럽 성능이 향상됩니다. 그러나이 경우 ZPools 측면에서 디스크를 더 잘 배치할수록 스크럽 성능도 향상됩니다.

따라서 성능이 느리고 그 경우에 해당하는 것으로 판단되는 경우이를 잠재적 인 원인으로 생각합니다.

— 사용자 169761
소스

1

리소스가 부족하다는 표시가 없습니다.

— 3molo

1

이것은 거의 완전히 거짓입니다. CPU 및 RAM은 스크럽 작업에 아무런 영향을 미치지 않습니다 (사용 가능한 공간이 전혀 없다고 가정). 사용 가능한 RAM 및 CPU가 많으면 스크럽 작업 속도가 빨라지지 않습니다. 스크럽은 풀에 들어오는 I / O를 감시하는 것으로 제한됩니다. 사용 가능한 시스템 다운 타임이 무엇인지 확인하는 것이 아닙니다.

— Nex7