Çok sayıda küçük dosyayı depolamak için en yüksek performanslı Linux dosya sistemi nedir (SSD değil, HDD)?


43

Birçok küçük dosya ve az sayıda daha büyük dosya içeren bir dizin ağacım var. Bir dosyanın ortalama boyutu yaklaşık 1 kilobayttır. Ağaçta 210158 dosya ve dizin var (bu sayı çalıştırılarak elde edildi find | wc -l).

Dosyaların küçük bir yüzdesi, haftada birkaç kez eklenir / silinir / yeniden yazılır. Bu, küçük dosyalar ve (az sayıda) büyük dosyalar için geçerlidir.

Çalıştığım dosya sistemlerinde (ext4, btrfs) diskteki dosyaların konumlandırılmasında bazı problemler var. Daha uzun bir süre zarfında, diskteki dosyaların fiziksel konumları (sabit disk değil, dönen medya) daha rasgele dağıtılır. Bu rastgele dağıtımın olumsuz sonucu, dosya sisteminin yavaşlamasıdır (örneğin: yeni bir dosya sisteminden 4 kat daha yavaş).

Bu performans düşüşünden etkilenmeyen ve dönen bir ortam üzerinde sabit bir performans profili sağlayabilen bir Linux dosya sistemi (veya bir dosya sistemi bakım yöntemi) var mı? Dosya sistemi Sigorta üzerinde çalışabilir, ancak güvenilir olması gerekir.


Hangi dosyaların çok sık olacağını veya çok sık değişmeyeceğini ve hangilerinin küçük / sık sık değişeceğini biliyorsanız, her senaryoda daha uygun, üzerinde farklı seçeneklere sahip iki dosya sistemi oluşturmak isteyebilirsiniz. Aynı yapının bir parçası oldukları için erişilebilir olmalarına ihtiyaç duyuyorsanız, mount, symlinks ile bazı hileler yapabilirsiniz.
Marcin

Btrfs'in (yazma üzerine yazma özelliği ile) belirli bir süre boyunca size halsiz kaldığını bilmek beni şaşırttı. Sonuçların sizden paylaşılmasını merak ediyorum, muhtemelen birbiriyle performansın ayarlanması yönünde birbirimize yardımcı oluyoruz.
Nikhil Mulley

Linux'ta çevrimiçi bir zfs var, doğal modda mevcut ve sigorta uygulamaları var.
Nikhil Mulley,

Bir zamanlar Linux'ta zfs'i denedim, dengesizdi. Sık sık dosya sistemini tamamen kilitlemeyi başardı. Kutu çalışır, ancak FS'ye herhangi bir erişim askıda kalır.
Patrick

Yanıtlar:


47

Verim

Hangi dosya sisteminin yüz binlerce küçük dosya ile en iyi performansı gösterdiğini bulmak için küçük bir Benchmark ( kaynak ) yazdım :

  • / dev / urandom verilerinden 300000 dosya (512B - 1536B) oluşturun
  • 30000 rasgele dosyayı yeniden yazmak ve boyutunu değiştirmek
  • 30000 sıralı dosyayı oku
  • 30000 rastgele dosyayı oku
  • tüm dosyaları sil

  • Her adımdan sonra önbelleği senkronize et ve bırak

Sonuçlar (saniye cinsinden ortalama süre, daha düşük = daha iyi):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Sonuç:
Ext4'ün genel performansı iyi olsa da, ReiserFS sıralı dosyaları okurken çok hızlıydı. XFS'nin birçok küçük dosyada yavaş olduğu ortaya çıktı - bu kullanımda kullanmamalısınız.

Parçalanma sorunu

Dosya sistemlerinin sürücü üzerine dosya dağıtmasını engellemenin tek yolu, bölümü yalnızca gerçekten ihtiyaç duyduğunuz kadar büyük tutmaktır, ancak bölmeyi parçalamayı önlemek için bölmeyi çok küçük yapmamaya dikkat edin. LVM kullanmak çok yardımcı olabilir.

daha fazla okuma

Arch Wiki'de dosya sistemi performansı ile ilgili bazı harika makaleler var:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices


4
Çekirdeğin hangi sürümünün bu karşılaştırmaya dayandığını belirtmelisin. XFS, son çekirdeklerden birinde çok önemli bazı hız geliştirmeleri elde etti (bunun 2.6.31 olduğunu düşünüyorum, ama benden alıntı yapma).
Patrick

1
btrfs dahili olarak numaralarınızı yapar. Diskin daha küçük parçalarını ayırır ve dosyaları bu parçalara yerleştirir, ardından yalnızca varolan parçalar doldurulduğunda başka bir disk parçası ayırır.
psusi

1
Bu herhangi bir dosya sistemi için geçerlidir. Bu nedenle uygulamalar fsync () gibi şeyleri kullanır.
psusi

2
@taffer, öyle. İşlemler, diğer dosya sistemlerinde dergi ile aynı etkiye sahiptir: fs meta verilerini korurlar. Teoride, uygulamalar tarafından tanımladığınız şekilde kullanılabilirler, ancak uygulamaların işlemleri açma ve kapatmalarına izin verecek hiçbir api yoktur.
psusi

1
@taffer "Son kriteriniz", Nisan 2015'ten itibaren üç yaşın üzerinde ve XFS'i yalnızca varsayılan seçeneklerle kullanıyor. Bu, XFS v5'i varsayılan ve getirdiği tüm avantajlar yapan xfsprogs 3.2.3 tarihini belirtir. Ayrıca, küçük dosyalar ve ağır meta veri güncellemeleri ile XFS performansı için bir oyun değiştirici olan -m finobt = 1 ile biçimlendirilmedi. Hayır, gümüş mermi yoktur, ancak fikirlerinizi eski ölçütlere dayandırmak akıllıca değildir, özellikle de büyük performans değiştiren özellikler göz ardı edildiğinde, kullanılamaz durumdayken veya devre dışı bırakıldığında, akıllıca olmaz.
Jody Lee Bruchon

7

ReiserFS'yi bu görev için kullanıyorum, özellikle birçok küçük dosyayı işlemek için yapılmış. Funtoo wiki'de bununla ilgili metni okumak kolay .

ReiserFS ayrıca, özellikle küçük dosya performansını iyileştirmeyi amaçlayan bir dizi özelliğe sahiptir. Ext2'den farklı olarak, ReiserFS sabit bir k veya dört k bloğunda depolama alanı ayırmaz. Bunun yerine, ihtiyacı olan tam boyutu tahsis edebilir.


1
ReiserFS'de de istikrar sorunları var - bu yüzden RH ve SuSE, FS'yi düşürdüler. İlkeden itibaren (BTree-tabanlı-FS) BTRFS karşılaştırılabilir olmalıdır.
Nils


0

Bu gibi durumlarda XFS'nin çok iyi performans gösterdiği belirtiliyor. Bu benim iş yerimde posta depolarımızda (1 dizinde yüz binlerce dosya içerebilen) neden kullandığımızın bir parçası. ReiserFS'den daha iyi hata toleransına sahiptir, daha geniş kullanım alanı vardır ve genellikle çok olgun bir dosya sistemidir.

Ek olarak, XFS çevrimiçi birleştirmeyi de destekler. Başlamak için daha az parçalanma ile sonuçlanan gecikmeli bir tahsis tekniği kullanmasına rağmen (diğer dosya sistemlerine karşı).


20
Bu gibi durumlarda XFS'nin çok iyi performans gösterdiği belirtiliyor. [kaynak belirtilmeli]
saat

8
Ehm, xfs özellikle bunun tam tersi olarak bilinir: büyük dosyalar ile gerçekten iyi çalışmak, ama küçük dosyalar üzerinde iyi değil! Örneğin bu ayrıntılı teste
Levite

1
@Levit O raporu yanlış okuduğunu düşünüyorum. Rapor açıkça açıkça gösteriyor ki, XFS rastgele IO için çok iyi performans gösteriyor. Ancak bu bir yana, rapor bu sorudaki senaryo türünü ve birçok dosyayı ele almamaktadır. Rasgele IO bir şeydir, ext * yüzünün üstüne düştüğü yerde çok sayıda dosya vardır.
Patrick

2
XFS'in gerçekten iyi olduğu tek yer, rasgele okuma / yazma işlemleri var (mekanik bir disk üzerinde gerçekten rastgele bir okuma düzeninin 10 MB / sn alabilmesi garip görünüyor - gerçek dünyada uçmayan bazı optimizasyonlar gibi görünüyor). (imho)), sayfa 7'de daha önce söylediklerimi gösterse de, XFS büyük dosyaları işlemede gerçekten iyidir! Sayfa 3 ve 5'e bakın, özellikle de 3'teki dosyada, harici dosyalarda olduğu gibi net olmayan küçük dosyaları da işlediğini görebilirsiniz! Gerçekte XFS'e karşı hiçbir şeyim yok, ancak hemen hemen her yerde bulduklarınızdan, birçok küçük dosya için en iyiyim değil, tek söylediğim bu!
Levite

5
XFS , büyük dosyalar söz konusu olduğunda, bu dosyalar uzun bir süre boyunca küçük parçalarla rasgele / yavaş genişletilirse, son derece yavaş olabilir . (Tipik syslogdmodel.) Örneğin, MD kurulumunun üzerindeki bir XFS'de yanımda, bir 1,5 GB'lik bir dosyanın kaldırılmasının 4.75 dakika (!) Sürdüğünü, disk sürücüsünün yazma hızında 100 işlem / sn sınırında kapatıldığını gördüm. 2 MB / sn'den daha fazla. Bu aynı zamanda, sürücü zaten maksimize edildiğinden, aynı paraleldeki diğer paralel giden IO işlemlerinin performansını da olumsuz etkiler. Başka bir FS'de (ya da kıyaslamalarda test edilmek) hiç böyle bir şey görmedim.
Tino
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.