Bir SATA 3.0 Arka Panel üzerinden 8x10 TB HDD'ye sahip bir Ubuntu 16.04 Yedekleme Sunucum var. 8 Sabit Disk bir RAID6'ya monte edilmiştir, bir EXT4 Dosya Sistemi kullanılmaktadır. Bu Dosya Sistemi, çok sayıda SEEK işlemi ancak düşük IO verimi olan çok sayıda küçük dosya depolar. Aslında her gün rsnapshot ile snappshotted olsun farklı sunuculardan birçok küçük dosya var (birden fazla INODES doğrudan aynı dosyalara. Dosya sistemi (60 TB net)% 50 kullanımı aştığı için çok kötü bir performans var. kullanımı% 75 ve

du -sch /backup-root/

birkaç gün sürer (!). Makine 8 Çekirdek ve 16G RAM'e sahiptir. RAM tamamen OS Dosya Sistemi Önbelleği tarafından kullanılır, 8 çekirdeğin 7'si IOWAIT nedeniyle her zaman boşta kalır.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Bu tür bir dosya sistemi kullanımı konusunda deneyimim yok. Bunu ayarlamak için hangi seçeneklere ihtiyacım var. Hangi dosya sistemi bu senaryoda daha iyi performans gösterir? İşletim sisteminde yerleşik olandan başka önbellek seçenekleri için RAM'i dahil etmek için herhangi bir seçenek var mı?

Büyük RAID derlemelerinde çok büyük miktarda küçük dosyayı nasıl ele alırsınız?

Teşekkürler Sebastian

Aynı amaçla ( rsnapshotyedekleme sunucusu) kullanılan bir RAID6 dizisinde 12 x 2 TB diskler ile benzer (daha küçük de olsa) bir kurulum var .

Birincisi, du -hsbu kadar büyük ve kullanılmış bir dosya sisteminde çok fazla zaman ayırmak normaldir . Ayrıca du, bariz IO yüküne ek olarak hatırı sayılır ve patlamış CPU yüküne neden olan hardlink'leri de hesaba katar.

Yavaşlığınız, dosya sistemi meta verilerinin çok uzaktaki (LBA terimleriyle) bloklarda bulunması ve birçok aramaya neden olmasından kaynaklanmaktadır. Normal bir 7.2K RPM disk yaklaşık ~ 100 IOPS sağladığından, gün olmasa bile tüm meta verilerin yüklenmesi için saatlerin nasıl gerektiğini görebilirsiniz.

Durumu (tahribatsız olarak) düzeltmeye çalışabileceğiniz bir şey:

• Emin için gereken değil sahip mlocate/slocatesizin indeksleme /backup-root/(kullanabileceğiniz prunefs tesisi kaçınmak buna) veya meta veri önbellek harman bozar yedek zaman severly edecektir;
• aynı nedenle, önlemek çalıştıran duüzerinde /backup-root/. Gerekirse, duyalnızca ilgili alt klasörde çalıştırın ;
• düşük vfs_cache_pressurebir daha tutucu bir (10 veya 20) için varsayılan değer (100). Bu, çekirdeğe veri önbelleğe almak yerine meta veri önbelleğe almayı tercih etmesini bildirir; bu da rsnapshot/rsynckeşif aşamasını hızlandırmalıdır ;
• örneğin, lvmcache veya bcache gibi bir meta veri önbellekleme cihazı eklemeyi deneyebilirsiniz . Bu meta veri cihazı açıkça bir SSD olmalıdır;
• kullanılabilir RAM'inizi artırın.
• ext4 kullanırken, inode tahsisi sorunlarına dikkat edin ( bir örnek için burayı okuyun ). Bu, performansla doğrudan ilişkili değildir, ancak bir uzantı tabanlı dosya sisteminde çok fazla dosya olduğunda önemli bir faktördür.

Deneyebileceğiniz diğer şeyler - ama bunlar yıkıcı operasyonlar:

• hem XFS kullanmak -ftypeve -finobtopsiyon seti;
• sıkıştırılmış ARC ve primarycache=metadataayar (ve belki de salt okunur önbellek için bir L2ARC ) ile Linux'ta ZFS (ZoL) kullanın .

Bu Dosya Sistemi, çok sayıda SEEK işlemi ancak düşük IO verimi olan çok sayıda küçük dosya depolar.

🎉

Bu, günümüzde birçok insanı yakalayan şey. Ne yazık ki, geleneksel FS'ler burada iyi ölçeklenmiyor. Zaten sahip olduğunuz kurulum söz konusu olduğunda muhtemelen birkaç tavsiye verebilirim: HDD'lerde RAID-6 üzerinden EXT4 :

1. Alt vm.vfs_cache_pressureO ediyorum 1. söylemek, aşağı önyargı önbellekleme değiştirmek yerine daha fazla veri meta verileri (düğüm, dentry) korunmasına yönelik kendisini ve yapmak istediği sayısının azaltılmasında olumlu etkisi olmamalıdır
2. Daha fazla RAM ekleyin . Herhangi bir piggy uygulaması çalıştırmayan bir sunucu için garip görünse de, unutmayın: aramaları azaltmanın tek yolu, daha fazla meta veriyi daha hızlı depolamada tutmaktır, ancak 16 GB'a sahip olduğunuz göz önüne alındığında, RAM miktarını artır
3. Söylediğim gibi EXT4 sahip olduğunuz kullanım durumu için iyi bir seçim değil, ama yine de ağrıyı yatıştırmak için sunduğu bazı özellikleri kullanabilirsiniz:
   • harici dergi desteklenir, böylece SSD (daha iyi yansıtılmış) eklemeyi deneyebilir ve günlüğü oraya yerleştirebilirsiniz. " Ext4: harici günlük uyarıları "
   • Günlük modunu "tüm veriler günlüğe kaydediliyor" bağlantısına geçirmeyi deneyindata=journal
4. Dosyaları tek bir FS kapsamı dışına taşımayı deneyin . Örneğin, burada LVM-2'niz varsa, daha küçük boyutlu hacimler oluşturabilir ve bunları bir süreliğine kullanabilirsiniz, daha sonra dolduğunda başka bir tane oluşturabilirsiniz.
   • LVM-2'niz yoksa bunu / dev / loop ile deneyebilirsiniz, ancak bu uygun değildir ve muhtemelen daha az performans gösterir

UPD. : Linux Yazılım RAID (LSR) RAID-6 olduğu ortaya çıktığından , ek öğe gider:

5. LSR'nin birçok kişinin göz ardı ettiği kendi ayar seçenekleri var
   • Bu şekilde maksimuma ayarlanabilen şerit önbellek : echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Ama boyutu dikkatli bir şekilde yapın (gerekirse daha az değer kullanın), çünkü boyut yığın büyüklüğünde birden fazladır ve seçtiğiniz yığın boyutuna bağlı olarak farklı miktarda RAM alacaktır
   • Aynalı SSD'lerde de bulunan harici günlük ( ancak şu anda günlük olmadan oluşturulan MD cihazı bir tane kullanmak için dönüştürülemez ).

- Muhtemelen sıfırdan yeniden tasarım olmadan geliştirilebilecek şeylerin çoğu.

Dosya sistemi (60 TB net)% 50 kullanımı aştığından çok kötü bir performansım var. Şu anda kullanım% 75

Bu çok ciddi bir sorun, çünkü yüksek disk alanı doluluk seviyesi sadece parçalanmayı kötüleştirdi. Ve daha fazla parçalanma demek daha fazla arayış demektir. % 50'ye ulaşmadan önce neden daha fazla veya daha az kabul edilebilir performans verdiğini merak etmeyin. Pek çok kılavuzda FS'lerin% 75-80'in arkasında büyümesine izin vermemek için açık önerileri vardır.

RAID6 bu durumda size çok yardımcı olmaz, ZFS gibi bir şey hızları aynı tutarken daha hızlı meta veri ve dizin erişimi sağlayabilir.

RAID-6 çizgili sürücüler, bu nedenle tüm IO tüm sürücülere gider. Bu birçok küçük dosya için oldukça verimsiz. Ancak bu muhtemelen ana sorun değil ...

Ext4 milyonlarca dosyaya sahip büyük dosya sistemleri için uygun değildir. XFS kullanın . 1,2 PB kadar büyük ve 1 milyar kadar dosya ile çalışan XFS dosya sistemim var, sorun değil. Sadece XFS kullanın .

Soruma cevap veren herkese teşekkürler.

Bu, nasıl çözdüm:

Her şeyden önce, panoya maksimum miktarda RAM ekledim. Maalesef, Kurul yalnızca 64GB'a kadar RAM'i destekliyor. Genişlemeden sonra davranışı gözlemledim ve hayal kırıklığı yarattı. Mevcut RAM'in tümü IO Cache için kullanılmasına rağmen, RSNAPSHOT-Backup'ın performansı ölçülebilir şekilde iyileşmedi.

Bu yüzden büyük topuzu çekmek zorunda kaldım. İki adet 1 TB NVME disk ekledim ve bunları bir RAID 1'e monte ettim. 8x 10 TB HDD'den oluşan RAID 6, bir RAID 1'e (2x 10 TB HDD, dahili 4'ü içerir) ve bir RAID 5'e (6x10 TB HDD'den oluşur) ayrıldı. RAID 1 artık İşletim Sistemini ve Sunucuların çalışma kopyasını içermektedir (bunlar bu sürücüye günde 4 kez yeniden bağlanır).

RAID5 artık NVME-RAID 1 tarafından desteklenen ve ext4 ile biçimlendirilmiş bir BCACHE destekli cihazdır. Bu sürücü RSNAPSHOT Kopyalarını içerir. Her gece dosyalar, çalışma kopyalarını VE yedek anlık görüntüleri içeren eski RAID6'ya kıyasla RAID5'in IO çıkışını yarıya indiren RAID1'den RAID5'e yeniden bağlanır. BCache sayesinde, kelimenin tam anlamıyla her bir dosya Disklere yazılmaz, ancak bir Bloktaki tüm değişiklikler, birkaç hunderth tek dosya değişikliği içeriyor olsa bile bir kez yazılır. Bu, HDD'lerdeki IOps'u daha da azalttı.

Son olarak, RSnapshot yapılandırmamı değiştirdim. Daha önce, 31 günlük anlık görüntü ve 18 aylık anlık görüntü vardı, bu da 49 yedek nesle sonuçlandı. Şimdi, klasik 7d / 4w / 12m / 1y-Design'a sahibim, bu da yedek nesillerin miktarını 24'e düşürüyor.

Bu değişikliklerden sonra (ve yukarıda belirtilen 64GB RAM ile), bir anlık görüntünün süresi ~ 20 saatten 1.5 saate düştü. BCache cihazlarının% 82'lik bir Önbellek İsabet oranı vardır (6 haftalık düzenli çalışmadan sonra).

Görev tamamlandı. Düşünceleriniz ve girdileriniz için hepinize teşekkürler.