İlgisiz bazı noktalar:
80K birçok dosyadır.
Bir dizinde 80.000 dosya mı var? Hiçbir işletim sistemi veya uygulama varsayılan olarak bu durumu iyi işlemez. Sadece rsync ile bu sorunu fark ettiniz.
Rsync sürümünüzü kontrol edin
Modern rsync, büyük dizinleri geçmişe göre çok daha iyi işler. En son sürümü kullandığınızdan emin olun.
Eski rsync bile büyük dizinleri yüksek gecikme bağlantıları üzerinde oldukça iyi işler ... ama 80 bin dosya büyük değil ... çok büyük!
Bununla birlikte, rsync'in bellek kullanımı bir ağaçtaki dosya sayısıyla doğru orantılıdır. Büyük dizinler büyük miktarda RAM alır. Yavaşlık, her iki taraftaki RAM eksikliğinden kaynaklanabilir. Bellek kullanımını izlerken bir test çalıştırması yapın. Linux herhangi bir sol RAM'i disk önbelleği olarak kullanır, bu nedenle RAM'iniz azalırsa, disk önbelleği daha az olur. RAM'iniz biterse ve sistem takas kullanmaya başlarsa, performans gerçekten kötü olacaktır.
--Checksum'un kullanılmadığından emin olun
--checksum(veya -c) her dosyanın her bloğunun okunmasını gerektirir. Muhtemelen sadece değişiklik sürelerini (inode'da saklanan) okuma varsayılan davranışıyla başa çıkabilirsiniz.
İşi küçük gruplar halinde bölün.
Gigasync gibi "dizin ağacını geri almak için perl kullanarak iş yükünü doğrayarak , rsync ile aktarılacak küçük dosya listeleri oluşturacak" gibi bazı projeler var .
Ekstra dizin taraması büyük miktarda ek yük olacak, ancak belki de net bir kazanç olacaktır.
İşletim sistemi varsayılanları bu durum için yapılmamıştır.
Tüm varsayılanlarla Linux / FreeBSD / etc kullanıyorsanız, performans tüm uygulamalarınız için korkunç olacaktır. Varsayılanlar, daha büyük dizinlerde RAM'i boşa harcamamak için daha küçük dizinleri varsayar.
Büyük dizinleri daha iyi işlemek için dosya sisteminizi ayarlayın: Büyük klasör boyutları GÇ performansını yavaşlatır mı?
"Namei önbelleğine" bakın
BSD benzeri işletim sistemleri, inode ("namei" önbellek ") için bir isim aramayı hızlandıran bir önbelleğe sahiptir.Her dizin için bir namei önbellek vardır.Çok küçükse, bir optimizasyondan daha fazla bir engeldir. Her dosyada rsync bir lstat () yaptığı için, 80k dosyalarının her biri için inode'a erişilir.Bu önbelleğinizi patlatabilir. Sisteminizdeki dosya dizini performansını nasıl ayarlayacağınızı araştırın.
Farklı bir dosya sistemi düşünün
XFS, daha büyük dizinleri işlemek için tasarlanmıştır. Bkz. Dosya sistemi tek bir dizindeki çok sayıda dosya
Belki yapabileceğiniz en iyi şey 5 dakikadır.
Kaç tane blok bloğunun okunduğunu ve donanımın bu kadar çok bloğu okuyabilmesini ne kadar hızlı bekleyeceğinizi hesaplayın.
Belki beklentileriniz çok yüksek. Değişen dosyaları olmayan bir rsync yapmak için kaç disk bloğunun okunması gerektiğini düşünün: her sunucunun dizini okuması ve dosya başına bir inode okuması gerekir. Hiçbir şeyin önbelleğe alınmadığını varsayalım, çünkü 80k dosya muhtemelen önbelleğinizi patlattı. Diyelim ki matematiği basit tutmak 80k blok. Bu, birkaç saniye içinde okunması gereken yaklaşık 40M veri. Ancak, her blok arasında bir disk araması olması gerekiyorsa, bu çok daha uzun sürebilir.
Yani yaklaşık 80.000 disk bloğunu okumanız gerekecek. Sabit sürücünüz bunu ne kadar hızlı yapabilir? Bunun rastgele bir I / O olduğu göz önüne alındığında, uzun bir doğrusal okuma değil, 5 dakika oldukça mükemmel olabilir. Bu 1 / (80000/600) veya her 7,5 ms'de bir disk okunur. Sabit sürücünüz için hızlı mı yoksa yavaş mı? Modele bağlıdır.
Benzer bir şeye karşı karşılaştırma
Bunu düşünmenin başka bir yolu da bu. Hiçbir dosya değişmediyse, ls -Llraynı miktarda disk etkinliği yapar ancak hiçbir zaman dosya verisi okumaz (yalnızca meta veriler). ls -LlrKoşmak için gereken zaman üst sınırınızdır.
Rsync (dosya değiştirilmeden) önemli ölçüde yavaş ls -Llrmı? Ardından rsync için kullandığınız seçenekler geliştirilebilir. Belki -cetkinleştirilir veya yalnızca dizinlerden ve meta verilerden (inode verileri) daha fazlasını okuyan başka bir işaret.
Rsync neredeyse kadar hızlı (hiçbir dosya değişmiş ile) mı ls -Llr? Sonra rsync'i olabildiğince iyi ayarladınız. İşletim sistemini ayarlamanız, RAM eklemeniz, daha hızlı sürücüler almanız, dosya sistemlerini değiştirmeniz vb.
Geliştiricilerinizle konuşun
80k dosyaları sadece kötü tasarım. Çok az dosya sistemi ve sistem aracı bu tür büyük dizinleri çok iyi idare eder. Dosya adları abcdefg.txt ise, onları abdc / abcdefg.txt dosyasında saklamayı düşünün (tekrarlamaya dikkat edin). Bu, dizinleri daha küçük dizinlere ayırır, ancak kodda büyük bir değişiklik gerektirmez.
Ayrıca .... bir veritabanı kullanmayı düşünün. Bir dizinde 80 bin dosya varsa, geliştiricileriniz gerçekten istedikleri bir veritabanı olduğu gerçeğini araştırıyor olabilir. MariaDB veya MySQL veya PostgreSQL, büyük miktarda veri depolamak için çok daha iyi bir seçenek olacaktır.
Hey, 5 dakikadaki sorun ne?
Son olarak, 5 dakika gerçekten çok mu kötü? Bu yedeklemeyi günde bir kez çalıştırırsanız, 5 dakika çok zaman almaz. Evet, hızı seviyorum. Ancak 5 dakika müşterileriniz için "yeterince iyi" ise, o zaman sizin için yeterince iyidir. Yazılı bir SLA'nız yoksa, yedeklemelerin ne kadar hızlı gerçekleşmesini beklediklerini öğrenmek için kullanıcılarınızla resmi olmayan bir görüşme yapmaya ne dersiniz?
Performansı artırmaya ihtiyaç duyulmadıysa bu soruyu sormadığınızı varsayıyorum. Ancak, müşterileriniz 5 dakikadan memnunsa, zaferi beyan edin ve çabalarınızı gerektiren diğer projelere geçin.
Güncelleme: Bazı tartışmalardan sonra darboğazın ağ olduğunu belirledik. Ben vazgeçmeden önce 2 şey tavsiye edeceğim :-).
- Sıkıştırma ile borudan daha fazla bant genişliği sıkmaya çalışın. Ancak sıkıştırma daha fazla CPU gerektirir, bu nedenle CPU'nuz aşırı yüklenmişse performansı daha da kötüleştirebilir. Rsync'i olsun ve olmasın deneyin ve
-zssh'nizi sıkıştırma ile ve sıkıştırma olmadan yapılandırın. Herhangi birinin diğerlerinden önemli ölçüde daha iyi performans gösterip göstermediğini görmek için 4 kombinasyonun hepsini zamanlayın.
- Duraklama olup olmadığını görmek için ağ trafiğini izleyin. Duraklamalar varsa, bunlara neyin neden olduğunu bulabilir ve orada optimize edebilirsiniz. Eğer rsync her zaman gönderiyorsa, o zaman gerçekten sınırınızdasın. Seçimleriniz:
- daha hızlı bir ağ
- rsync dışında bir şey
- kaynağı ve hedefi birbirine yaklaştırın. Bunu yapamazsanız, yerel bir makineye rsync sonra gerçek hedefe rsync yapabilir misiniz? İlk rsync sırasında sistemin kapalı olması gerekiyorsa, bunu yapmanın faydaları olabilir.