Tuning ZFS fırçalama, 141KB / s 15 gün boyunca çalışıyor

14

7.2k rpm sas disklerinde ayna + şerit çalıştıran oldukça temel bir sistem, özellikle yüklü değil. Tekilleştirme yok, tüm veri kümelerinde sıkıştırma. Scrub ölü bir salyangoz hızında 15 gündür çalışıyor. Yapılması gereken bir optimizasyon var mı, yoksa bazı hatalı hw nedeniyle olabilir mi?

MD1200 muhafazalı Dell R510.
2x Xeon E5620
48GB
NexentaStor 3.1.3, Topluluk sürümü

Biraz bilgi:

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 bunu her çalıştırdığımda değişir

# 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

Her 5 saniyede bir yaklaşık 20-25 MB / s yazılır. Bu yazılar arasında temelde okuma veya yazma yoktur.

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

Iostatlar bana disk için beklemek için daha fazla zaman harcadığımı mı söylüyor? Özellikle% b sütunu

# 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

Gecikme biraz yüksek mi?

# 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

Biraz fark yarattı bazı tweaking uygulandı. zfs_top_maxinflight 127, zfs_scrub_delay 0 ve zfs_scan_idle 0 olarak ayarlandı.

# 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 tweak öncesi, oldukça yüksek b% sütununa dikkat edin

$ iostat -nx -A 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 sonrası,% b sütununa dikkat edin, meşgul bekleme süresinde% 80-85 zaman

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

Ne çoklu iostat oluşumu -XnE | grep Hataları söylüyor? hata sayısında artış var mı?

Tüm sütunlarda sıfır

— 3molo

smartctl -A /dev/diskHer sürücü hakkında ne söylenir (yüklemeniz gerekebilir smartctl, temel kurulumla birlikte gelip gelmediğinden emin değilsiniz).

— Chris S

1

Bir diskte "Orta olmayan hata sayısı: 8071" dışında ilgi çekici bir şey yok. Tüm diskler aynı (tek) sas şeridinde bir

— JBOD'da

11

ZFS fırçalama operasyonları oldukça ölü beyin prensipleri ile çalışır. En önemlisi, sadece başka bir şey olmadığında ovma için zaman harcar. Biraz veri erişimi olan bir havuzu oldukça sabit bir temelde kurcalarsanız, fırçalama etkili bir şekilde kendini aç bırakır ve neredeyse hiçbir şey yapmaz.

Keşfetmek için ayarlanabilirler, ne yaptığına dair hızlı notlarımla (en son bir süre önce buna baktım):

zfs_scan_idle - kullanıcı G / Ç'si bu çok sayıda saat kenarı içinde meydana gelirse, zikseli gevşeme saat gecikmeleri ile fırçalama G / Ç'sini geciktirin
zfs_scrub_delay - zfs_scan_idle tarafından tetiklenirse fırçalama işlemini geciktirmek için kaç saat kenesi
zfs_top_maxinflight - üst düzey vdev başına maksimum fırçalama G / Ç sayısı
zfs_scrub_limit - yaprak başına maksimum ovma G / Ç sayısı vdev
zfs_scan_min_time_ms - fırçalama işlemlerinde txg başına harcanacak minimum ms
zfs_no_scrub_io - not yok
zfs_no_scrub_prefetch - not yok, adın fırçalama işlemlerinde önceden getirmeye neden olmadığı anlamına geliyor

Bunların tümü, değiştirmek için "echo [ayarlanabilir] / W0t [sayı]" ve geçerli ayarı görüntülemek için "echo [ayarlanabilir] / D" (anında değiştirmeyi öneririm) kullanılarak değiştirilebilir.

Yani teoride ve genel pratikte, diyelim ki, zfs_scan_idle değerini 10 olarak değiştirin (veya destekliyorsa 1 - veya 0, kodu kontrol etmeniz gerekir) ve zfs_scrub_delay değerini 1 olarak değiştirin (veya 0, bunu destekler) ve txg_synctime_ms ayarınız 5000 veya daha fazla ise zfs_scan_min_time_ms'ı biraz değiştirirseniz, bazı kullanıcı G / Ç seviyelerinde bile fırçalama işlemleri yapma konusunda çok daha agresif hale gelmelidir.

Özel durumunuzda,% b ve asvc_t bildirilen bazı çok, çok rastgele okuma iş yükünün devam ettiğini ima eder (dönen diskler gerçekten sıralıysa bundan daha iyi olmalıdır) ve yukarıda açıklandığı gibi "kolay" şeyleri zaten yaptınız . Bu nedenle, önce fırçalama işlemlerinde önceden getirmeyi devre dışı bırakmak için, sadece bunun yardımcı olup olmadığını görmek için zfs_no_scrub_prefetch'i açarım. Sevinç yoksa, bulunduğunuz Nexenta sürümüne bağlı olarak - 30/5, 5/1 veya 10/5 çalıştırıyor olabilirsiniz (bu kısaca zfs_txg_timeout & (zfs_txg_synctime_ms * 1000) ayarları için kullanıyoruz. Zfs_txg_timeout değerini 10 ve zfs_txg_synctime_ms değerini 5000 olarak değiştirin, sonra zfs_scan_min_time_ms değerini 3000 veya 4000'e yükseltmeyi deneyin. dikkatli,

Bu yardımcı olur umarım. İyi şanslar!

— Nex7
kaynak

Ben bu ayarları bash "echo <tunable> / W0t <sayı> | mdb -kw" kullanarak değiştirmek gerektiğini varsayalım. Ve geçerli değerleri "echo <tunable> / D | mdb -k" ile görüntülersiniz. Notlarım, bunların hepsinin uçuşta değiştirilebileceğini söylüyor, hiçbiri / etc / sistem modifikasyonu gerektirmiyor ve etkili olması için yeniden başlatılıyor.

— Nex7

Ayrıca cevap vermeden önce tüm soruyu okumalıyım ve konferans görüşmeleri sırasında ServerFault'a göz atmayı bırakmalıyım. :)

— Nex7

Bildirilen% b ve asvc_t, bazı çok, çok rasgele okunan iş yükünün devam ettiğini gösterir (dönen diskler, gerçekten sıralıysa bundan daha iyi olmalıdır). İlk önce fırçalama işlemlerinde önceden getirmeyi devre dışı bırakmak için, sadece bunun yardımcı olup olmadığını görmek için zfs_no_scrub_prefetch'i açarım. Nexenta sürümüne bağlı olarak sevinç yoksa - 30/5, 5/1 veya 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000) sürümünü çalıştırıyor olabilirsiniz. Zfs_txg_timeout değerini 10 ve zfs_txg_synctime_ms değerini 5000 olarak değiştirip deneyin ! 3000 veya bu normal I / O'yu açlıktan olabilir, önlüğündeki artık çok geçirebilirsiniz ZFS'yi söyler 4000 zfs_scan_min_time_ms yükseltmişti

— Nex7

Çok değerli bir girdi sağladığınızı düşünüyorum, ancak yorumları iyi bir cevaba ekleyebilmeniz çok daha yararlı olacaktır.

— 3molo

2

Daha fazla ayarlama yardımcı olabilir, ancak zorunlu olmayabilir. ZFS fırçalama işleminin diskler üzerinde sektörlere göre DEĞİL veri yapısı boyunca yuvarlandığına dikkat etmek önemlidir. Yani, zfs veri yapısının disklerinizde nasıl göründüğüne bağlı olarak, bir ovma işlemi inanılmaz derecede rasgele görünebilir - diskleriniz> 100 MB / s sıralı okuma kapasitesine sahip olabilir , ancak tamamen rastgele okuma tamamen başka bir hikaye olacaktır . Ortalama blok boyutu da burada önemli olacaktır.

— Nex7

3

Donanımdan şüpheleniyorum ...

Bunun neden 15 gün çalışmasına izin verdin? Bu normal değil. Ovalamayı durdurun zpool scrub -s tankve sistemi kontrol edin.

Hangi denetleyicileri kullanıyorsunuz?
Bu, bu havuzda koştuğunuz ilk fırça mı?
İlk etapta fırçalamayı çalıştırmanızı isteyen bir sorun var mı?

— ewwhite
kaynak

1

LSI SAS9200-8e (BT ürün yazılımı). İlk fırçalama değil. Hayır, gerçek bir sorun yok (ama bir süredir sıralı okuma / yazma performansını sorguluyorum).

— 3molo

Gecikme ve bekleme süreleriyle güncellendi, hizmet istekleri için her zaman biraz zaman olduğundan ve fırçalamayı o kadar düşük önceliklendirdiğinden şüphelenmeye başlayana kadar durur. Herhangi bir fikir çok yararlı!

— 3molo

Ovmaların periyodik olarak çalışması önemlidir. Bir ovma çalıştırmak için bir sorun olana kadar beklemek, o sorunun veri kaybına patlamasını istiyor. Scrubs sessiz veri bozulması (bitrot) yakalamak için vardır. Yavaş çalışan bir ovma bir sistem sorununun işareti değildir, sadece ovmanın hızlanmasına izin vermeyecek kadar meşgul tutulan bir havuzdur.

— lschweiss

0

Cevabım biraz geç geliyor, ama bu tür bir şey başka birine olursa, işte benim almam: sadece "dmesg" yi deneyin. Benim durumumda, bir ovma yapmıyordum, ancak dosyaları disklere kopyalıyordum ve disklerin birkaç saniye boyunca aktif olduğunu açıkça duyuyordum, sonra daha uzun bir süre durdular ve tekrar çalışıyorlar vb. Bu bir SATA denetleyicisinin başarısızlığından kaynaklandı ve dmesg bana tüm hataları verdi. İlk başta arızalı bir disk olduğunu düşündüm, ama sonra aslında denetleyici olduğunu fark ettim.

— jytou
kaynak

-3

Scrub, boş bir sunucuda bile mevcut sistem kapalı kalma süresini kullanır, bu kullanılabilirlikle ilgilidir. Ram ve İşlemci, disk değil, kullanımı fırçalamanın anahtarlarıdır. Bunlardan ne kadar çok mevcutsa, fırçalama performansınız da o kadar iyi olur. Ancak, kesinlikle, bu durumda, diskleriniz ne kadar iyi yerleştirilirse, ZPools açısından, fırçalama performansınız da o kadar iyi olacaktır.

Dolayısıyla, performansınız yavaş olsaydı ve durum böyle görünüyorsa, bunlara potansiyel nedenler olarak bakardım.

— user169761
kaynak

1

Kaynakların az olduğuna dair bir gösterge görmüyorum.

— 3molo

1

Bu neredeyse tamamen yanlış. CPU ve RAM'in fırçalama işlemleri üzerinde etkili bir şekilde sıfır etkisi vardır (hiç boş alan olduğu varsayılırsa). Çok fazla boş RAM ve CPU'ya sahip olmak ovma işlemlerini 'hızlandırmaz'. Scrub, gelen I / O'yu havuza izlemekle sınırlıdır, 'mevcut sistem kapalı kalma süresini' kontrol ederek değil, ne olursa olsun.

— Nex7