Büyük dosyaları kopyalamak için cp'ye daha hızlı bir alternatif var mı (~ 20 GB)?


40

Ben yüksek lisans öğrencisiyim ve çalıştığım grup bir Linux kümesini koruyor. Kümenin her bir düğümü kendi yerel diskine sahiptir, ancak bu yerel diskler nispeten küçüktür ve otomatik yedekleme ile donatılmış değildir. Bu yüzden, grubun birçok TB depolama alanı olan bir dosya sunucusu var. Göreceli bir Linux acemiyim, bu yüzden dosya sunucusunun hız, ağ kabiliyeti, vb. Özelliklerinin ne olduğundan emin değilim. Yerel disklerin G / Ç bakımından dosya sunucusundan önemli ölçüde daha hızlı olduklarını biliyorum. . Yaklaşık bir düzine insan dosya sunucusunu kullanıyor.

Kullanılması cpyerel disklerin birine dosyasunucusu bir ~ 20 GB dosyayı kopyalamak için (uygun ortalama gerçek zamanlı olarak 11,5 dakika sürer time). Bu cpişlemin çok verimli olmadığını biliyorum çünkü (1) timeböyle bir kopya için sistem zamanının sadece ~ 45 saniye olduğunu söylüyor; ve (2) topkopya sırasında incelediğimde , % CPU oldukça düşük (inceleme ile, ortalama olarak kabaca % 0-10 ).

Kullanımı cpaynı yerel diskteki başka bir klasöre yerel diskteki bir klasörden aynı ~ 20 GB dosyayı kopyalamak için daha az zaman alır - gerçek zamanlı olarak 9 dakika (~ göre sistem sürede 51 saniye, yaklaşık time). Öyleyse, görünüşe göre, dosya sunucusu, beklendiği gibi yerel diskten biraz daha yavaş, ancak belki de önemli ölçüde yavaş değil. Yerelden aynı yere kopyalamanın 9 dakikadan daha hızlı olmamasına şaşırdım.

Dosya sunucusundan yerel disklerden birine ~ her biri ~ 20 GB büyüklüğünde ~ 200 büyük dosya kopyalamam gerekiyor. Öyleyse sorum şu: Linux'ta büyük dosyaları kopyalamak için daha hızlı bir alternatif var mı cp? (Veya içinde cpkopyalamayı hızlandıran kullanabileceğim herhangi bir bayrak var mı?) Bu kopyalama zamanından bir dakika bile olsa traş olsam bile, bu çok yardımcı olacaktır.

Yeni, daha hızlı donanım diskleri satın aldığımdan eminim, ancak bu tür kaynaklara erişimim yok. Ayrıca sistem yöneticisi değilim - sadece (acemi) bir kullanıcıyım - bu nedenle disklerdeki yükle ilgili daha ayrıntılı bilgilere erişemiyorum. Bir düzine insan günlük dosya sunucusunu kullanırken, bu düğümü / yerel diski kullanan tek kişi benim olduğumu biliyorum.


29
Bana sorarsanız bu oldukça hızlı, 29 MB / s yapar. Bunu hızlandıracak herhangi bir komut olduğunu sanmıyorum, "darboğaz" büyük olasılıkla a) ağ veya b) dosya sunucusu.
tink 17.13

5
Tink% 100 doğru. Bunu geliştirebilecek bir şey hiç görmedim. Geçmişte yaptığım tek şey, göndermeden önce verileri sıkıştırmaktır, ancak bu, sıkıştırma adımı ve açma adımları ile zaman ekleyeceğiniz anlamına gelir, ancak bazen veriler iyi bir adaysa buna değer sıkıştırılmış!
slm

3
Ayrıca deneyebilirsiniz ddve rsyncortamınızda daha hızlı hangisinin çalıştığını karşılaştırma
Raza

@Salton Teşekkürler. Henüz denemedim ddama denedim rsync. Buna göre, gerçek zaman yaklaşık 11.5 dakika ve sistem zamanı yaklaşık 1.5 dakika idi time.
Andrew,

2
Hiç kimsenin, yerel diskin yerel disk kopyasına kopyalanmasının, birden fazla diskin monte edilmesiyle daha verimli yapılabileceğine işaret etmediğine şaşırdım. Dan kopyalanması /dev/sda1için /dev/sdb1üzerine bir yerden kopyalama daha hızlı olacak /dev/sda1başka bir konuma /dev/sda1veya başka bir bölüme /dev/sdasabit disk okur ve arasına ek arar yapmak zorunda değildir, çünkü diskleri iplik ve kafaları hareketli geleneksel sabit diskler varsayarak yazıyor (; SSD açıkçası farklıdır).
üçlü

Yanıtlar:


53

Kopyalama sırasında % CPU düşük olmalıdır . CPU, disk denetleyicisine "X-Y sektörlerinden veri Z'de bellek arabelleğine al" komutunu verir. Sonra gider ve başka bir şey yapar (ya da başka bir şey yoksa uyu). Donanım, veriler bellekte olduğunda bir kesmeyi tetikler. Ardından CPU'nun birkaç kez kopyalaması gerekir ve ağ kartına "paketleri A, B ve C bellek konumlarında iletme" bildirir. Sonra başka bir şey yapmaya geri dönüyor.

~ 240 mbps bastırıyorsun. Gigabit LAN üzerinde en az 800 mbps yapabilmeniz gerekir, ancak:

  1. Dosya sunucusunu kullanan herkes arasında paylaşılır (ve muhtemelen anahtarlar vb. Arasında bir bağlantı)
  2. Bu, disk sunucusunun yazma hızını sınırlar, disk G / Ç bant genişliğini kullanan herkes tarafından paylaşılır.
  3. Dosya sunucusuna nasıl erişeceğinizi (NFS, CIFS (Samba), AFS vb.) Belirtmediniz. Ağ bağlantınızı ayarlamanız gerekebilir, ancak son zamanlarda herhangi bir şeyde varsayılanlar genellikle oldukça akıllıca olur.

Darboğazı izlemek için, iostat -kx 10yararlı bir komut olacak. Yerel sabit disklerinizdeki kullanımı size gösterecektir. Bunu dosya sunucusunda çalıştırabilirseniz, dosya sunucusunun ne kadar meşgul olduğunu size söyleyecektir.

Genel çözüm, elbette ki bütçenizin olmadığı darboğazı hızlandırmak olacaktır. Ancak, daha hızlı bir yaklaşım bulabileceğiniz birkaç özel durum var:

  • Dosyalar sıkıştırılabilirse ve hızlı bir CPU'nuz varsa, minimum sıkıştırma işlemi daha hızlı olabilir. Gibi bir şey lzopya da belki gzip --fastest.
  • Burada ve orada yalnızca birkaç bit değiştiriyorsanız ve ardından dosyayı geri gönderiyorsanız, yalnızca delta göndermek çok daha hızlı olacaktır. Ne yazık ki, rsyncdeltayı bulmak için her iki taraftaki dosyayı okumanız gerekeceğinden , bu konuda gerçekten yardımcı olmayacaksınız. Bunun yerine, dosyayı değiştirirken deltayı izleyen bir şeye ihtiyacınız var ... Buradaki çoğu yaklaşım uygulamaya özeldir. Ancak, örneğin cihaz eşleştiricisi (yepyeni dm dönemi hedefine bakın ) veya btrfs ile ilgili bir şeyler yerleştirmeniz mümkün .
  • Aynı verileri birden çok makineye kopyalıyorsanız, aynı anda tüm makinelere göndermek için udpcast gibi bir şey kullanabilirsiniz.

Sysadmin olmadığınızı not ettiğinizden beri, sanırım bir sysadmininiz var demektir. Ya da en azından dosya sunucusu ve ağdan sorumlu bir kişi. Muhtemelen ona / çocuklarına sormalısınız, kurulumunuzun özelliklerini daha iyi bilmelidirler. Sysadmin (leriniz) en azından makul bir şekilde ne kadar transfer bekleyebileceğinizi söyleyebilmelidir.


İostat -kx 10 :-) için +1
n611x007

16

Bu muhtemelen daha hızlı bir alternatif olabilir ve ağı iki gün boyunca tıkamayacaksınız: Bir veya iki büyük USB (varsa USB 3) veya FireWire diskleri alın, sunucuya bağlayın ve dosyaları kopyalayın. Hafıza. Diski yerel makinenize taşıyın. Dosyaları makineye kopyalayın.


23
Sneakernet ( en.wikipedia.org/wiki/Sneakernet ) çok hızlı olabilir: Asla otoyoldan aşağı kayıyor kasetlerle dolu bir vagonun bant genişliğini küçümsemeyin.
SplinterReality

10

Verimli tanımınız geriye doğrudur. Daha verimli bir uygulama daha az cpu harcar . Yerel kopyada, ortalama olarak tek bir sabit diskin elde edebileceği kadar iyi olan ortalama 74 MB / s çıktı (okuma + yazma) vardır.


1
Hata. "Verimli" derken "hızlı" demek istedim.
Andrew,

10

Doğrudan SSH (veya SFTP) erişiminiz varsa (sysadmin'inize sorun), scpsıkıştırma ile kullanabilirsiniz ( -C):

scp -C you@server:/path/to/yourfile .

Tabii ki, bu yalnızca dosya sıkıştırılabilirse faydalıdır ve bu işlem daha fazla CPU zamanı kullanacaktır, çünkü şifreleme kullanacaktır (çünkü SSH'nin üzerindedir) ve sıkıştırmaktadır.


Bu durumda, şifrelemeyi devre dışı bırakmak yararlı olacaktır. Kopyayı daha hızlı hale getirmeye çalıştığımızı unutmayın .
lgeorget haziran

3
@lgeorget Sabit disklerin ne kadar yavaş olduğunu göz önünde bulundurarak şifrelemenin ek yükünün önemli olmayacağından şüpheleniyorum. Hakkında bir şeyler eklemeyi düşündüm -c none, ama bu standart değil gibi görünüyor .
Monica

1
Biz ~ 20G dosyaları ile konum uğraşan o kadar olduğunu gerekli değilse şifreleme kullanmak oldukça verimsiz.
lgeorget haziran

1
@lgeorget Şifreleme elde ettiği verimden çok daha hızlı yapılabilir, bu nedenle hiçbir şeyi yavaşlatmaz. Ancak burada SSH'den geçmek gereksiz görünüyor. Sadece mutlaka sıkıştırma ihtiyacınız varsa başka araçlar var mı?
Thomas,

@Thomas SSH'nin avantajı, uzak sunucuya erişiminiz olması gerekiyorsa, neredeyse kesinlikle SSH'yi çalıştırmasıdır. Başka bir seçenek de dosyayı yerel olarak sıkıştırmak, sunucuya kopyalamak, sonra ssh
içeride

8

cpUygulama büyük olasılıkla bir darboğaz değil. iotopHem sunucu hem de küme düğümü üzerinden IO kullanımını gözlemlemeye çalışın . Bu size performansı artırabileceğiniz bir fikir verecektir.

Başka bir ipucu, aynı verileri aynı ana bilgisayardan kopyalamaktan kaçınmaktır. Örneğin, dosya sunucusundan ağ üzerinden tüm küme düğümlerine dağıtmak için aynı 20G dosyanız varsa, dosyaları tek tek bir müşteriden ziyade eşler arası moda kopyalarsanız çok daha hızlı çalışır. Uygulaması biraz daha karmaşık, ancak doğrudan bağlantı merkezi gibi bazı komut satırı p2p'yi kullanmayı deneyebilirsiniz.

Bu 20G dosyalarının içinde, bazı kısımlar yaygındır ve bazıları küme düğümüne özgüdür, onu ortak ve belirli parçalara ayırmayı düşünün ve ardından ortak kısmı p2p şeklinde dağıtın.


1
LAN kullanıyorsanız, eşler arası yerine çok noktaya yayın yapabilmeniz gerekir. Hangisi daha hızlı olmalı ve ağa daha az yüklenmelidir.
derobert

8

Bu dosyaların doğası / içeriği bir miktar fark yaratabilir. Bir bilgisayardan diğerine, her biri ~ 20 GB olan 200 dosyayı kopyalamanız gerektiğini anladım, öyle mi?

Bu dosyalar sıkıştırılabilir veya benzer / özdeş parçalara sahipse, iki yaklaşımınız vardır:

  • kopyalamadan önce bunları sıkıştırın ya da üzerinde fermuar etkin olan bilgisayarlar arasında bir tünel oluşturun. Yani, ağ tıkanıklık ise, biraz daha hızlı olacak

  • dosyalar birbirine çok benziyorsa veya aralarındaki bazı ortak içerikleri paylaşıyorsanız, rsync kullanmayı deneyin . Dosyalar arasında neyin ortak olduğunu bulmak için biraz zaman harcar ve tam anlamıyla kopyalamanıza gerek kalmaz , çünkü ortak olanı temel alarak yeniden oluşturur.

Düzenle

Bu dosyaları birçok kez kopyalamanız gerekecek mi? (bir kopya gibi -> bu dosyaları kullan -> A bilgisayarındaki dosyalardaki bir şeyi değiştir -> dosyaları tekrar B bilgisayarına kopyala)

Eğer öyleyse, rsync yardımcı olacaktır, çünkü sürümler arasında neyin eşit olduğunu tespit etmeye çalışacak ve değişmeyenleri kopyalamayınız.

Ve üçüncü bir yöntem: eğer yukarıdakiler doğruysa (dosyada değişir, sonra tüm dosyaları tekrar ikinci bilgisayara kopyala) binary diff, sadece ikinci bilgisayarda ilk bilgisayarda nelerin değiştirildiğini değiştirmeyi deneyebilirsiniz .


6

Aşağıdakileri burada görüyorum, şifreleme iyi bir fikir değil, muhtemelen aktarılacak veri miktarını ARTTIRABİLİR.

İki sistem arasında kopyalama yapıyorsanız, tıkanıklık elbette sunucular arasındaki bağlantıdır.

Yerel olarak kopyalıyorsanız, işlemin nasıl yürüdüğüne bakın, SINGLE dişlidir, bu nedenle standart Linux yardımcı programlarının kullandığı:

- for all blocks in a file
      read a block
      write a block

Bu işlem için eşzamanlılık YOKTUR.

İşleri hızlandırmak için şöyle bir şey kullanabilirsiniz:

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

Daha fazla bilgi için arabellek (1) kılavuz sayfasına bakınız.

Arabellek komutu, kopyalama işlemini aynı anda çalıştırmak için iki işlem ayarlar: biri okuma için diğeri yazma işlemi için ve verileri iki işlem arasında iletmek için paylaşılan bellek arabelleğini kullanır. Paylaşılan bellek arabelleği, yazılı olmayan verilerin ve önceden yazılan verilerin üzerine yazılmasını engelleyen klasik dairesel arabellektir. Bu programı diskten kasete transferlerde kopya süresinin yaklaşık% 10-20'sini kesmek için kullandım.


Aslında, "bir blok oku / bir blok yaz" da eşzamanlılık vardır, çünkü "bir blok yaz" aslında sadece çekirdeğin arabelleğine koyar ve çekirdek arka planda gerçek blok yazmayı işler (en azından, siz bitinceye kadar) RAM Veya bazı nedenlerden dolayı O_DSYNC / O_SYNC kullanıyorsanız.
derobert


1

Aynı dosya kümesini sık sık yerel bilgisayarınızdan sunucuya, burada ve oradaki ufak değişikliklerle sunucuya kopyalıyorsanız. Rsync veya DVCS (örneğin hg veya git) kullanarak aktarımı hızlandırabilirsiniz.

git veya hg deltaları takip edip algılayabilir ve sadece bu deltaları transfer edebilir. Bir git kullanılması durumunda, her iki taraf da havuzun tüm geçmişine sahip olduğundan, deltanın çözülmesi çok ucuzdur.

rsync, diğer tarafta ne olduğunu önceden bilmeden deltaları algılamak için bir yuvarlama sağlama toplamı algoritması kullanır. Deltaları hesaplamak için rsync'in daha fazla çalışması gerekirken, tüm dosya geçmişini depolaması gerekmez.


1

Tüm dosyaları tek bir arşive paketlemeyi denemek isteyebilirsiniz (sıkıştırılmaya gerek yoktur). Deneyimlerime göre, bir arşivi kopyalamak, çok sayıda ayrı dosyayı kopyalamaktan daha hızlıdır


3
İyi genel gözlem, ancak sorunun “~ 200 büyük dosya - her biri ~ 20 GB” dediği gibi, bunun bu sorunun asıl cevabı olarak görülebileceğine inanmıyorum .
Manatwork

@ manatwork ah .. açıkça okumadım. Toplam 20 gb olan 200 dosyası olduğunu sanıyordum
Munim

0

Deneyin bbcp . Çevremizde yapılan testler, cp'nin bir tür yerleşik yöneticiye sahip olduğunu ortaya koydu. Sadece dikkatli olun çünkü yönetmeni çıkarırken sunucunuzu yeniden hizalayabilir ve bir kesinti oluşturabilirsiniz. Bizim durumumuzda, kopyayı yapmak için sunucuyu çevrimdışına alıyorduk, bu yüzden daha hızlıydı. Bu, aktarım süresini birkaç saat geliştirdi.


0

Kopyalamadan önce hedef dosyaların bulunmadığından emin olun.

Bazen sadece aynı ana bilgisayara kopyalamak için ne kadar zaman harcanması şaşırtıcıdır (ağ dahil değildir).

Burada başka bir cp sorusuna cevabımı görün . Uzun lafın kısası, varolan bir dosyanın üzerine yazmak, onu kesmekten veya önce bağlantısını kesdikten sonra da kopyalamaktan çok daha yavaştır. İkincisi, 1.2GB'lık bir dosya için 8 kat daha hızlıdır.

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.