ZFSスクラブのチューニング、141 KB / sを15日間実行

14

7.2k rpm sasディスクでミラー+ストライプを実行する、特に基本的なシステムではありません。すべてのデータセットで重複除去、圧縮なし。スクラブは、死んだカタツムリの速度で15日間実行されています。実行する必要のある最適化はありますか、それともハードウェアの欠陥が原因ですか？

MD1200エンクロージャを搭載したDell R510。
Xeon E5620 x 2
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〜25 MB /秒が書き込まれます。それらの書き込みの間に、基本的に読み取りまたは書き込みはありません。

                          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

pre mdb tweak、かなり高い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

— 3molo
ソース

iostat -XnEの複数の出現| grepエラーは言う？エラーカウントが増加しますか？

すべての列でゼロ

— -3モル

何がないsmartctl -A /dev/disk（インストールする必要があります各ドライブについて言うsmartctlことは基本インストールに付属しているかどうかわから、ありません）。

— クリスS

1

1つのディスクで「中程度のエラーカウント：8071」以外の関心はありません。すべてのディスクは、同じ（単一の）

— SAS

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-スクラブ操作の1トランザクションあたりの最小ミリ秒
zfs_no_scrub_io-メモなし
zfs_no_scrub_prefetch-メモはありません。名前はスクラブopsでプリフェッチを引き起こさないことを意味するようです

これらのすべては、「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に変更してみてください。これは、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にしてzfs_scan_min_time_msを3000または4000にアップします。これにより、ZFSがスクラブにはるかに長い時間を費やすことができ、通常のI / Oが

— 不足

非常に貴重な情報を提供してくれると思いますが、1つの良い答えにコメントを追加できれば、さらに役立つでしょう。

— モーロ

2

より多くのチューニングが役立ったかもしれませんが、必ずしもそうではありません。ZFSスクラブは、ディスク上のセクターごとではなく、データ構造をロールスルーすることに注意することが重要です。つまり、zfsデータ構造がディスク上でどのように見えるかに応じて、スクラブ操作は信じられないほどランダムに見える場合があります-ディスクは100 MB / sを超える連続読み取りが可能ですが、完全にランダムな読み取りは完全に別の話になります。ここでは、平均ブロックサイズも重要です。

— Nex7

3

ハードウェアが疑われる...

なぜこれを15日間実行しますか？それは普通ではありません。スクラブを停止しzpool scrub -s tank、システムをチェックアウトします。

どのコントローラーを使用していますか？
これはこのプールで実行した最初のスクラブですか？
最初にスクラブを実行するように促した問題がありましたか？

— ewwhite
ソース

1

LSI SAS9200-8e（ITファームウェア）。最初のスクラブではありません。いいえ、実際の問題はありません（ただし、しばらくの間、シーケンシャルな読み取り/書き込みのパフォーマンスに疑問を抱いてきました）。

— モーロ

待機時間と待機時間で更新され、リクエストを処理する時間が常にあると疑われ始め、スクラブの優先順位が低くなり、停止するまでクロールされます。洞察はとても役に立ちます！

— モーロ

スクラブは定期的に実行することが重要です。スクラブを実行するのに問題が生じるまで待つことは、その問題がデータ損失に爆発することを求めています。スクラブは、サイレントデータ破損（bitrot）をキャッチするためにあります。実行速度の遅いスクラブはシステムの問題の兆候ではなく、スクラブを加速させないようにビジー状態に保たれているプールにすぎません。

— -lschweiss

0

私の答えは少し遅れていますが、この種のことが他の誰かに起こった場合、ここに私の考えがあります。単に「dmesg」を試してみてください。私の場合、スクラブを実行していませんでしたが、ディスクにファイルをコピーしていて、ディスクが数秒間アクティブになっているのをはっきりと聞き、その後すべてが長時間停止し、再び動作しました。これは、1つのSATAコントローラーの障害が原因であり、dmesgはすべてのエラーを私に与えました。最初は故障したディスクだと思っていましたが、実際にはコントローラーであることに気付きました。

— to頭
ソース

-3

スクラブは、利用可能なシステムのダウンタイムを使用します。アンロードされたサーバーであっても、それは可用性に関するものです。ラムとプロセッサは、ディスクではなくスクラブ使用率の鍵です。これらが多ければ多いほど、スクラブのパフォーマンスは向上します。ただし、この場合、ZPoolsの観点からディスクを適切にレイアウトすればするほど、スクラブのパフォーマンスも向上します。

そのため、パフォーマンスが低下しており、それが事実であると思われる場合は、潜在的な理由としてこれらを検討します。

— user169761
ソース

1

リソースが不足していることを示すインジケータは表示されません。

— モーロ

1

これはほとんど完全に間違っています。CPUとRAMは、スクラブ操作に実質的に影響を与えません（空きがあると仮定した場合）。空きRAMとCPUがたくさんあると、スクラブ操作が「高速化」されません。スクラブは、「利用可能なシステムダウンタイム」をチェックすることではなく、プールへの着信I / Oを監視することで制限されます。

— Nex7