Neden rsync NFS'den daha hızlı?

Birkaç gün önce biraz tuhaf bir şey farkettim (en azından benim için). Aynı veriyi kopyalayıp rsync'i çalıştırdım ve ardından NFS mount'a sildim /nfs_mount/TEST. Bu /nfs_mount/TESTbarındırılıyor / ihraç ediliyor nfs_server-eth1. Her iki ağ arabirimindeki MTU 9000'dir, aradaki anahtar jumbo çerçeveleri de destekler. Bunu yaparsam rsync -av dir /nfs_mount/TEST/X MBps ağ aktarım hızını alıyorum. Bunu yaparsam rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ağ aktarım hızını en az 2X MBps olarak alıyorum. Benim NFS seçeneklerdir bağlama nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Alt satır: her iki transfer de aynı ağ alt ağı üzerinden, aynı kablolar, aynı arabirimler, aynı verileri okur, aynı dizine yazarlar, vb. Üzerinden gider.

İstemci Ubuntu 10.04, sunucu Ubuntu 9.10'dur.

Neden bu kadar hızlı? NFS bu hızda eşleşir mi?

Teşekkürler

Düzenleme: lütfen NFS paylaşımına veya SSH'ye NFS sunucusuna yazmak ve orada yerel olarak yazmak için rsync kullandığımı unutmayın. İki kere rsync -avde temiz hedef dizini ile başlıyorum. Yarın düz kopya ile deneyeceğim.

Düzen2 (ek bilgi): Dosya boyutu 1KB-15MB arasındadır. Dosyalar zaten sıkıştırılmış, başarılı olmadan daha fazla sıkıştırmaya çalıştım. Bundan tar.gzdosya yaptım dir. İşte kalıp:

• rsync -av dir /nfs_mount/TEST/ = en yavaş aktarım;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= jumbo çerçeveleri etkinleştirilmiş en hızlı rsync; jumbo çerçeveler olmadan biraz daha yavaştır, ancak doğrudan NFS'ye göre çok daha hızlıdır;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = tar.gz olmayan eşdeğeri ile aynıdır;

İle Testleri cpve scp:

• cp -r dir /nfs_mount/TEST/= biraz daha hızlı rsync -av dir /nfs_mount/TEST/ancak yine de önemli ölçüde yavaş rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= genel olarak en hızlı, biraz üstesinden gelir rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = tar.gz olmayan eşdeğeri ile aynıdır;

Sonuç, bu sonuçlara dayanarak: Bu test için tar.gz large file veya pek çok küçük dosya kullanılıyorsa, önemli bir fark yoktur. Jumbo çerçeveleri açık veya kapalı da neredeyse hiç farketmez. cpve scpkendi rsync -aveşdeğerlerinden daha hızlıdır . Dışa aktarılan NFS paylaşımına doğrudan yazmak, kullanılan yönteme bakılmaksızın, SSH üzerinden aynı dizine yazmaktan önemli ölçüde yavaştır (en az 2 kez).

Arasındaki farklar cpve rsyncbu durumda ilgili değildir. Ben denemeye karar verdi cpve scp2X farkı - Aynı model göstermek ve yaptıkları sadece görmek için.

Kullandığım rsyncveya cpher iki durumda da, NFS'nin aynı komutların SSH üzerinden aktarım hızına ulaşmasını neyin engellediğini anlayamıyorum.

NFS paylaşımına yazma neden SSH üzerinde aynı yere yazmaktan 2 kat daha yavaş?

Edit3 (NFS sunucu / etc / ihracat seçenekleri): rw,no_root_squash,no_subtree_check,sync. Müşterinin / proc / mounts gösterileri: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Hepinize teşekkür ederim!

Belki daha yavaş aktarım hızı değildir, ancak yazma gecikme süresini arttırır. NFS paylaşımını senkronizasyon yerine bağlamayı deneyin ve bunun hız farkını kapatıp kapatmadığını kontrol edin. Ssh üzerinden rsync yaptığınızda, uzak rsync işlemi zaman uyumsuz olarak (hızlı bir şekilde) yazar. Ancak eşzamanlı olarak monte edilmiş nfs paylaşımına yazarken, yazma işlemleri hemen onaylanmaz: NFS sunucusu, NFS istemcisine yazma işleminin başarılı olduğuna dair onay göndermeden önce diske (veya denetleyici önbelleği büyük olasılıkla) çarpana kadar bekler.

Eğer 'async' probleminizi çözerse, NFS sunucusuna orta yazma işleminde bir şey olursa, diskte tutarsız verilerle sonuçlanabileceğini unutmayın. Bu NFS bağlantısı bu (veya başka herhangi bir) veri için birincil depolama olmadığı sürece, muhtemelen iyi olacaksınız. Tabii, eğer rsync-over-ssh çalıştırılırken / sonrasında nfs sunucusundaki fişi çektiğinizde aynı teknede olacaktınız (örneğin, rsync 'bitmiş' iadeler, nfs sunucusu çöküyor, yazma önbelleğindeki veriler artık kayboluyor) diskte tutarsız veri bırakmak).

Testinizle ilgili bir sorun olmasa da (yeni verileri rsyncing), ssh üzerinden rsync'in sağlama toplamlarını hesaplarken ve olması gereken dosyaların listesini oluştururken tek bir bayt aktarılmadan önce uzak sunucuda önemli CPU ve IO talepleri yapabileceğini unutmayın. güncellenmiş.

NFS bir paylaşım protokolüdür, Rsync ise dosya transferleri için optimize edilmiştir; Amacınızın, paylaşılan erişim sağlamak yerine dosyalarınızı olabildiğince hızlı kopyalamak olduğu konusunda bir öncül bildiğiniz zaman yapabileceğiniz birçok optimizasyon vardır .

Bu yardımcı olacaktır: http://en.wikipedia.org/wiki/Rsync

Rsync, dosyalar arasında yalnızca değişen bitleri aktaran bir dosya protokolüdür. NFS her seferinde her şeyi işleyen uzak bir dizin dosya protokolüdür ... bir çeşit SMB gibi. İkisi farklı ve farklı amaçlar için. İki NFS paylaşımı arasında aktarmak için Rsync'i kullanabilirsiniz.

Bu ilginç. Göz önünde bulundurmadığınız bir olasılık, ilettiğiniz dosyanın içeriği / türüdür.

Küçük dosyalara sahip scadleriniz varsa (örneğin, tek tek dosyalardaki e-posta adresleri), NFS verimliliği tam MTU’nun kullanılmamasından kaynaklanıyor olabilir (belki de bu durum UDP üzerinden TCP ile daha düşüktür).

Alternatif olarak, yüksek oranda sıkıştırılabilir dosyalara / verilere, hızlı CPU'lara ve oldukça yüksek CPU hızına sahip olmayan bir ağa (*) sahipseniz, yalnızca ssh bağlantısı üzerindeki örtük sıkıştırma işleminden hız alabilirsiniz.

Üçüncü bir olasılık, dosyaların (veya bunların bir sürümünün) hedefte zaten mevcut olmasıdır. Bu durumda, hızlanma, rsync protokolünün dosyaları aktarırken kaydettiğinizden dolayı olacaktır.

(*) Bu durumda 'hız' ile, CPU'nun ağın veri aktarma hızına kıyasla verileri sıkıştırabileceği hızdan bahsediyorum, örneğin kablo üzerinden 5MB göndermek için 5 saniye sürüyor, ancak CPU Bu 5 MB’ı 1 saniyede 1 MB’ye sıkıştırabilir. Bu durumda, sıkıştırılmış verilerin iletim süresi 1 saniyenin biraz üzerinde olurken, sıkıştırılmamış veriler 5 saniyedir.

Verimi artırmak için -e "ssh Ciphers = arcfour" komutunu da kullanıyorum.

Amacınız tüm dosyaları bir yerden başka bir yere kopyalamaksa, o zaman tar / netcat en hızlı seçenek olacaktır. Dosyalarınızda (sıfırlar) çok fazla boşluk olduğunu biliyorsanız, -i seçeneğini kullanın.

KAYNAK: tar cvif - / path / to / source | nc HEDEF PORTNUM HEDEF: cd / yol / to / kaynak && nc -l PORTNUM | katran xvif -

Verilerinizin sıkıştırılabilir olduğunu biliyorsanız, tar komutlarınızda sıkıştırma kullanın. -z -j -Ipixz

Ben pixz bir hayranıyım .. paralel xz, bu harika sıkıştırma sunuyor ve sahip olduğum cpu sayısını ağ bant genişliğine göre ayarlayabiliyorum. yavaş bant genişliğim varsa daha yüksek sıkıştırma kullanacağım bu yüzden ağdan çok cpu bekliyorum .. hızlı bir ağım varsa çok düşük sıkıştırma kullanacağım:

KAYNAK: tar cvif - / path / to / source | pixz -2 -p12 | nc HEDEF PORTNUM # tar, sıfır yoksay, 12 cpu çekirdeği kullanarak seviye 2 pixz sıkıştırma HEDEF: nc -l PORTNUM | katran -Ipixz -xvif

Sıkıştırma seviyesini ayarlarsanız ve göbekleri doğru ayarladıysanız, veri kümenize bağlı olarak, ağı doyuma yakın tutabilmeniz ve darboğaz olduğunuzda yeterli miktarda sıkıştırma yapabilmeniz gerekir (genellikle disk sistemleri okuyup yazıyorsa aynısı).

rsync'e gelince, sıfırın bu seçenekle aynı tar yapmasına benzer şekilde atladığına inanıyorum, bu yüzden NFS'den daha az veri aktarıyor. NFS, verilerle ilgili varsayımlarda bulunamaz, bu nedenle NFS protokolü ile birlikte her baytı iletmek zorundadır. RSync bazı ek yükü vardır.

netcat'ın hiçbiri yok .. umurunda olan verilerden başka hiçbir şey içermeyen tam TCP paketleri gönderecek.

netcat ile, scp'de olduğu gibi, her zaman tüm kaynak verilerini göndermeniz gerekir, rsync'de olduğu gibi seçici olamazsınız, bu nedenle artımlı yedeklemeler veya bu tür şeyler için uygun değildir, ancak verileri kopyalamak veya arşivlemek için iyidir.

Nfsshare'de dosya kilitleme ayarlarınız var mı? Devre dışı bırakılmışsa, çok daha fazla performans elde edebilirsiniz.

Artmış hızın, en azından kısmen, G / Ç'nizi etkin bir şekilde keserek göndermek / almak için uzak bir makineye yerel bir süreç oluşturan "rsync src host: / path" nedeniyle olduğunu varsayalım.