Soru ZFS anlık görüntü geri alma hızı, dosya sayısına bağlıdır mu?


Ana bilgisayardan 10GB'lık bir dosya okuyabilmemiz ve net2, hızın 410MB / s olduğu netcat kullanarak host2'ye yazabilmesi için iki ana bilgisayar arasında 10Gbit bağlantı test ettim.

ZFS, aynı özel 10Gbit bağlantısı üzerinden netcat ile tekrar gönderdiğimde / alırken sadece 70MB / s alırım. Anlık görüntü 15 milyon dosya ile 2,5 TB oldu.

Soru

Bu yavaşlamanın nedeni ne olabilir? Bu çok sayıda dosya ile bir anlık görüntü geri almak için çok zaman harcadığı darboğaz mı, yoksa dosya sayısı ZFS geri alma hızını etkilemiyor mu?

Güncelleştirme

Ben 410MB / s var nerede 10GB dosya aktarma testi varsayalım ZFS gönderme / alma geri alma ile simüle eder varsayalım. Bu varsayımla çok farklı hızları gördüğüm için çok şaşırdım. İki test arasında karşılaştırma yapmak için hız kullanıyorum, bu yüzden rastgele verilerle bir 2.5TB dosyası oluşturmak zorunda değilim.

Bu yüzden "host1 dosyasından dosya oku, netcat ile aktarma, host2 dosyasına dosya yaz" nedeninin "zfs host1'den anlık görüntü aktarımı, netcat ile aktarımı, host2'de ZFS alma / geri alma" dan daha hızlı olduğunu anlamıyorum.

Belki de aynı şeyi sormanın başka bir yolu olabilir:

Eşit boyutta iki 2,5TB anlık görüntü varsa, anlık görüntü1 1 dosya içeriyor ve anlık görüntü2 15 milyon dosya içeriyor. Zamanı zfs receive ikisi için de aynı mı? Yoksa diğerinden daha hızlı mı olacak?


7
2018-05-30 13:42


Menşei


Sanırım 15 milyon dosyanın daha fazlası var. Sonuçta, büyük bir dosya yerine, nispeten küçük dosyaları taşıyorsunuz. - Nathan C
Bu, tüm dosya sistemi bloğu yerine her dosya için küçük bir anlık görüntü oluşturulduğu anlamına mı geliyor? - Sandra
Muhtemelen bu noktada bir G / Ç darboğazına isabet ediyorsunuz. Bu yavaşlamayı neredeyse tüm dosya sistemlerinde görüyorsunuz. - Nathan C
Bu soru beni biraz karıştırıyor, netcat @ 410 MB / s kullanarak bir dosya aktardığınıza göre, daha sonra 70 MB / sn netcat üzerinden zfs send / recv aktardı. Sonra da ZFS geri dönüş hızını meniton. Orijinal aktarım bir zfs gönder / recv mi, değil mi? ZFS geri dönüşü burada devreye giriyor? - Nex7
Öyle, teşekkürler. Zfs gönder / recv ile kendi geçmişime dayanarak uygun bir cevap olduğunu düşündüğüm dosyalara başvurdum. (zfs gönderme / recv yaparken havuzda devam eden diğer G / Ç miktarının da önemli olduğunu, ama mbuffer çözüm gerçekten de hafifletir varsayarak, o da orada lulls varsayarak anmak için söz değil gönderim dışı / yeniden G / Ç). - Nex7


Cevaplar:


Bir zfs gönderme / yeniden akışta yer alan dosya ve dizinlerin sayısının aktarım hızı üzerinde doğrudan bir etkisi olmamalıdır. Dolaylı olarak, belki de, veri kümesinin disklerinizin “yayılması” nın, bunları oluşturan iş yüküne bağlı olarak daha fazla dizin / dosya ile daha yüksek olacağını söylemek doğrudur. Bu önemlidir, çünkü bir sabit diskin rasgele okunandan daha fazla sıralı bir okuma yapması çok daha kolaydır - ve eğer söz konusu akış diskin her tarafındaysa, sıralı olmayandan daha fazla rastgele bir okuma iş yükü olacaktır.

Ayrıca, benim ZFS dosya sistemlerinde (zvols üzerinde değil) dosyalarda yer alan ZFS meta verisi benim anlayışım; Doğrudan sayılarım yok, ama 2.5 TB'lık bir dosya için, genel olarak, 15 milyon dosyayla dolu 2,5 TB'dan çok daha az metadata bloklarına sahip olmaktan dolayı kendimi tutamazdım. Bu (potansiyel olarak fazla) ekstra meta veri blokları okunması gereken daha fazla veri ekleyecektir, böylece daha fazla disk okuma (ve potansiyel olarak arama) devam edecektir. Evet, dolaylı olarak, 15 milyon dosyadan oluşan bir gönderme akışının, aynı boyutta tek bir dosyadan (örneğin, bir dosya aynı anda oluşturulduysa, sıralı bir yazım olarak) oluşturulmasından daha yavaş olabileceği olasıdır. o anda bitişik boş alan bol bir havuzda).

Çok lekeli performansa sahip olmak için sıkıştırılmamış olarak gönderilen ZFS gönderim / tekrar akışları için çok yaygındır - zaman zaman oldukça hızlı ilerler gibi görünmektedirler, bu da potansiyel olarak uzun süreler boyunca neredeyse hiçbir şeye düşmeyecektir. Davranış, internet üzerindeki çeşitli forumlarda bir ölçüde tanımlanmış ve hatta analiz edilmiştir, bu yüzden ona girmeyeceğim. Genel olarak, ZFS'nin dahili olarak daha verimli bir iş akışı yapmak için bazı çalışmaları yapması ve yapması gerektiğinde, bir çok sorun için 'hızlı düzeltme', gönderen ve alan tarafa bir tampon getirmektir. Bunun için en yaygın araç 'mbuffer'.

Zfs'nizi pipetleyerek, netcat'ten önce mbuffer'ı göndererek (ve yine zfs recv'den önce mbuffer ile), temel sorun bir arabellek eklemenin yardımcı olabileceği bir durumdur. Alasdair'in blogunun üzerinde bir yazmacın yazılması var - şu anda bu konuyla ilgili yayınlanmış bir şeyim yok, bu yüzden size şunları göstereceğim: http://blogs.everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/


5
2018-06-01 06:12



Gerçekten gerek yok netcat mbuffer kullanırken - the-wabbit


Büyük hız farkının nedeni, bir dosya ve anlık görüntü aktarmanın karşılaştırılamamasıdır. Bir dosya sıralı I / O'dur ve bir anlık görüntü değişmiş olan blokları içerdiğinden rasgele G / Ç'dir.


-2
2018-06-08 15:50



Bu teknik olarak doğru değil. Sıralı bir anlık görüntü ve sıralı olmayan bir dosya, ZFS'de hem tamamen mümkündür (çevreye bağlı olarak da mümkündür). Bir dosya üzerinden okuma yapmanın ardışık bir G / Ç'yi temsil edeceğine dair bir garanti yoktur; bu, artımlı bir anlık görüntüden okunmanın ardışık olmayan G / Ç'yi temsil edeceğinin garantisidir. Birinin olasılıkları muhtemelen diğerinden daha rasgele olma olasılıklarıdır, fakat garanti etmez. Üzgünüm, ama bu sadece yanlış. - Nex7