İki bilgisayar arasında çok miktarda veri göndermenin en hızlı yolu nedir? [kapalı]

111

Bu sık sık içinde olduğum bir durum:

  • İçinde 320 GB sabit disk bulunan bir kaynak sunucum var ve 16 GB RAM ( burada tam özellikler mevcut , ancak bu diğer makinelerde de sıkça karşılaştığım bir sorun olduğu için, herhangi bir konuda çalışmayı tercih ederim.) "makul" Linux makinesi)
  • Birkaç terabaytlık sabit disk alanına sahip bir yedekleme sunucum var ( burada tam özellikler , yukarıdaki feragatnameye bakın)

Kaynak sunucudan 320 GB veriyi hedef sunucuya (özellikle de veri /dev/sda) aktarmak istiyorum .

  1. İki bilgisayar fiziksel olarak yan yana, bu yüzden aralarındaki kabloları çalıştırabilirim.
  2. LAN'dayım ve yeni bir yönlendirici kullanıyorum , bu da ağ hızlarımın "ideal" bir şekilde 1000Mbit olması gerektiği anlamına geliyor, değil mi?
  3. Güvenlik bir sorun değil. Yerel bir ağdayım ve yönlendirici de dahil olmak üzere ağdaki tüm makinelere güveniyorum .
  4. (isteğe bağlı) Verilerin imzalı bir sağlama toplamına ihtiyacım yok, ancak yalnızca hataya yol açmak yerine temel hata denetimi (atılan paketler veya sürücünün okunamaz hale gelmesi gibi) algılanmalı.

Bu soruyu çevrimiçi olarak aradım ve birkaç komutu test ettim. En sık görülen, şudur:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

Bu komutun çok yavaş olduğu kanıtlandı (bir saat boyunca çalıştı, verilerde yalnızca 80 GB civarında kaldı). 1GB test paketi için yaklaşık 1 dakika 22 saniye sürdü ve sıkıştırılmadığında iki kat daha hızlı oldu. Sonuçlar, aktarılan dosyanın kaynak sistemdeki RAM miktarından daha az olması nedeniyle de çarpıtılmış olabilir.

Ayrıca (ve bu 1GB test parçaları üzerinde test edildi), eğer gzipkomutu kullanırsam sorun yaşıyorum dd; sonuçta ortaya çıkan dosya, hedefte çıkartıldığında doğrudan yayınlandığından farklı bir sağlama toplamına sahiptir. Hala bunun neden olduğunu anlamaya çalışıyorum.

networking  backup  dd  file-transfer 
— IQAndreas
kaynak
54
— gwillie
4
/dev/sdaGörüntü olarak mı yoksa sadece dosya olarak mı aktarmak istiyorsunuz ? Rsync neden seçenek yok? Siz /dev/sdatakılıyken takılı mı dd?
— Jodka Limon
15
Performans verileriniz (1GB / 80sn, 80GB / 1h) 100 MBit’te beklediklerimizle mükemmel şekilde eşleşiyor. Donanımını kontrol et. ... ve gerrit doğru, 320GB büyük olabilir, ancak "büyük miktarda veri" yanlış beklentileri artırıyor.
— blafasel
8
"Asla bir yük treni bant genişliğini disklerle küçümseme." .. Verimlilik, gecikme süresi veya ikisinin bir karışımı hakkında mı soruyorsunuz?
— keshlam
8
Bir arkadaşım daima şöyle derdi: "Asla bir kamyondaki sabit disk yığınının bant genişliğini küçümseme".
— AMADANON Inc.

Yanıtlar:

139

Sunucular fiziksel olarak yan yana olduğundan ve yorumlarda bunlara fiziksel erişime sahip olduğunuzdan, en hızlı yol, sabit sürücüyü ilk bilgisayardan çıkarmak, ikinciye yerleştirmek ve dosyaları aktarmak olacaktır. SATA bağlantısı üzerinden.

— BlueRaja - Danny Pflughoeft
kaynak
15
+1: Fiziksel olarak aktarma, bir yerden büyük bir harici sabit disk almak anlamına gelse bile en hızlı yol gibi görünüyor. Bu yaklaşık 40 £ ve muhtemelen zaten çok zaman
— harcadınız
3
Bir gigabit ağında tam hızda çalışıyorsa, bu fikre tamamen katılmıyorum. NFS / SMB üzerinden bir HP Gen 7 mikroserver ve bir Pentium G630 makinesi arasındaki Zyxel Gigabit anahtarı üzerinden test etmek bana ~ 100MB / s transfer sağlıyor. (Sürücü plakalarının dış kenarını terk edinceye kadar.) Bu yüzden 3 saat içinde gerçekçi bir şekilde yapıldığını düşünüyorum. SSD'nin veya çok yüksek performanslı disklerin / depolamanın kullanılması dışında, 2 kopya 100MB / sn'lik bir çıktı üretebilir, bu da her kopya işleminin sadece 200MB / sn olmasını gerektirir.
— Eylül’de 15:52
3
@Phizes: Belli ki geçici kopyalamıyorsun. Bu, Deword'un kötü bir fikiriydi, başkalarının bahsettiği şey değildi. Kaynak sürücüyü hedef makineye bağlamanın amacı SATA-> SATA'ya dd(veya bir dosya sistemi ağacı kopyası) gitmektir .
— Peter Cordes
10
"Asla sabit sürücülerle dolu bir kamyonun bant genişliğini küçümsemeyin. Yine de bir gecikme süresine rağmen"
— Kevin
3
@Kevin: evet, benim açımdan, aynı bilgisayardaki diskler arasındaki doğrudan bir kopyanın en az diğer olası yöntemlerin olduğu kadar hızlı olmasıydı. Phize’in, OPS’in eski diskleri için iyi bir performans sergilediğini, ancak yeni sürücüler için bir darboğaz olduğunu kabul etmek için gerçek yaşam bant genişliği sayılarını tanıttım. (Bir bilgisayardan hem sürücüler ise bir olgu değildir kaynağın meta önbelleğe ve dest dosyaları milyarlarca rsync için örneğin, önemli olan onların RAM kullanarak ayrı bilgisayarları sahip olduğunda en iyi seçenektir.)
— Peter Cordes
69

netcat güvenliğin bir sorun olmadığı durumlar için harikadır:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

Not dd: GNU coreutils kullanıyorsanız SIGUSR1, işleme gönderebilirsiniz ve stderr'e ilerleme verecektir. BSD için ddkullanın SIGINFO.

pv , kopya sırasında kaydedilen ilerlemenin rapor edilmesinde daha da faydalıdır:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
— zackse
kaynak
2
İkinci Örneğin, bir ddhatta gerekli, ya da pv/ nctedavi /dev/sdakendi başlarına sadece iyi? (Bunun gibi özel dosyaları veya 0x00
— baytlı
5
@ user1794469 Sıkıştırma yardımcı olur mu? Ağın tıkanıklığın olduğu yerde olmadığını düşünüyorum.
— IQAndreas
17
Unutmayın ki bashbirinde netcat ile bağlantı kurmak yerine > /dev/tcp/ IP  / port ve < /dev/tcp/ IP  / port yönlendirmelerini kullanabilirsiniz .
— Incnis Mrsi
5
İyi cevap. Gigabit Ethernet genellikle sabit sürücü hızından daha hızlı olduğundan sıkıştırma kullanışsızdır. Birkaç dosya aktarmak için tar cv sourcedir | pv | nc dest_host_or_ip 9999ve düşünün cd destdir ; nc -l 9999 | pv | tar xv. Birçok varyasyon mümkündür, örneğin .tar.gzkopyalardan ziyade hedef tarafta bir yerde kalmak isteyebilirsiniz . Eğer dizini dizine kopyalarsanız, ekstra güvenlik için daha sonra bir rsync uygulayabilirsiniz, örneğin dest'dan rsync --inplace -avP user@192.168.1.100:/path/to/source/. /path/to/destination/.tüm dosyaların gerçekten tam kopya olduğunu garanti eder.
— Stéphane Gourichon
3
IPv4 kullanmak yerine, IPv6 kullanarak daha iyi bir iş hacmine sahip olabilirsiniz çünkü daha büyük bir taşıma kapasitesi vardır. Makineler IPv6 yeteneğine sahipse, muhtemelen zaten bir IPv6 yerel bağlantı adresine sahiplerse bile, onu yapılandıramazsınız
— David Costa
33

  1. Do kullanmak hızlı sıkıştırma.

    • Aktarım ortamınız ne olursa olsun - özellikle ağ veya usb için - okuma, önbellek ve yazma için veri patlamalarıyla çalışacaksınız ve bunlar tam olarak senkronize olmuyor.
    • Disk belleniminin yanı sıra, disk önbellekleri ve çekirdek / ram önbelleklerinin yanı sıra, sistemlerin CPU'larını bir veri bloğu başına gönderilen veri miktarını konsantre etmek için de kullanabiliyorsanız, o zaman yapmanız gerekir .
    • Herhangi bir sıkıştırma algoritması, girişin mümkün olduğu kadar hızlı bir şekilde seyrek giriş işlemlerini otomatik olarak gerçekleştirir, ancak geri kalanını ağ çıkışlarında halledecek çok az kişi vardır.
    • lz4 Burada en iyi seçenek nedir:

      LZ4, çok çekirdekli CPU ile ölçeklendirilebilir, çekirdek başına 400 MB / s hızında sıkıştırma hızı sağlayan, çok hızlı bir kayıpsız sıkıştırma algoritmasıdır. Aynı zamanda, çekirdek başına çoklu GB / sn hızında, genellikle çok çekirdekli sistemlerde RAM hız sınırlarına ulaşan son derece hızlı bir kod çözücüye sahiptir.

  2. Tercihen yok değil gereksiz yere ararlar.

    • Bu ölçmek zor olabilir.

    • Kopyaladığınız aygıtta çok fazla boş alan varsa ve aygıt yakın zamanda sıfırlanmadıysa, ancak kaynak dosya sistemlerinin tümü kopyalanmalıdır, o zaman ilk önce yapmanız gereken zamana değecektir. gibi bir şey:

      </dev/zero tee >empty empty1 empty2; sync; rm empty*

    • Ancak bu, kaynağı hangi seviyede okuman gerektiğine bağlıdır. Aygıtın baştan sona /dev/some_diskaygıt dosyasından okunması genellikle arzu edilir , çünkü dosya sistemi düzeyinde okumak genellikle sırayla olmayan bir şekilde ileri geri ve diskin aranmasını içerir. Ve böylece okuma komutunuz şöyle bir şey olmalı:

      </dev/source_device lz4 | ...

    • Bununla birlikte, kaynak dosya sisteminizin tamamı aktarılmaması gerekiyorsa, dosya sistemi düzeyinde okumak oldukça kaçınılmazdır ve bu nedenle girdi içeriğinizi bir akışa eklemelisiniz. paxgenellikle bu durumda en iyi ve en basit çözümdür, ancak siz de düşünebilirsiniz mksquashfs.

      pax -r /source/tree[12] | lz4 | ...
mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...

  3. Do not ile şifrelemek ssh.

    • Güvenilir bir ortama şifreleme yükü eklemek gereksizdir ve sürekli aktarım hızına ciddi şekilde zarar verebilir ve okunan verilerin iki kez okunması gerekir .
    • PRNG okunan verileri ihtiyacı ya da en azından bazı, rasgelelik sürdürmek.
    • Ve elbette verileri de aktarmanız gerekir.
    • Ayrıca şifreleme ek yükünü kendiniz de aktarmanız gerekir; bu, çoğuşma başına daha az veri aktarımı için daha fazla iş demektir .

    • Bunun yerine , başka bir yerde önerildiği gibi basit bir ağ kopyası için kullanmanız netcat( veya tercih ettiğim gibi, nmapprojenin daha yeteneklincat ):

      ###  on tgt machine...
nc -l 9999 > out.lz4
###  then on src machine...
... lz4 | nc tgt.local 9999
— mikeserv
kaynak
1
Harika cevap Bir küçük gramer noktası - "patlama başına değiş tokuş yapılması gereken veri miktarını azaltın" - "patlamaların" sabit genişlikli olması nedeniyle bilgi yoğunluğunu artırmak için sıkıştırma kullandığınızı düşünüyorum veri bloğu başına aktarılan bilgiler değişebilir.
— Mühendis Dollery,
@EngineerDollery - evet, bu aptalcaydı. Daha iyi olduğunu düşünüyorum,
— mikeserv 10:15
@ IQAndreas - Bu cevabı ciddiye alırdım. Şahsen ben pigz kullanıyorum ve hız artışı inanılmaz . Paralellik büyük bir kazançtır; İşlemciler veri hattının diğer bölümlerinden çok daha hızlıdır, bu nedenle paralel sıkıştırmanın sizi yavaşlatacağından şüpheliyim (gzip paralelleştirilemez). Bu kadar hızlı bir şekilde, sabit diskleri oynatacak hiçbir şekilde teşvik edilemeyebilir; Bu daha hızlı olsaydı (disk takas zamanı dahil) şaşırmam. Sıkıştırma ve sıkıştırma olmadan kıyaslama yapabilirsiniz. Her durumda, ya BlueRaja'nın diskswap cevabı ya da bu sizin kabul ettiğiniz cevabınız olmalıdır.
— Mike S
Hızlı sıkıştırma mükemmel bir tavsiyedir. Bununla birlikte, yalnızca verilerin makul şekilde sıkıştırılabilir olması durumunda yardımcı olduğu, yani sıkıştırılmış bir formatta olmaması gerektiği anlamına geldiği belirtilmelidir.
— Walter Tross
@WalterTross - oran ne olursa olsun herhangi bir girişin sıkıştırılabilir olması durumunda , sıkıştırma işi aktarma işinden daha iyi performans gösterdiği sürece yardımcı olacaktır . Modern bir dört çekirdekli sistemde, bir lz4iş geniş açık GIGe'lere bile kolayca ayak uydurabilir ve USB 2.0 hiçbir şansı yoktur. Ayrıca, lz4yalnızca çalışması gerektiğinde çalışmak üzere tasarlandı - kısmen çok hızlı çünkü sıkıştırma işleminin ne zaman yapılması gerektiğini ve ne zaman yapmaması gerektiğini bilir. Ve eğer aktarılan bir cihaz dosyasıysa, kaynak dosya sisteminde herhangi bir parçalanma varsa, önceden sıkıştırılmış girdiler bile bir şekilde sıkışabilir.
— mikeserv 10:15
25

Aktarım hızını sınırlayabilecek birkaç sınırlama vardır.

  1. 1 Gb / sn'lik bir boruda doğal ağ yükü var. Genellikle, bu GERÇEK iş hacmini 900Mbps veya altına düşürür. O zaman bunun iki yönlü bir trafik olduğunu ve aşağı doğru 900Mbps'den daha az bekleyeceğinizi hatırlamanız gerekir.

  2. Bir "new-ish router" kullanıyor olsanız bile, router'ın 1Gbps'yi desteklediğinden emin misiniz? Tüm yeni yönlendiriciler 1 Gb / sn'yi desteklemez. Ayrıca, işletme sınıfı bir yönlendirici olmadıkça, yönlendiricinin etkin olmadığından ek iletim bant genişliğini kaybedeceksiniz. Aşağıda bulduğuma göre, 100 Mbps’in üzerine çıkmış gibi görünüyorsun.

  3. Ağınızı paylaşan diğer cihazlardan gelen ağ tıkanıklığı olabilir. Yapabildiğiniz gibi doğrudan bağlı bir kablo kullanmayı denediniz mi?

  4. Diskinizin ne kadarını kullanıyorsunuz? Muhtemelen, ağ tarafından değil, disk sürücüsü ile sınırlısınız. 7200 dev / dak HDD'lerin çoğu sadece 40 MB / sn civarında olacaktır. Hiç baskın kullanıyor musunuz? SSD kullanıyor musunuz? Uzak uçta ne kullanıyorsunuz?

Bunun yedekler için yeniden çalıştırılması bekleniyorsa rsync kullanmanızı öneririm. Ayrıca ssh / http / https / ftp bağlantılarını paralel hale getireceği için diğer ucundaki filezilla benzeri bir indiriciyi kullanarak scp, ftp (s) veya http komutunu kullanabilirsiniz. Bu, diğer çözümler tek bir borunun üzerindeyken bant genişliğini artırabilir. Tek bir boru / dişli, tek dişli olması nedeniyle hala sınırlıdır, yani CPU'ya bağlı bile olabilir.

Rsync ile, sıkıştırma, izin koruma ve kısmi transferlere izin vermenin yanı sıra, çözümünüzün karmaşıklığını büyük miktarda çıkarırsınız. Başka nedenler de var, ancak genel olarak büyük işletmelerin tercih ettiği yedekleme yöntemi (veya yedekleme sistemlerini işletiyor). Commvault aslında kendi yazılımlarının altındaki rsync'i yedeklemeler için dağıtım mekanizması olarak kullanıyor.

Verdiğiniz 80GB / s örneğinize göre, yaklaşık 177 Mbps (22,2 MB / s) alıyorsunuz. Bunu, rsync ile gigabit üzerindeki rsync ile kendi testlerimde yapmayı başardığım için iki kutu arasında atanmış bir ethernet hattında kolayca ikiye katlayabileceğinizi düşünüyorum.

— Khrystoph
kaynak
12
İçin +1 rsync. İlk çalıştırdığınızda daha hızlı olmayabilir , ancak kesinlikle daha sonraki tüm zamanlar için olacaktır.
— Skrrp
4
> 7200 dev / dak HDD'lerin çoğu sadece 40 MB / sn civarında olacaktır. IME, modern bir sürücüde art arda 100 MB / s'yi görme olasılığınız daha yüksektir (ve buna ~ 5k sürücüler dahildir). Yine de, bu daha eski bir disk olabilir.
— Bob
2
@Bob: Modern olanlar hala dakikada 5400 dairesel parça okuyabilirler. Bu diskler hala hızlı, çünkü her iz bir megabayttan daha fazlasını içeriyor. Bu, aynı zamanda oldukça büyük diskler olduğu anlamına gelir. Küçük bir 320 GB disk parça başına çok fazla kilobayt tutamaz, bu da hızlarını mutlaka sınırlar.
— MSalters
1
40 MB / s, son on yılda yapılan herhangi bir sürücü için sıralı okuma için kesinlikle çok karamsar. Mevcut 7200RPM sürücüler Bob’un söylediği gibi 100 MB / sn’yi geçebilir.
— Ocaklar
3
Gigabit Ethernet, 1000 mbps tam çift yönlüdür . (Dediğin gibi etrafında gerçekte 900mbps, ya) Sen 1000MBps olsun her yönü . İkincisi ... sabit sürücüler artık rutin olarak 100 MB / sn. Bu on yıllık eski bir sürücü olmadıkça 40 MB / sn yavaş.
— derobert 10:15
16

Bununla düzenli olarak ilgileniyoruz.

Kullanmaya meyilli olduğumuz iki ana yöntem şunlardır:

  1. SATA / eSATA / sneakernet
  2. Doğrudan NFS bağlantısı, ardından yerel cpveyarsync

Birincisi, sürücünün fiziksel olarak yeniden yerleştirilip değiştirilemeyeceğine bağlıdır. Bu her zaman böyle değildir.

İkincisi şaşırtıcı derecede iyi çalışıyor. Genel olarak, doğrudan NFS bağlantıları ile kolayca bir 1gbps bağlantıyı aşıyoruz. Scp, sd over ssh veya benzeri herhangi bir şey ile buna yakın bir yere gidemezsiniz (genellikle 100mpb'ye şüpheli bir şekilde yakın bir maksimum oran elde edersiniz). Çok hızlı çok çekirdekli işlemcilerde bile, iki makinenin en yavaşındaki çekirdeklerin birinin şifreli ağ bağlantısındaki tam delikli cp veya rsync ile karşılaştırıldığında iç karartıcı yavaş olan maksimum kripto veriminde bir tıkanıklığa varacaksınız. Nadiren, bir süredir bir iops duvarına çarpacaksınız ve daha tipik ~ 110 MB / s yerine yaklaşık ~ 53MB / s'de sıkışıp kalacaksınız, ancak kaynak veya hedef aslında olmadığı sürece, genellikle kısa ömürlütek bir sürücü, o zaman sürücünün kendisinin sürekli oranı ile sınırlandırılmış olabilirsiniz (bu, gerçekten denemedene kadar bilemeyeceğiniz rastgele nedenlerden dolayı yeterince değişir) - meh.

NFS, bilinmeyen bir dağıtımda kurulup kurulmaması konusunda can sıkıcı olabilir, ancak genel olarak konuşursak, boruları mümkün olduğu kadar eksiksiz doldurmanın en hızlı yolu olmuştur. Bunu son 10 gbps üzerinden yaptığımda, bağlantıyı maksimize edip etmediğimi hiç bulamadım, çünkü biraz kahve almaya gelmeden önce transfer bitmişti - bu yüzden oraya vuracağınız bazı doğal limitler olabilir. Kaynak ve hedef arasında birkaç ağ aygıtınız varsa, ağın daraltıcı etkisinden hafif gecikmeler veya hıçkırıklarla karşılaşabilirsiniz, ancak genel olarak bu, ofis genelinde (onu kullanan diğer trafiği sansa eden) veya veri merkezinin bir ucundan diğeri (dahili olarak gerçekleşen bir tür filtreleme / inceleme işleminiz yoksa, bu durumda tüm bahisler kapalıdır ).

DÜZENLE

Ben do ... sıkıştırma hakkında bazı söylentiler fark değil bağlantıyı sıkıştırmak. Sizi bir kripto katmanının kullanacağı gibi yavaşlatır. Bağlantıyı sıkıştırırsanız tıkanıklık her zaman tek bir çekirdek olacaktır (ve hatta bu çekirdeğin veriyolundan özellikle faydalanamayacaksınız). Durumunuzda yapabileceğiniz en yavaş şey, 1 gbps veya daha yüksek bir bağlantıda yan yana oturan iki bilgisayar arasında şifreli, sıkıştırılmış bir kanal kullanmaktır.

GELECEĞİN KORUNMASI

Bu tavsiye 2015 yılı ortası itibariyle geçerlidir. Bu neredeyse kesinlikle çok uzun yıllar boyunca geçerli olmayacak. Yani inanmayarak ile her şeyi almak ve düzenli olarak bu görevle karşı karşıya eğer o andan çeşitli yöntemler denemek fiili yükleri yerine web gibi şeyler için tipik teorik optimumlara yakın, hatta gözlenen şey sıkıştırma / şifreleme geçiş oranları alacak hayal etmenin trafik, çok (metinsel PROTIP olduğu: toplu transferler genellikle vb görüntüler, ses, video, veri tabanı dosyaları, ikili kod, ofis dosya formatları, esas oluşur zaten sıkıştırılmışkendi yollarında ve sıkıştırma bloğu büyüklüğünün zaten sıkıştırılmış ikili verilerinizle aynı hizada olmadığından neredeyse garanti edilen başka bir sıkıştırma rutininden geçmekten çok az yararı var ...).

Gelecekte, SCTP gibi konseptlerin daha ilginç bir yere götürüleceğini, bağlı bağlantıların (ya da dahili olarak spektrumla kanalize edilmiş fiber bağlantıların) tipik olduğu ve her kanalın diğerlerinden bağımsız bir akış alabildiğini ve her birinin diğerlerinden bağımsız bir akış alabileceğini hayal ediyorum. akış paralel olarak sıkıştırılabilir / şifrelenebilir, vb. olabilir. Bu harika olurdu! Fakat bugün 2015'te durum böyle değil ve fantazi ve teorisyenlik güzel olsa da, çoğumuz, doğrudan bir Mavi Gen / Q üreten cevabına doğrudan bir kriyo-odası besleme verisinde çalışan özel depolama kümelerine sahip değiliz. Bu sadece gerçeklik değil. Sıkıştırmanın iyi bir fikir olup olmadığını anlamak için veri yükümüzü ayrıntılı bir şekilde analiz etmek için vaktimiz yok - analizimizi bitirmeden önce transferin kendisinin biteceğini,

Fakat...

Kez değişir ve sıkıştırma ve şifrelemeye karşı önerim geçerli olmayacak. Bu tavsiyenin tipik davada çok yakında devrilmeyi gerçekten çok isterim . Hayatımı kolaylaştıracaktı.

— zxq9
kaynak
1
@jofel Yalnızca ağ hızı , işlemcinin sıkıştırma veriminden daha yavaş olduğunda - bu, 1 gpbs veya daha yüksek bağlantılar için asla doğru değildir. Yine de, tipik durumda, ağ darboğazıdır ve sıkıştırma işleri etkili bir şekilde hızlandırır - ancak OP'nin tarif ettiği durum bu değildir.
— zxq9
2
lz4işini tıkamak için yeterince hızlı, ancak kopya ile ne yapmak istediğinize bağlı olarak, sıkıştırılmamış olarak ihtiyacınız olabilir. lzop da oldukça hızlı. İ5-2500k Sandybridge (3.8GHz) cihazımda ~ 180MB lz4 < /dev/raid0 | pv -a > /dev/null/ s giriş, ~ 105MB / s çıkış, tam doğru bir performans sergiliyor. İşlemci tarafında dekompresyon işleminin yapılması daha da kolaydır.
— Peter Cordes
1
Ayrıca, 3.8GHz, çoğu sunucu işlemcisinin (veya en azından görmeye alışkın olduğum herhangi bir lezzetin işletme sınıfı sistemleri) çalıştığından biraz daha hızlıdır. Veri merkezlerinde çok daha düşük saat hızlarına sahip çok daha yüksek çekirdek sayıları görmek daha yaygındır. Transfer yüklerinin paralel hale getirilmesi uzun zamandır bir sorun olmamıştır , bu yüzden çoğu durumda tek bir çekirdeğin maksimum hızına sıkışmış durumdayız - ancak bunun saat hızlarının genellikle maksimuma çıkarıldığı, ancak ağ hızlarının hala olduğu gibi değişeceğini umuyorum. maksimumlarına çarpmadan önce gitmek için uzun bir yol.
— zxq9 10:15
2
Sıkıştırma hakkındaki yorumlarınıza tamamen katılmıyorum. Tamamen verilerin sıkıştırılabilirliğine bağlıdır. Eğer% 99,9'luk bir sıkıştırma oranı elde edersen, bunu yapmamak aptallık olur - neden 100 MB'lık transfer ile kaçabileceğin zaman 100GB'ı transfer ettin? Bu sıkıştırma seviyesinin bu soru için bir durum olduğunu önermiyorum, bunun sadece vaka bazında dikkate alınması gerektiğini ve mutlak kurallar olmadığını gösteriyorum.
— Mühendis Dollery 10:15
1
@EngineerDollery Bu toplu aktarımında dışarı çalmıyor hiç gerçek dünyada. Bunu hemen hemen her gün yapıyorum ve çeşitli yöntemler ve ayarlar denedim. (Eğer üzerine sıkıştırma ayarlama testler için zaman herhangi bir şey - Uygulamada hemen hemen her veri merkezinde her şey, kurumsal altyapı, küçük işletme sunucusu veya ev ağı içinde anlamına gelir) bilinmeyen verinin genel durum büyük toplu transferlerinde olduğu kadar 1 gbps veya daha yüksek bir bağlantıda daha hızlı. Git dene. Metin genellikle sıkıştırma için en iyi durumdur. Metin, tipik bir toplu transfer yükünün küçük bir kısmını içerir.
— zxq9 10:15
6

Geçmişte kullandığım şık bir araç bbcp. Burada görüldüğü gibi: https://www.slac.stanford.edu/~abh/bbcp/ .

Ayrıca bkz. Http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

Bu araçla çok hızlı aktarım hızlarım oldu.

— Karanlık kalp
kaynak
1
Bu cevabın ikinci linki, çekirdek parametrelerinin daha yüksek hızlara ulaşmak için nasıl ayarlanacağını açıklar. Yazar, 10G bağlantılarında saniyede 800 megabayt aldı ve bazı şeyler 1Gbps bağlantılara uygulanabilir.
— Stéphane Gourichon 08:15
5

Bir şekilde bir ilk paso alırsanız (tel üzerinden / sinsi / ağ üzerinden / ne olursa olsun), rsyncdaha sonraki transferleri büyük ölçüde hızlandıran bazı seçeneklere bakabilirsiniz . Gitmek için çok iyi bir yol olacaktır:

rsync -varzP sourceFiles destination

Seçenekler şunlardır: ayrıntılı, arşiv modu, özyinelemeli, sıkıştır, Kısmi ilerleme

— Atlamalı Tavşan
kaynak
2
Rsync, netcat'ten daha güvenilirdir, ancak arşiv özyinelemelidir, bu nedenle r gereksizdir.
— Tanath
Ayrıca, -zCPU'nuza ve hangi verileri işlediğinize bağlı olarak inanılmaz derecede yavaş olabilir. Sıkıştırmayı devre dışı bırakırken 30 MB / sn'den 125 MB / sn'ye kadar transfer deneyimledim.
— saat
4

Orijinal posterin ısrarına, yorumların cevabını zackse yorumunda ekledi, ancak tipik koşullarda en hızlı olduğundan emin değilim .

bashözel bir yönlendirme sözdizimi vardır:
Çıkış için:      > /dev/tcp/ IP  / portu
Giriş için:       < /dev/tcp/ IP  / portu
IP yasağı noktalı-ondalık IP veya bir ana bilgisayar adı olabilir; bağlantı noktası yasağı, ondalık sayı ya da bağlantı noktası adı olabilir /etc/services.

Gerçek bir /dev/tcp/dizin yok . bashBir TCP soketi oluşturma, belirtilen hedefe bağlama ve normal bir dosya yönlendirme işleminin yaptığı gibi aynı şeyi yapan özel bir sözdizimsel kludge (yani, ilgili standart akışı dup2 (2) kullanarak soketle değiştirin).

Bu nedenle, kaynak makineden ddveya tardoğrudan TCP üzerinden veri akışı yapılabilir . Ya da tersine, verileri tardoğrudan veya TCP yoluyla doğrudan veya başka bir şeye aktarmak . Her durumda, bir gereksiz netcat ortadan kalkar.

Netcat hakkında notlar

Klasik netcat ve GNU netcat arasındaki sözdiziminde bir tutarsızlık var . Alıştığım klasik sözdizimini kullanacağım. GNU netcat -lpile değiştirin -l.

Ayrıca GNU netcat'in -qanahtarı kabul edip etmediğinden emin değilim .

Disk görüntüsünü aktarma

(Zackse'ın cevabı boyunca.) Hedefte
:

nc -lp 9999 >disk_image

Kaynakta:

dd if=/dev/sda >/dev/tcp/destination/9999
 

İle bir tar.gz arşivi oluşturmak tar

Hedefte:

nc -lp 9999 >backup.tgz

Kaynakta:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

Değiştir .tgzile .tbzve czile cjbir olsun bzip2-Sıkıştırılmış arşiv.

Anında genişleme ile dosya sistemine aktarma

Ayrıca tar.
Hedefte:

cd backups
tar x </dev/tcp/destination/9999

Kaynakta:

tar c files or directories to be transferred |nc -q 1 -lp 9999

Bu olmadan çalışacak -q 1, ancak veriler sona erdiğinde netcat takılacak. Sözdizimi ve uyarıları için tar (1) 'e bakınız tar. Fazlalık olan çok fazla dosya varsa (düşük entropi), o zaman sıkıştırma (örn. czVe xzyerine cve x) denenebilir, ancak dosyalar normalse ve ağ yeterince hızlıysa, işlemi yalnızca yavaşlatır. Sıkıştırma hakkında ayrıntılar için mikeserv'in cevabına bakınız.

Alternatif stil (hedef bağlantı noktasını dinler)

Hedefte:

cd backups
nc -lp 9999 |tar x

Kaynakta:

tar c files or directories to be transferred >/dev/tcp/destination/9999
— Incnis Mrsi
kaynak
bash aslında bir dosyayı beklemek ve almak için görünüşe göre bir sokette "dinleyemiyor": unix.stackexchange.com/questions/49936/… böylece bağlantının en az bir yarısı için başka bir şey kullanmalısınız. ...
— rogerdpack
2

Bu betiği kullanırdım , socatpakete ihtiyacı olduğunu yazdım .

Kaynak makinede:

tarnet -d wherefilesaretosend pass=none 12345 .

Hedef makinede:

tarnet -d wherefilesaretogo pass=none sourceip/12345

Eğer vbufpaket (Debian, Ubuntu) bulunmaktadır ardından dosya gönderen bir veri ilerleme gösterecektir. Dosya alıcısı hangi dosyaların alındığını gösterecektir. Geçiş = seçenek verinin açığa çıkabileceği yerlerde kullanılabilir (daha yavaş).

Düzenle:

-nCPU bir şişe boynuysa, sıkıştırmayı devre dışı bırakmak için bu seçeneği kullanın .

— Skaperen
kaynak
2

Bütçe asıl sorun değilse, sürücüleri Intel Xeon E5 12 çekirdekli "sürücü konektörü" ile bağlamayı deneyebilirsiniz. Bu bağlayıcı genellikle o kadar güçlüdür ki, mevcut sunucu yazılımınızı bile çalıştırabilirsiniz. Her iki sunucudan!

Bu eğlenceli bir cevap gibi görünebilir, ancak verileri neden sunucular arasında taşıdığınızı ve paylaşılan hafıza ve depolamaya sahip büyük bir tanenin daha anlamlı olabileceğini gerçekten düşünmelisiniz.

Şu anki özelliklerden emin değilsiniz fakat yavaş aktarım, ağ hızıyla değil disk hızlarıyla sınırlandırılabilir.

— user133111
kaynak
1

Yalnızca yedekleri önemsiyor ve sabit sürücünün bayt kopyası için bir baytla ilgilenmiyorsanız, backupPC'yi öneririm. http://backuppc.sourceforge.net/faq/BackupPC.html Kurulumu biraz üzücü fakat çok hızlı bir şekilde aktarılıyor.

Yaklaşık 500G veri için ilk transfer sürem yaklaşık 3 saatti. Sonraki yedeklemeler yaklaşık 20 saniye içinde gerçekleşir.

Yedeklemeyle ilgilenmiyorsanız, ancak bir şeyleri eşitlemeye çalışıyorsanız, rsync veya unison ihtiyaçlarınızı daha iyi karşılar.

Sabit diskin bayt kopyası için bir bayt, genellikle yedekleme amaçları için korkunç bir fikirdir (artımlı, yer tasarrufu olmaz, sürücü kullanımda olamaz, "boş alanı" yedeklemeniz gerekir ve çöpleri yedeklemeniz gerekir. (16 G'lik bir takas dosyası veya 200G çekirdek dökümü veya bunun gibi bir şey gibi). rsync (veya backuppc veya diğerleri) kullanarak, zaman içinde "anlık görüntüler" oluşturabilir, böylece "dosya sisteminiz 30 dakika önce neye benziyordu" ile gidebilirsiniz. çok az yükü.

Bununla birlikte, eğer gerçekten bir bayt kopyası için bir bayt transfer etmek istiyorsanız, o zaman sorun sürücüden veri almak değil transferde yatacağınız. 400G RAM dışında bir 320G dosya aktarımı çok zaman alacak. Şifreli olmayan protokollerin kullanılması bir seçenektir, ancak ne olursa olsun, orada oturup birkaç saat (ağ üzerinden) beklemek zorunda kalacaksınız.

— coteyr
kaynak
1
400G RAM veri aktarımını nasıl hızlandırır?
— Skaperen
Bunun amacı olmadığından emin değilim, ancak "400 GB RAM satın almanız ve HDD’nizi HDD’ye aktarmanızın daha hızlı geçmesi" yerine "RAM’den RAM’e aktarımın biraz daha uzun süreceğini" olarak okudum.
— MichaelS
Evet, Ram senin için arabelleğe girecek ve daha hızlı görünecek. Tamamen RAM tamponlama ile HD'den HD'ye aktarım yapabilirsiniz ve çok hızlı görünecektir. Ayrıca diske girme oldukça zor olacaktır, ancak HD'den RAM'e RAM'den HD'ye daha hızlı, HD'den HD'ye daha hızlıdır. (Neyse HD için RAM RAM Eğer HD yapmak zorunda unutmayın ama RAM tüm aktarım boyutu daha az varsa segmentlerde için "sifon" olacaktır.)
— coteyr
Koya koymanın bir başka yolu da bütün kaynak sürücüyü sıkıştırmanın hatta göndermenin bile tokmak için okunması gerektiğidir. Bir seferde hepsine uymuyorsa, bir segmenti okumak, göndermek, atmak, aramak, segmenti okumak vb. Herkese aynı anda uyması durumunda hepsini aynı anda okuması gerekir. Hedefte aynı.
— coteyr
1
HD'den RAM'e RAM'den HD'ye HD'den daha hızlıdır HD'den HD'ye nasıl daha hızlı olabilir?
— AL
1

Programdan bağımsız olarak, genellikle ağ üzerinden "dosya çekmenin" "zorlamadan" daha hızlı olduğunu buldum. Yani, hedef bilgisayara giriş yapmak ve bir okuma yapmak kaynak bilgisayara giriş yapmaktan ve bir yazı yazmaktan daha hızlıdır.

Ayrıca, bir ara sürücü kullanacaksanız, şunu göz önünde bulundurun: USB yerine eSATA kullanan harici bir sürücü (paket olarak veya takma birimine takılı ayrı bir sürücü) edinin. Ardından iki bilgisayarın her birine eSATA bağlantı noktasına sahip bir kart takın veya dahili SATA bağlantı noktalarından birini harici eSATA konektörüne getiren basit bir adaptör kablosu edinin. Ardından sürücüyü kaynak bilgisayara takın, sürücüyü çalıştırın ve otomatik olarak takılmasını bekleyin (tam olarak monte edebilirsiniz, ancak bunu tekrar tekrar yapıyorsanız fstab dosyasına da koyabilirsiniz). Sonra kopyalayın; dahili bir sürücüyle aynı hızda yazacaksınız. Ardından sürücüyü çıkarın, kapatın, diğer bilgisayara takın, açın, otomatik montaj bekleyin ve okuyun.

— Mike Ciaraldi
kaynak
2
Dosyaları nasıl "çektiğinize" dair ayrıntılı bilgi verebilir misiniz? Hangi araçları kullanıyorsunuz ve bu etkiyi gösteren herhangi bir örnek verebilir misiniz?
— STW
Bunun daha eksiksiz bir cevap olup olmayacağından emin değilim, ancak şu senaryoyu inceleyin: İki bilgisayarın olduğunu, foo ve bar olduğunu ve foodan çubuğa veri kopyalamak istediğinizi varsayalım. (1) Foo'ya giriş yapın, sonra fiziksel olarak çubuğa bağlı olan sürücüyü uzaktan monte edin. Ardından foo diskinden uzaktan monte edilmiş dizine (fiziksel olarak çubuk üzerinde) kopyalayın. Bunu veriyi diğer bilgisayara iterek aradım. (2) Bunu, aynı verileri kopyalamanın diğer yolu ile karşılaştırın. Çubuğa giriş yapın, foo'ya bağlı dizini uzaktan monte edin ve foo'dan çubuğun sürücüsüne okuyun. Bu çekiyor.
— Mike Ciaraldi
Bu kopyalama, Linux cp komutuyla, bir GUI dosya yöneticisinden veya herhangi bir dosya kopyalama yöntemiyle yapılabilir. Çekmenin daha hızlı olduğunu düşünüyorum çünkü yazma okumadan daha yavaştır ve hedef diske nasıl yazılacağına dair kararların çoğu sürücünün bağlı olduğu bilgisayarda aynı şekilde yapılır, bu nedenle daha az ek yük olur. Ama belki de artık daha modern sistemlerde durum böyle değil.
— Mike Ciaraldi
1

NIC takımlarına bakmanı tavsiye edeceğim. Bu paralel olarak çalışan birden fazla ağ bağlantısının kullanılmasını içerir. Gerçekten 1 Gb'den daha fazla aktarıma ihtiyacınız olduğunu ve 10 Gb'nin maliyet engelleyici olduğunu varsayarsak, NIC-teaming tarafından sağlanan 2 Gbs düşük maliyetli olur ve bilgisayarlarınız zaten ek bağlantı noktalarına sahip olabilir.

— Byron Jones
kaynak
LACP'ye (Link Aggregation Control Protocol) bakınca, hızda bir artış görmeyeceksiniz. Artıklık ve daha fazla eşzamanlı bağlantı sunma yeteneği sağladı, ancak bu tür bir aktarma için hız artışı sağlamayacak.
— STW
@STW: Bir makineye iki bağlantıyı 2gbit bir bağlantıda birleştirmek için anahtar desteği gerektirir, ancak mümkündür. Ancak, her iki makinenin de, anahtara 2gbit bağlantısı varsa faydalı olur. NIC'yi çalıştıran iki kablonuz varsa <-> NIC, anahtarsız, bunun da işe yaraması gerekir, ancak çok kullanışlı olmaz (bir makinede İnternet'e bağlı kalmak için 3. NIC'iniz olmadığı sürece).
— Peter Cordes
Anahtarlarda bu özellik için belirli bir ad var mı?
— STW
NIC takımları, EtherChannel, vb. Çeşitli varyasyonları vardır. STW belirli konfigürasyonlar için doğrudur, bu yardımcı olmaz, ancak bazı konfigürasyonlar için olur. Bağlanan kanalın tek bir IP soketi için performansı hızlandırıp hızlandırmadığı ortaya çıkar. Bunun sizin için uygun bir çözüm olup olmadığını belirlemek için özellikleri araştırmanız gerekecek.
— Byron Jones
802.3ad, anahtarlarınızda aradığınız açık standarttır. Hızlı bir kesmek olsa da, fazladan NIC'leri ağa bağlayabilir ve özel adres alanındaki ayrı alt ağlarda uygun IP adresleri verebilirsiniz. (ana bilgisayar 1 bağlantı noktası a ve ana bilgisayar 2 bağlantı noktası a bir alt ağ, ana bilgisayar 1 bağlantı noktası b ve ana bilgisayar 2 bağlantı noktası b başka bir alt ağ alır). Sonra sadece transferi yapmak için iki paralel iş çalıştırın. Bu, Etherchannel, 802.3ad, vb. Giriş ve çıkışları öğrenmekten çok daha kolay olacaktır.
— Dan Pritts
1

FWIW, bunu hep kullandım:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

Bu yöntemle ilgili olarak, makineler arasında dosya / klasör izinlerini koruyacağı (her ikisinde de aynı kullanıcıların / grupların var olduğu varsayılarak) olduğu (Ayrıca, genellikle seyrek dosyaları işlemek için bir -S parametresi kullanabildiğim için sanal disk görüntüleri kopyalamak için yapıyorum. )

Bunu sadece iki meşgul sunucu arasında test ettim ve ~ 14 GB'ı 216 saniyede (yaklaşık 64 MB / sn) yönetin - özel makineler ve / veya sıkıştırma arasında daha iyisini yapabilir ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers
— ttstooge
kaynak
1

Dosya sistemi adli tıp yapmak istemiyorsanız, FS'nin kullanmadığı boş alanları kopyalamaktan kaçınmak için dosya sisteminiz için bir döküm / geri yükleme programı kullanın. Sahip olduğunuz dosya sistemine bağlı olarak, bu genellikle dahil olmak üzere tüm meta verileri koruyacaktır ctime. inode numaraları, yine de hangi dosya sistemine bağlı olarak değişebilir (xfs, ext4, ufs ...).

Geri yükleme hedefi, hedef sistemdeki bir dosya olabilir.

Bölüm tablosuyla birlikte tam disk bir görüntü istiyorsanız dd, bölüm tablosunu / bootloaders / stuff xfsdumpbölümünü , sonra bölümleri almak için diskin ilk 1M'sini alabilirsiniz .

Bilgi dökümünüzden aslında ne tür bir dosya sistemine sahip olduğunuzu söyleyemem. BSD UFS ise, bunun bir dökümü / geri yükleme programı olduğunu düşünüyorum. ZFS ise, IDK, bir şey olabilir.

Genelde tam kopya diskler, kurtarma durumları dışındaki hiçbir şey için çok yavaştır. Bu şekilde artımlı yedeklemeler de yapamazsınız.

— Peter Cordes
kaynak
1

Ayrıca, paylaşılan bir depolama alanı için sistemleri de ayarlayabilirsiniz!

Bunların yan yana olduklarını düşünüyorum ve bunu tekrar tekrar yapmanız muhtemel.

— user133526
kaynak
1

Ethernet çapraz kabloya ne dersiniz? Kablosuz hızlara güvenmek yerine, NIC'nizin kablolu hızında sınırlandırılırsınız.

İşte bu tür çözümlerin bazı örnekleri ile benzer bir soru.

Görünüşe göre sadece tipik bir ethernet kablosu bugünlerde yeterli olacaktır. Açıkçası, NIC'niz ne kadar iyiyse transfer o kadar hızlı olur.

Özetlemek gerekirse, herhangi bir ağ kurulumu gerekliyse, sunucunuz ve yedekleme bilgisayarınız için statik IP'leri ayarlamak için bir alt ağ maskesi 255.255.255.0 ile sınırlandırılmalıdır.

İyi şanslar!

Düzenle:

@ Khrystoph bu cevabı bu konuda dokundu

Hız oranlarını nasıl artıracak? Lütfen cevabınızı açıklayabilir misiniz?
— AL
1
Potansiyel olarak hızı artıracaktır çünkü sizi yavaşlatan ara ağ hakkında endişelenmeniz gerekmez. "Tipik" vs "geçit" ethernet kabloları ile ilgili olarak - 1 Gb ethernet gerektiği gibi otomatik geçiş yapar. HP ethernet anahtarları bunu 100 Mb'de yapacak. Genelde değil, diğer markalar ve 100Mb'ye takılırsanız bir çaprazlamaya ihtiyacınız olacak.
— Dan Pritts
1

Birkaç kişi ssh'yi atlamanızı önerir çünkü şifreleme sizi yavaşlatır. Modern CPU'lar aslında 1Gb'de yeterince hızlı olabilir, ancak OpenSSH, iç pencere uygulamasında sizi büyük ölçüde yavaşlatabilecek problemlerle karşılaşıyor.

Bunu ssh ile yapmak istiyorsanız, HPN SSH'ye bir bakın . Pencereleme problemlerini çözer ve çok iş parçacıklı şifreleme ekler. Maalesef, ssh'yi hem istemci hem de sunucu üzerinde yeniden kurmanız gerekecek.

— Dan Pritts
kaynak
0

Tamam Bu soruyu birbirine "yakın" olan "çok büyük borulara" (10Gbe) sahip iki bilgisayar için cevaplamaya çalıştım.

Burada karşılaştığınız sorun şudur: borular çok büyük olduğu için çoğu sıkıştırma CPU'da tıkanacaktır.

10GB dosya aktarma performansı (6 Gb ağ bağlantısı [linode], sıkıştırılamaz veri):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

Ve 10 Gbe'de iki kutu, netcat'ın biraz eski sürümleri (CentOs 6.7), 10GB dosya:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

Yani bir keresinde netcat diğer toplumda daha az cpu kullandı, yani YMMV.

Netcat ile "-N -q 0" seçeneğine sahip değilse kesilmiş dosyaları aktarabilir, dikkatli olun ... "-w 10" gibi diğer seçenekler de kesilmiş dosyalara yol açabilir.

Neredeyse tüm bu durumlarda olan şudur, ağın değil, cpu'nun maksimize edilmesi. scp230 MB / s'de maksimuma çıkar, bir çekirdeği% 100 kullanımda sabitler.

Iperf3 ne yazık ki bozuldu dosyalar . Netcat'ın bazı sürümleri tüm dosyayı aktarmıyor gibi görünüyor, çok garip. Özellikle eski versiyonları.

"Netcat'a boru olarak gzip" veya "mbuffer" gibi çeşitli teşvikler de gzip veya mbuffer ile CPU'yu maksimuma çıkarmış gibi görünüyordu; lz4 yardımcı olabilir. Buna ek olarak, denediğim bazı gzip borusu özelliklerinden bazıları çok büyük (> 4 GB) dosyalar için bozuk aktarımlara neden oldu, bu yüzden orada dikkatli olun :)

Özellikle daha yüksek gecikme süresi için işe yarayabilecek başka bir şey (?) Tcp ayarlarını yapmaktır. İşte önerilen değerlerden bahseden bir rehber:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm ve https://fasterdata.es.net/host-tuning/linux/ (başka bir cevaptan) muhtemelen IRQ ayarları: https://fasterdata.es .net / konak ayar / 100g ayar /

linode'dan gelen öneriler, /etc/sysctl.conf dosyasına ekleyin:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq

Ek olarak, koşmanızı istiyorlar:

 /sbin/ifconfig eth0 txqueuelen 10000

değişikliklerin de zarar vermeyeceğinden emin olmak için ince ayar yapıldıktan sonra çift kontrol etmeye değer.

Ayrıca pencere boyutunu ayarlamaya değer olabilir: https://iperf.fr/iperf-doc.php#tuningtcp

Yavaş (er) bağlantılarda sıkıştırma işlemi kesinlikle yardımcı olabilir. Büyük borularınız varsa, çok hızlı sıkıştırma , kolayca sıkıştırılabilir verilerle yardımcı olabilir , denemedim.

"Sabit sürücüleri senkronize etmek" için standart cevap, mümkün olduğunda aktarımı engelleyen dosyaları yeniden senkronize etmektir.

Başka bir seçenek: "paralel scp" kullanın (bir şekilde veya diğer), o zaman daha fazla çekirdek kullanacaktır ...

— rogerdpack
kaynak
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.