7.2k rpm sasディスクでミラー+ストライプを実行するかなり基本的なシステムで、特にロードされていません。すべてのデータセットで重複排除、圧縮なし。スクラブは、カタツムリの死骸の速さで15日間実行されています。実行する必要があるいくつかの最適化はありますか、それとも何らかの障害のあるハードウェアが原因である可能性がありますか?
いくつかの情報:
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/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
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 Tweakのポスト、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スクラブ操作は、かなり頭の痛い原則に基づいて動作します。特に、他に何も行われていない場合にのみ、スクラブに時間を費やします。ほんの少しのデータアクセスでプールをポークする場合、スクラブは事実上それ自体を枯渇させ、ほとんど何もしません。
探求する調整可能なパラメータとその機能についての簡単なメモ(ただし、これについてはしばらく前に最後に調べました):
これらはすべて、「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インストールのデフォルト設定と比較して、スクラブに多くの時間を費やすことができます。注意してください。遅延設定も基本的に0に設定されている場合、これにより通常のI/Oが不足する可能性があります。
お役に立てれば。幸運を!
ハードウェアだと思います...
なぜこれを15日間実行させるのですか?それは異常です。スクラブを停止します-zpool scrub -s tank
とシステムをチェックアウトします。
私の答えは少し遅くなりますが、このようなことが他の誰かに起こった場合は、私の考えは次のとおりです。単に「dmesg」を試してください。私の場合、スクラブはしていませんでしたが、ファイルをディスクにコピーしていました。ディスクが数秒間アクティブであり、その後、すべてが長時間停止し、再び動作していることなどがはっきりとわかりました。これは、1つのSATAコントローラーの障害によるもので、dmesgがすべてのエラーを出しました。最初は障害のあるディスクだと思っていましたが、実際にはコントローラであることがわかりました。