ZFS performansı: havuzda veya dosya sisteminde boş alan bırakmam gerekir mi?

ZFS'nin performansının büyük ölçüde boş alan miktarına bağlı olduğunu biliyorum:

Havuz performansını korumak için havuz alanını% 80'in altında tutun. Şu anda, havuz çok dolu olduğunda ve meşgul posta sunucusunda olduğu gibi dosya sistemleri sık sık güncelleştirildiğinde havuz performansı düşebilir. Tam havuzlar performans cezasına neden olabilir, ancak başka sorunlara neden olmaz. [...]% 95-96 aralığında çoğunlukla statik içerik olsa bile yazma, okuma ve yeniden canlandırma performansının düşebileceğini unutmayın. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

Şimdi bir ZFS dosya sistemi barındıran 10T raidz2 havuzum olduğunu varsayalım volume. Şimdi bir çocuk dosya sistemi oluşturuyorum volume/testve 5T rezervasyon yapıyorum .

Sonra NFS başına her iki dosya sistemini de bazı ana bilgisayarlara bağlarım ve bazı işler yaparım. Anladığım kadarıyla volume5T'den fazla yazamıyorum , çünkü kalan 5T'ye ayrıldı volume/test.

Benim ilk soru nasıl performans düşüşü, ben dolgu Gözat eğer vardır volume~ 5T ile bağlama noktası? ZFS'nin yazma üzerine kopyalama ve diğer meta şeyler için bu dosya sisteminde boş alan olmadığı için düşecek mi? Yoksa ZFS ayrılmış alan içindeki boş alanı kullanabildiğinden aynı kalacak volume/testmı?

Şimdi ikinci soru . Kurulumu aşağıdaki gibi değiştirirsem fark eder mi? volumeşimdi iki dosya sistemi var volume/test1ve volume/test2. Her ikisi de 3T rezervasyon her (ama hiçbir kota) verilir. Şimdi 7T yazıyorum test1. Her iki dosya sisteminin performansı aynı mı olacak yoksa her dosya sistemi için farklı mı olacak? Düşecek mi yoksa aynı kalacak mı?

Teşekkürler!

Evet. Havuzunuzda boş alan bırakmanız gerekiyor. Temel olarak yazma üzerine kopyalama eylemleri ve anlık görüntüler içindir. Performans yaklaşık% 85 oranında azalır. Daha yükseğe çıkabilirsin, ama kesin bir etkisi var.

Rezervasyon ile uğraşmayın. Özellikle NFS ile. Gereksiz. Belki bir zvol için ama NFS için değil.

Yine de karışıklığı görmüyorum. 10T'niz varsa,% 85'inden fazlasını kullanmayın. Kullanımlarını sınırlamak için kotaları kullanarak paylaşımlarınızı uygun şekilde boyutlandırın . Veya herhangi bir kota kullanmayın ve genel havuz kullanımınızı izleyin .

Performans düşüşü, zpool'unuz çok dolu veya çok parçalı olduğunda gerçekleşir. Bunun nedeni ZFS ile birlikte kullanılan serbest blok keşfi mekanizmasıdır. NTFS veya ext3 gibi diğer dosya sistemlerinin aksine, hangi blokların meşgul olduğunu ve hangilerinin ücretsiz olduğunu gösteren bir blok bitmap'i yoktur. Bunun yerine ZFS, zvolünüzü "metaslabs" olarak adlandırılan (genellikle 200) daha büyük alanlara böler ve her metaslab'da AVL ağaçlarını ¹ serbest blok bilgisi (uzay haritası) saklar. Dengeli AVL ağacı, isteğin boyutuna uyan bir blok için verimli bir arama yapılmasını sağlar.

Bu mekanizma ölçeklendirme nedenleriyle seçilmiş olsa da, maalesef yüksek düzeyde parçalanma ve / veya alan kullanımı söz konusu olduğunda büyük bir ağrı olduğu ortaya çıkmıştır. Tüm metaslablar önemli miktarda veri taşıdığı anda, havuz boşken az sayıda büyük alanın aksine çok sayıda küçük ücretsiz blok alanı elde edersiniz. Daha sonra ZFS'nin 2 MB alan tahsis etmesi gerekiyorsa, uygun bir blok bulmak veya 2 MB'yi daha küçük bloklara bölmenin bir yolunu bulmak için tüm metaslab'ların alan haritalarını okumaya ve değerlendirmeye başlar. Bu elbette biraz zaman alıyor. Daha da kötüsü, ZFS'nin aslında fiziksel disklerdeki tüm uzay haritalarını okuyacağı için bir çok G / Ç işlemine mal olacağıdır . İçin herhangi senin yazma.

Performanstaki düşüş önemli olabilir. Güzel resimlerden hoşlanıyorsanız , bazı numaraların (basitleştirilmiş ancak geçerli) bir zfs havuzundan çıkarıldığı Delphix'deki blog yayınına bir göz atın . Grafiklerden birini utanmadan çalıyorum - bu grafikteki mavi, kırmızı, sarı ve yeşil çizgilere (sırasıyla)% 10,% 50,% 75 ve% 93 kapasitede havuzları temsil eden KB / s zamanla parçalanırken:

Bu hızlı ve kirli bir düzeltme geleneksel olarak metaslab hata ayıklama modu olmuştur (sadece echo metaslab_debug/W1 | mdb -kwayarı anında değiştirmek için çalışma zamanında sorun ). Bu durumda, tüm yazma haritaları OS RAM'de tutulur ve her yazma işleminde aşırı ve pahalı G / Ç gereksinimi ortadan kaldırılır. Nihayetinde bu, özellikle büyük havuzlar için daha fazla belleğe ihtiyacınız olduğu anlamına gelir, bu nedenle at ticareti için bir tür RAM'dir. 10 TB havuzunuz muhtemelen 2-4 GB bellek ^2'ye mal olacak , ancak çok fazla uğraşmadan kullanımın% 95'ine çıkarabilirsiniz.

¹ biraz daha karmaşık, eğer ilgileniyorsanız, ayrıntılar için Bonwick'in uzay haritalarındaki yazısına bakın

² bellek için bir üst sınır hesaplamanın bir yoluna ihtiyacınız varsa , her bir metaslab'de kullanılmakta zdb -mm <pool>olan sayısını almak için segmentskullanın, en kötü senaryoyu modellemek için ikiye bölün (her işgal edilen segmentin ardından ücretsiz bir tane gelir) ), bir AVL düğümü için kayıt boyutuyla çarpın (iki bellek işaretçisi ve bir değer, zfs'nin 128 bit doğası ve 64 bit adreslemenin 32 bayta kadar toplanması göz önüne alındığında, insanlar genellikle bazıları için 64 bayt varsayıyor gibi görünüyor) sebebi).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Referans: Temel taslak, Markus Kovero tarafından zfs-tartışmalı posta listesindeki bu gönderide yer alsa da, hesaplamamda benim düzeltmeyi umduğum bazı hatalar yaptığına inanıyorum.