Tuning ZFS scrubbing, 141KB / s berjalan selama 15 hari

14

Sebuah sistem yang cukup mendasar menjalankan mirror + stripe pada disk sas 7.2k rpm, tidak terlalu dimuat. Tanpa pemotongan, kompresi pada semua dataset. Scrub telah berjalan selama 15 hari dengan kecepatan siput mati. Apakah ada beberapa optimasi yang perlu dilakukan, atau dapatkah itu karena beberapa kesalahan hw?

  • Dell R510 dengan penutup MD1200.
  • 2x Xeon E5620
  • 48GB
  • NexentaStor 3.1.3, edisi Komunitas

Beberapa informasi:

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 diubah setiap kali saya menjalankan ini

# 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

Setiap 5 detik, sekitar 20-25 MB / s ditulis. Antara menulis itu pada dasarnya tidak ada membaca atau menulis.

                          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
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Apakah iostats mengatakan kepada saya bahwa saya menghabiskan lebih banyak waktu menunggu disk maka saya harus melakukannya? Khususnya kolom% 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

Latency anak laki-laki di sisi atas?

# 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

Menerapkan beberapa perubahan yang membuat sedikit perbedaan. zfs_top_maxinflight diatur ke 127, zfs_scrub_delay ke 0, dan zfs_scan_idle ke 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, perhatikan kolom b% agak tinggi

$ 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

posting mdb tweak, perhatikan kolom b%, 80-85% waktu menunggu sibuk

$ 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 bulan
sumber
Apa beberapa kemunculan iostat -XnE | grep Kesalahan mengatakan? melakukan beberapa peningkatan jumlah kesalahan?
Nol di semua kolom
— bulan
Apa yang smartctl -A /dev/diskdikatakan tentang setiap drive (mungkin harus menginstal smartctl, tidak yakin apakah itu datang dengan instalasi dasar).
— Chris S
1
Tidak ada yang menarik, selain "Jumlah kesalahan non-menengah: 8071" pada satu disk. Semua disk diletakkan dalam JBOD (Dell MD1200) pada jalur sas (tunggal) yang sama
— 3molo

Jawaban:

11

Operasi scrub ZFS beroperasi pada beberapa prinsip yang cukup mematikan otak. Terutama, itu hanya menghabiskan waktu menggosok ketika tidak ada hal lain yang terjadi. Jika Anda menyodok kumpulan dengan hanya sedikit akses data pada basis yang cukup konstan, scrub secara efektif akan kelaparan sendiri dan hampir tidak melakukan apa pun.

Tunables untuk dijelajahi, dengan catatan singkat saya tentang apa yang dilakukannya (saya terakhir melihat ke dalam beberapa saat yang lalu, meskipun):

  • zfs_scan_idle - jika pengguna I / O terjadi dalam banyak tick ticks ini, tunda scrub I / O oleh zfs_scrub_delay tick ticks
  • zfs_scrub_delay - berapa banyak kutu jam untuk menunda operasi scrub jika dipicu oleh zfs_scan_idle
  • zfs_top_maxinflight - jumlah maksimum scrub I / O per vdev tingkat atas
  • zfs_scrub_limit - jumlah maksimum scrub I / O per daun vdev
  • zfs_scan_min_time_ms - minimum ms untuk menghabiskan per txg pada operasi scrub
  • zfs_no_scrub_io - tidak ada catatan
  • zfs_no_scrub_prefetch - tanpa catatan, nama sepertinya menyiratkan tidak menyebabkan prefetch pada operasi scrub

Semua ini dapat diubah dengan cepat menggunakan "echo [tunable] / W0t [number]" untuk berubah, dan "echo [tunable] / D" untuk melihat pengaturan saat ini (yang saya sarankan lakukan sebelum mengubah).

Jadi dalam teori, dan dalam praktik umum, jika Anda ingin, katakanlah, ubah zfs_scan_idle menjadi 10 (atau 1 - atau 0, jika mendukung itu, perlu memeriksa kode) dan zfs_scrub_delay ke 1 (atau 0, jika mendukung itu), dan jika pengaturan txg_synctime_ms Anda adalah 5000 atau lebih mungkin mengubah zfs_scan_min_time_ms sedikit, itu harus menjadi jauh lebih agresif tentang benar-benar melakukan operasi scrub bahkan dengan beberapa tingkat pengguna I / O terjadi.

Dalam kasus spesifik Anda,% b dan asvc_t yang dilaporkan menyiratkan beberapa beban kerja baca yang sangat acak (berputar disk harus lebih baik daripada jika itu benar-benar berurutan), dan Anda telah melakukan hal-hal "mudah" seperti dijelaskan di atas. . Jadi, pertama saya akan mengaktifkan zfs_no_scrub_prefetch, untuk menonaktifkan prefetch pada operasi scrub, hanya untuk melihat apakah itu membantu. Jika tidak ada sukacita, tergantung pada versi Nexenta yang Anda gunakan - Anda dapat menjalankan 30/5, 5/1 atau 10/5 (itu singkatan yang kami gunakan untuk pengaturan zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Ubah zfs_txg_timeout menjadi 10 dan zfs_txg_synctime_ms menjadi 5000, lalu coba naikkan zfs_scan_min_time_ms menjadi 3000 atau 4000. Ini memberi tahu ZFS bahwa ia dapat menghabiskan lebih banyak waktu pada scrub, dibandingkan dengan pengaturan default pada instal NexentaStor lama yang menggunakan 5/1 sebagai default - tetapi cermat,

Semoga ini membantu. Semoga berhasil!

— Nex7
sumber
Saya kira saya harus mencatat bahwa Anda memodifikasi pengaturan ini di bash menggunakan "echo <tunable> / W0t <number> | mdb -kw". Dan Anda melihat nilai saat ini dengan "echo <tunable> / D | mdb -k". Catatan saya mengatakan semua ini dapat diubah dalam penerbangan, sepertinya tidak ada yang memerlukan modifikasi / etc / sistem dan reboot untuk berlaku.
— Nex7
Saya juga harus membaca seluruh pertanyaan sebelum menjawab - dan berhenti menjelajahi ServerFault saat panggilan konferensi. :)
— Nex7
% B dan asvc_t melaporkan menyiratkan beberapa beban kerja baca yang sangat acak (berputar disk seharusnya lebih baik dari itu jika benar-benar berurutan). Pertama saya akan mengaktifkan zfs_no_scrub_prefetch, untuk menonaktifkan prefetch pada operasi scrub, hanya untuk melihat apakah itu membantu. Jika tidak ada sukacita, tergantung pada versi Nexenta yang Anda gunakan - Anda dapat menjalankan 30/5, 5/1 atau 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000). Ubah zfs_txg_timeout menjadi 10 dan zfs_txg_synctime_ms menjadi 5000, lalu coba meningkatkan zfs_scan_min_time_ms ke 3000 atau 4000. Ini memberitahu ZFS bahwa ia dapat menghabiskan lebih banyak waktu pada scrub, mungkin kelaparan I / O yang normal!
— Nex7
Saya pikir Anda memberikan masukan yang sangat berharga, tetapi akan jauh lebih membantu jika Anda dapat menambahkan komentar menjadi satu jawaban yang bagus.
— 3
2
Lebih banyak penyetelan mungkin bisa membantu, tetapi belum tentu. Penting untuk dicatat bahwa scrub ZFS bergulir melalui struktur data, BUKAN sektor demi sektor pada disk. Artinya, tergantung pada bagaimana struktur data zfs terlihat pada disk Anda, operasi scrub mungkin terlihat sangat acak - disk Anda mungkin mampu> 100 MB / s membaca berurutan , tetapi pembacaan acak sepenuhnya akan menjadi cerita yang sama sekali berbeda . Ukuran blok rata-rata juga penting di sini.
— Nex7
3

Saya menduga perangkat keras ...

Mengapa Anda membiarkan ini berjalan selama 15 hari? Itu tidak normal. Hentikan scrub - zpool scrub -s tankdan periksa sistem.

  • Pengontrol apa yang Anda gunakan?
  • Apakah ini scrub pertama yang pernah Anda jalankan di kolam ini?
  • Apakah ada masalah yang mendorong Anda untuk menjalankan scrub?
— putih
sumber
1
LSI SAS9200-8e (firmware IT). Bukan scrub pertama. Tidak, tidak ada masalah nyata (tapi saya telah mempertanyakan kinerja baca / tulis berurutan untuk sementara waktu).
— 3molo
Diperbarui dengan latensi dan waktu tunggu, mulai mencurigai selalu ada waktu untuk melayani permintaan dan yang memprioritaskan scrub sangat rendah sehingga merangkak berhenti. Wawasan apa pun sangat membantu!
— 3molo
Lulur penting untuk dijalankan secara berkala. Menunggu sampai Anda memiliki masalah untuk menjalankan scrub meminta masalah itu meledak menjadi kehilangan data. Scrub ada untuk menangkap korupsi data diam-diam (bitrot). Lambat berjalan bukan tanda masalah sistem, hanya kolam yang cukup sibuk untuk tidak membiarkan lulur dipercepat.
— lschweiss
0

Jawaban saya datang agak terlambat, tetapi jika hal seperti ini terjadi pada orang lain, inilah pendapat saya: coba saja "dmesg". Dalam kasus saya, saya tidak melakukan scrub, tetapi saya menyalin file ke disk, dan saya jelas mendengar disk aktif selama beberapa detik, lalu semua berhenti untuk waktu yang lebih lama, dan kembali bekerja dan seterusnya. Ini karena kegagalan satu kontroler SATA dan dmesg memberi saya semua kesalahan. Saya pikir itu adalah disk yang gagal pada awalnya, tetapi kemudian saya menyadari itu sebenarnya controller.

— jytou
sumber
-3

Scrub menggunakan downtime sistem yang tersedia, bahkan pada server yang dibongkar, ini tentang ketersediaan. Ram dan Prosesor adalah kunci pemanfaatan scrub, bukan disc. Semakin banyak tersedia, semakin baik kinerja scrub Anda. Namun, tentu saja, dalam hal ini, semakin baik disk Anda diletakkan, dalam hal ZPools, semakin baik kinerja scrub Anda juga.

Jadi, jika kinerja Anda lambat, dan tampaknya memang demikian, saya akan menganggap ini sebagai alasan potensial.

— pengguna169761
sumber
1
Saya tidak melihat indikator bahwa sumber daya apa pun langka.
— bulan
1
Ini benar-benar salah. CPU & RAM memiliki dampak nol efektif pada operasi scrub (dengan asumsi ada yang gratis sama sekali). Memiliki banyak RAM & CPU gratis tidak akan 'mempercepat' operasi scrub. Scrub dibatasi dengan menonton I / O masuk ke kolam, bukan dengan memeriksa 'downtime sistem yang tersedia', apa pun itu.
— Nex7
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.