ZFS havuzu yavaş sıralı okuma


10

Bu sorunla ilgili bir sorum var, ama çok karmaşık ve çok büyük oldu, bu yüzden sorunu NFS'ye ve yerel sorunlara bölmem gerektiğine karar verdim. Ayrıca bu konuda çok başarılı olmadan zfs-tartışmak posta listesinde sormaya çalıştım.

Aynı sunucudaki NFS / CIFS dizinleri arasında yavaş kopyalama

Anahat: Nasıl kuruluyorum ve ne bekliyorum

  1. 4 diskli bir ZFS havuz var. 2 TB KIRMIZI çizgili 2 ayna olarak yapılandırılmıştır (RAID 10). Linux'ta, zfsonlinux. Önbellek veya günlük cihazı yok.
  2. Veriler aynalar arasında dengelenmiştir (ZFS için önemlidir)
  3. Her disk, paralel olarak 147 MB ​​/ sn'de okuyabilir (ham w / dd), 588 MB / sn'lik bir toplam verim sağlar.
  4. Benzer bir 4 TB KIRMIZI diskin kıyaslamalarına dayanarak, her diskten yaklaşık 115 MB / sn yazma, 138 MB / sn okuma ve 50 MB / sn yeniden yazma bekliyorum. Herhangi bir disk bu gün bunu yapabileceğinden, en az 100MB / sn okuma veya yazma bekliyorum.
  5. Ben yük altında sıralı veri okuma veya yazma sırasında her 4 diskte% 100 IO kullanımını göreceğini düşündüm. Ve diskler% 100 kullanımda 100MB / sn'nin üzerinde olacaktı.
  6. Havuz bana tek bir disk üzerinde 2x yazma, 2x yeniden yazma ve 4x okuma performansı verecek düşündüm - yanılıyor muyum?
  7. YENİ Aynı havuzdaki bir ext4 zvolün ZFS ile aynı hızda olacağını düşündüm

Aslında ne elde ederim

Havuzun okuma performansının beklediğim kadar yüksek olmadığını görüyorum

birkaç gün önce havuzda bonnie ++ benchmark

Versiyon 1.97 ------ Sıralı Çıkış ------ - Sıralı Giriş- --Rastgele-
Eşzamanlılık 1 -Per Chr- --Block-- -Yeni Yaz- -Per Chr- --Block-- --Seeks--
Makine Boyutu K / sn% CP K / sn% CP K / sn% CP K / sn% CP K / sn% CP / sn% CP
igor 63G 99 99 232132 47 118787 27336 97 257072 22 92.7 6

tek bir 4TB RED sürücüde bir zpool içinde bonnie ++

Versiyon 1.97 ------ Sıralı Çıkış ------ - Sıralı Giriş- --Rastgele-
Eşzamanlılık 1 -Per Chr- --Block-- -Yeni Yaz- -Per Chr- --Block-- --Seeks--
Makine Boyutu K / sn% CP K / sn% CP K / sn% CP K / sn% CP K / sn% CP / sn% CP
igor 63G 101 99 115288 30 49781 14326 97 138250 13 111.6 8

Buna göre, tek bir 4TB RED sürücüden elde edilen sonuçlara göre okuma ve yeniden yazma hızları uygundur (bunlar çift). Ancak, beklediğim okuma hızı yaklaşık 550 MB / sn (4 TB sürücünün 4 katı) olacaktı ve en azından 400 MB / sn. Bunun yerine yaklaşık 260 MB / sn görüyorum

bonnie ++ şu andan itibaren havuzda, aşağıdaki bilgileri toplarken. Eskisi gibi değil ve hiçbir şey değişmedi.

Versiyon 1.97 ------ Sıralı Çıkış ------ - Sıralı Giriş- --Rastgele-
Eşzamanlılık 1 -Per Chr- --Block-- -Yeni Yaz- -Per Chr- --Block-- --Seeks--
Makine Boyutu K / sn% CP K / sn% CP K / sn% CP K / sn% CP K / sn% CP / sn% CP
igor 63G 103 99 207518 43 108810 24342 98 302350 26 256,4 18

yazma sırasında zpool iostat . Bana iyi geliyor.

                                                 kapasite işlemleri bant genişliği
havuz tahsis ücretsiz okuma yazma okuma yazma
-------------------------------------------- ----- - ---- ----- ----- ----- -----
havuz2 1.23T 2.39T 0 1.89K 1.60K 238M
  ayna 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 01007 1.60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0975 0 120M
  ayna 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

yeniden yazma sırasında zpool iostat . Bana iyi geliyor, sanırım .

                                                 kapasite işlemleri bant genişliği
havuz tahsis ücretsiz okuma yazma okuma yazma
-------------------------------------------- ----- - ---- ----- ----- ----- -----
havuz2 1.27T 2.35T 1015923125M 101M
  ayna 651G 1.18T 505465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198438 24.4M 51.7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306384 37,8M 45,1M
  ayna 651G 1.18T 510457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304371 37,8M 43,3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206423 25,5M 49,6M

Neler olup bittiğini merak ediyorum

okuma sırasında zpool iostat

                                                 kapasite işlemleri bant genişliği
havuz tahsis ücretsiz okuma yazma okuma yazma
-------------------------------------------- ----- - ---- ----- ----- ----- -----
havuz2 1.27T 2.35T 2.68K 32 339M 141K
  ayna 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92.5M 96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76.8M 96.8K
  ayna 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95,7M 56,0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74.0M 56.0K

iostat -x aynı okuma işlemi sırasında. IO% değerinin nasıl% 100 olmadığını unutmayın.

Cihaz: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz bekliyor r_await w_await svctm% util
sdb 0.60 0.00 661.30 6.00 83652.80 49.20 250.87 2.32 3.47 3.46 4.87 1.20 79.76
sdd 0.80 0.00 735.40 5.30 93273.20 49.20 251.98 2.60 3.51 3.51 4.15 1.20 89.04
sdf 0.50 0.00 656.70 3.80 83196.80 31.20 252.02 2.23 3.38 3.36 6.63 1.17 77.12
sda 0.70 0.00 738.30 3.30 93572.00 31.20 252.44 2.45 3.33 3.31 7.03 1.14 84.24

zpool ve test veri kümesi ayarları:

  • atime kapalı
  • sıkıştırma kapalı
  • ashift 0'dır (otomatik algılama - benim anlayışım bunun iyi olduğu yönündeydi)
  • zdb disklerin hepsinin ashift olduğunu söylüyor = 12
  • modül - seçenekler zfs zvol_threads = 32 zfs_arc_max = 17179869184
  • senkronizasyon = standart

Düzenle - 30 Ekim 2015

Biraz daha test yaptım

  • veri kümesi bonnie ++ w / recordsize = 1M = 226MB yazma, 392MB çok daha iyi okuma
  • veri kümesi dd w / kayıt boyutu = 1M = 260MB yazma, 392MB çok daha iyi okuma
  • ext4 dd bs ile zvol = 1M = 128MB yazma, 107MB okuma neden bu kadar yavaş?
  • paralel olarak veri kümesi 2 işlemesi = 227MB yazma, 396MB okuma
  • dd direct io veri kümesi ve zvol üzerinde fark yaratmaz

Artan kayıt boyutuyla performanstan çok daha mutluyum. Havuzdaki hemen hemen her dosya 1MB'ın üzerindedir. Ben de öyle bırakacağım. Diskler hala% 100 kullanılmıyor, bu da hala daha hızlı olup olmadığını merak ediyor. Ve şimdi zvol performansının neden bu kadar berbat olduğunu merak ediyorum, çünkü bu (hafifçe) kullandığım bir şey.

Yorumlarda / cevaplarda istenen bilgileri vermekten mutluluk duyuyorum. Diğer sorumda da tonlarca bilgi var: Aynı sunucuda NFS / CIFS dizinleri arasında yavaş kopyalama

Bir şeyi anlayamayabileceğimin ve bunun hiç de sorun olmayabileceğinin tamamen farkındayım. Şimdiden teşekkürler.

Açıklamak gerekirse soru şudur: ZFS havuzu neden beklediğim kadar hızlı değil? Ve belki de yanlış bir şey var mı?


1
Ayar yok, şüphelendim ... Diskleriniz için küllüğü ayarladınız mı? Herhangi bir zfs.conf ayarı var mı? Atime açık / kapalı mı? Tuhaf senkronizasyon ayarları var mı?
ewwhite

@ewwhite Soruya bazı ayrıntılar ekledim, teşekkürler
Ryan Babchishin

Şuna bakın: tomshardware.com/reviews/red-wd20efrx-wd30efrx-nas,3248-5.html WD Red sürücülerinin derin arama süreleri vardır. İyi akış yapıyorlar, ancak gerçek dünya kullanımı altında aramaları gerekecek ve IO istatistikleriniz, arama süresinin neredeyse kesinlikle performansınızı etkilediğine dair yeterli IO işlemi / sn gösteriyor. Bir zvol oluşturun ve ddne tür bir performans elde ettiğinizi görmek için kullanın . Ayrıca, önbellekten çift arabelleğe almanın performansı etkileyebileceği akış hızlarına girerken doğrudan IO'yu denemek isteyebilirsiniz. FWIW, teorik toplam ham 4 disk okuma performansının 3 / 4'ü iyi.
Andrew Henle

(boş alan bitti) Ayrıca, tek iş parçacıklı G / Ç işlemlerinin disklerinizi tam meşgul etmek için yeterli olmayabileceği kadar diskiniz var. Bu %utilrakamlarınızı açıklayabilir .
Andrew Henle

@AndrewHenle Teşekkür ederim. Kulağa çok makul geliyor. Şimdi buna bakacağım.
Ryan Babchishin

Yanıtlar:


10

Hızları beklediğim sayılara çok yakın tutmayı başardım.

Aradığım 400MB / sn ve yönetilen 392MB / sn . Yani diyorum ki sorun çözüldü. Daha sonra bir önbellek cihazı ekleyerek , 458MB / sn okuma başardım (önbellek inanıyorum).

1. Bu başlangıçta sadece ZFS veri kümesi recordsizedeğerinin1M

zfs set recordsize=1M pool2/test

Bu değişikliğin daha az disk etkinliği ile sonuçlandığını, dolayısıyla daha verimli büyük senkron okuma ve yazma ile sonuçlandığına inanıyorum. Tam olarak ne istediğimi.

Değişiklikten sonraki sonuçlar

  • bonnie ++ = 226MB yazma, 392MB okuma
  • dd = 260MB yazma, 392MB okuma
  • Paralel olarak 2 işlem = 227MB yazma, 396MB okuma

2. Bir önbellek cihazı (120 GB SSD) eklediğimde daha da iyi başardım. Yazma biraz daha yavaş, neden olduğundan emin değilim.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

Önbellek cihazı ile hile setine oldu l2arc_noprefetch=0yılında /etc/modprobe.d/zfs.conf . ZFS'nin akış / sıralı verileri önbelleğe almasını sağlar. Bunu yalnızca önbellek cihazınız benimki gibi dizinizden daha hızlıysa yapın.

Veri kümemdeki rekor boyut değişikliğinden yararlandıktan sonra, zayıf zvol performansı ile başa çıkmanın benzer bir yolu olabileceğini düşündüm.

Şiddetli insanlara a kullanarak iyi performans aldıklarını belirterek rastladım volblocksize=64k, denedim. Şanssız.

zfs create -b 64k -V 120G pool/volume

Ama sonra ext4'ün (test ettiğim dosya sistemi) RAID gibi strideve stripe-widthdaha önce hiç kullanmadığım seçenekleri desteklediğini okudum . Bu yüzden gerekli ayarları hesaplamak için bu siteyi kullandım: https://busybox.net/~aldot/mkfs_stride.html ve zvol'u tekrar biçimlendirdim.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

bonnie++Basit bir kıyaslama yapmak için koştum ve sonuçlar mükemmeldi. Ne yazık ki benimle sonuçları yok, ama hatırladığım gibi onlar yazma için en az 5-6x daha hızlı idi. Tekrar kıyaslarsam bu cevabı tekrar güncelleyeceğim.


1
Neredeyse bir yıl sonra geri gelip bu kadar ayrıntılı bir cevap yazdığınız için fazladan +1 verebilirsem, yapardım. Teşekkürler!
Jed Daniels

0

Beklentileriniz mükemmel değilken sonuçlarınız son derece makuldür: RAID1 (ve ek olarak RAID10 tarafından) verilen okuma performansı iyileştirmesini abartırsınız. Mesele şu ki, 2 yönlü yansıtma , tek diskin okuma hızını / GİB'lerini en fazla 2 kat verir , ancak gerçek dünya performansı 1x-2x arasında herhangi bir yerde olabilir.

Bir örnekle açıklığa kavuşalım. Her diskin 100 MB / s (sıralı) ve 200 IOPS kapasitesine sahip 2 yönlü aynaya sahip bir sisteminiz olduğunu düşünün. 1 (maks tek, üstün istek) bu dizinin bir kuyruk derinliği ile olacak hiçbir tek disk üzerinde avantaj: raıd1 iki diskin sıraya IO istekleri böler, ancak yok değil en azından (iki diskler üzerinde tek isteği bölmek, gördüğüm herhangi bir uygulama bu şekilde davranır). Diğer tarafta, IO kuyruğunuz daha büyükse (örneğin: 4/8 bekleyen isteğiniz varsa), toplam disk verimi tek diskten önemli ölçüde daha yüksek olacaktır.

RAID0 için benzer bir nokta yapılabilir, ancak bu durumda ortalama iyileştirmeleri belirleyen şey sadece kuyruk boyutunun değil, IO istek boyutunun da bir fonksiyonudur : ortalama IO boyutunuz yığın boyutundan küçükse, çizgili olmayacaktır . iki (veya daha fazla) diskte, ancak tek bir disk tarafından sunulacaktır. Artırılmış Bonnie ++ kayıt boyutu ile sonuçlarınız bu tam davranışı gösterir: şeritleme daha büyük IO boyutundan büyük ölçüde yararlanır.

Şimdi bir RAID10 dizide iki RAID seviyesini birleştirerek olacağı açık olmalıdır değil doğrusal performans ölçekleme yol, ancak bir ayarlar üst sınırı bunun için. Birden fazla dd / bonnie ++ örneği çalıştırırsanız (veya fiodoğrudan IO kuyruğunu manipüle etmek için kullanırsanız ), yalnızca IO dizinizi daha eksiksiz bir şekilde vergilendireceğiniz için orijinal beklentinizle daha uyumlu sonuçlar alacağınızdan eminim. birden fazla oustanding sıralı / rastgele IO isteği), tek başına tek, sıralı IO isteklerini yüklemek yerine.


Beklentilerim 400MB / sn. İle neredeyse aynıydı. 392MB / sn alıyorum. Mantıklı görünüyor. çok makul. Ben de birden fazla dd ve bonnie ++ süreçlerini paralel olarak çalıştırdım ve hiçbir performans artışı görmedim. Zvol performansının neden bu kadar kötü olduğunu açıklamamışsınız.
Ryan Babchishin

392 MB / sn sadece Bonnie ++ kullanarak büyük bir kayıt boyutu (> = 1 MB / sn) alıyorsunuz ve nedenini açıkladım. ZVOL üzerinden EXT4 hiç test etmediğim bir konfigürasyon, bu yüzden başkalarının yorum yapması için bıraktım.
shodanshok
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.