Olen jatko-opiskelija, ja ryhmä, jossa työskentelen, ylläpitää Linux-klusteria. Jokaisella klusterin solmulla on oma paikallinen levy, mutta nämä paikalliset levyt ovat suhteellisen pieniä eikä niissä ole automaattista varmuuskopiointia. Joten ryhmä omistaa tiedostopalvelimen, jossa on paljon TB: tä tallennustilaa. Olen suhteellinen Linux-aloittelija, joten en ole varma, mitkä ovat tiedostopalvelimen ominaisuudet nopeuden, verkkokyvyn jne. Suhteen. Tiedän kokemuksesta, että paikalliset levyt ovat huomattavasti nopeampi kuin tiedostopalvelin I / O: n suhteen . Noin kymmenkunta ihmistä käyttää tiedostopalvelinta.

Käyttämällä cp ~ 20 Gt: n tiedoston kopioiminen tiedostopalvelimesta johonkin paikallisista levyistä kestää keskimäärin noin 11,5 minuuttia reaaliajassa (time). Tiedän, että tämä cp -operaatio ei ole kovin tehokas, koska (1) time kertoo minulle, että tällaisen kopion järjestelmäaika on vain ~ 45 sekuntia; ja koska (2) kun tutkin top kopion aikana, % CPU on melko alhainen (tarkastuksen perusteella noin keskimäärin 0-10% ).

cp -toiminnon käyttäminen saman ~ 20 Gt: n tiedoston kopioimiseksi paikallisen levyn kansiosta toiseen samalla paikallisella levyllä olevaan kansioon vie vähemmän aikaa – noin 9 minuuttia reaaliajassa (~ 51 sekuntia järjestelmäaikassa time mukaan). Joten ilmeisesti tiedostopalvelin on jonkin verran hitaampi kuin paikallinen levy, kuten odotettiin, mutta ehkä ei merkittävästi hitaampi. Olen yllättynyt siitä, että kopiointi paikallisesta samaan paikalliseen ei ole nopeampaa kuin 9 minuuttia.

Minun on kopioitava ~ 200 isoa tiedostoa – kukin ~ 20 Gt – tiedostopalvelimesta johonkin paikallisista levyistä. Joten kysymykseni kuuluu: Onko cp: lle nopeampi vaihtoehto suurten tiedostojen kopioimiseksi Linuxissa? (Vai onko cp -alueella lippuja, joita voisin käyttää ja jotka nopeuttavat kopiointia?) Vaikka voisin jollain tavalla ajaa minuutin pois tästä kopiointiajasta, se auttaa valtavasti.

Olen varma, että ostan uusia, nopeampia laitteistolevyjä, mutta minulla ei ole pääsyä tällaisiin resursseihin. En ole myöskään järjestelmänvalvoja – olen vain (aloittelija) käyttäjä – – joten minulla ei ole pääsyä tarkempiin tietoihin levyillä olevasta kuormituksesta. Tiedän, että vaikka noin tusina ihmistä käyttää tiedostopalvelinta päivittäin, olen ainoa henkilö, joka käyttää tätä solmua / paikallista levyä.

Kommentit

  • Se tekee noin 29 Mt / s, mikä on melko nopeaa, jos kysyt minulta. En ’ usko, että ’ ei ole mitään komentoa, joka nopeuttaa tätä, ” pullonkaula ” on todennäköisesti a) verkko tai b) tiedostopalvelin.
  • tink on 100% oikea. En ’ ole koskaan nähnyt mitään, mikä voisi parantaa tätä. Ainoa asia, jonka olen aiemmin tehnyt ’, on pakata tiedot ennen lähettämistä, mutta se tarkoittaa, että ’ lisäät aikaa pakkausvaiheen ja purkuaskelmien kanssa, mutta joskus se on ’ sen arvoista, jos data on hyvä pakattava ehdokas!
  • Voit myös kokeilla dd ja rsync vertailla sitä, mikä toimii nopeammin ympäristössäsi
  • @Salton Kiitos. En ole vielä kokeillut dd, mutta yritin juuri rsync. Todellinen aika oli noin 11,5 minuuttia ja järjestelmäaika noin 1,5 minuuttia time -standardin mukaan.
  • I ’ yllättynyt kukaan ei ole huomauttanut, että paikallisesta levystä paikalliselle levylle -kopiointi voitaisiin tehdä tehokkaammaksi asentamalla useita levyjä. Kopiointi kohteesta /dev/sda1 kohteeseen /dev/sdb1 tulee olemaan nopeampi kuin kopiointi yhdestä sijainnista osoitteessa /dev/sda1 toiseen sijaintiin /dev/sda1 tai toiseen osioon /dev/sda, koska kiintolevy voitti ’ t täytyy tehdä lisää hakuja lukemisen ja kirjoittamisen välillä (olettaen, että perinteiset kiintolevyt pyörivät levyt ja liikkuvat päät; SSD on tietysti erilainen).

Vastaa

Prosessorin prosenttiosuuden pitäisi olla alhainen kopioinnin aikana. Suoritin kertoo levy-ohjaimelle ”napata tietoja sektorista X – Y muistipuskuriin Z: ssä”. Sitten se menee ja tekee jotain muuta (tai nukkua, jos muuta ei ole). Laitteisto laukaisee keskeytyksen, kun tiedot ovat muistissa. Sitten CPU: n on kopioitava se muutaman kerran ja käsketään verkkokorttia ”lähettämään paketteja muistipaikoissa A, B ja C”. Sitten palataan tekemään jotain muuta.

Työnnä ~ 240mbps.Gigabittisellä lähiverkolla sinun pitäisi pystyä suorittamaan vähintään 800 Mbps, mutta:

  1. Se jaetaan kaikkien tiedostopalvelinta käyttävien (ja mahdollisesti kytkinten välisen yhteyden jne.) Kesken
  2. Tätä rajoittaa nopeus, jonka tiedostopalvelin pystyy käsittelemään kirjoittamisen, pitäen mielessä, että kaikki sen käyttäjät jakavat levyn I / O-kaistanleveyden.
  3. Et määritä, miten käytät tiedostopalvelinta (NFS, CIFS (Samba), AFS jne.). Sinun on ehkä viritettävä verkkokiinnitys, mutta kaikessa puoli viimeaikaisessa oletukset ovat yleensä melko järkeviä.

Pullonkaulan jäljittämiseksi, iostat -kx 10 tulee olemaan hyödyllinen komento. Se ”näyttää sinulle paikallisten kiintolevyjen käytön. Jos voit suorittaa sen tiedostopalvelimella, se kertoo kuinka kiireinen tiedostopalvelin on.

Yleinen ratkaisu tulee olemaan nopeuta pullonkaulaa, jolle ei tietenkään ole budjettia. Mutta on olemassa muutama erityistapa, joissa voit löytää nopeamman lähestymistavan:

  • Jos tiedostot ovat pakattavia, ja sinulla on nopea CPU, minimaalisen pakkauksen tekeminen lennossa saattaa olla nopeampaa. Jotain lzop tai ehkä gzip --fastest.
  • Jos muutat vain muutama bitti täällä ja siellä ja lähetät sitten tiedoston takaisin, vain deltojen lähettäminen on paljon nopeampaa. Valitettavasti rsync ei todellakaan auta tässä, koska sen täytyy lukea tiedosto molemmilta puolilta löytääkseen delta. Sen sijaan tarvitset jotain, joka seuraa deltaa, kun muutat tiedostoa … Useimmat lähestymistavat ovat sovelluskohtaisia. Mutta on mahdollista, että pystyt korjaamaan jotain esimerkiksi laitteen mapperilla (katso upouusi dm-aikakauden kohde ) tai btrfs: llä.
  • Jos kopioit samat tiedot useampiin koneisiin, voit lähettää ne kaikille koneille kerralla käyttämällä jotakin udpcastia.

Ja, koska huomaat, ettet ole sysadmin, arvaan, että sinulla on sysadmin. Tai ainakin joku, joka on vastuussa tiedostopalvelimesta &. Sinun pitäisi todennäköisesti kysyä häneltä / Hänen tulee tuntea paljon paremmin asennuksen erityispiirteet. Järjestelmänvalvojiesi tulisi ainakin osata kertoa, minkä siirtonopeuden voit kohtuudella odottaa.

Kommentit

  • +1 iostat -kx 10: lle 🙂

Vastaa

Tämä voi mahdollisesti olla nopeampi vaihtoehto, etkä tukkeudu verkkoa kahdeksi päiväksi: Ota yksi tai kaksi isoa USB (jos sinulla on USB 3) tai FireWire-levyä, liitä se palvelimelle ja kopioi tiedostot levylle. Siirrä levy paikalliseen koneeseesi. Kopioi tiedostot koneelle.

Kommentit

Vastaa

Jos sinulla on suora SSH (tai SFTP) pääsy (kysy järjestelmänvalvojalta), voit käyttää scp -pakettia (-C): 

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

Tietysti siitä on hyötyä vain, jos tiedosto on pakattava, ja tämä käyttää enemmän suorittimen aikaa, koska se käyttää salausta (koska se on SSH: n kautta) ja pakkaa.

Kommentit

  • Tässä tapauksessa olisi hyödyllistä poistaa käytöstä salaus. Muista, että yritämme tehdä kopiosta nopeamman .
  • @lgeorget Epäilen, että salauksen yleiskustannukset voittivat ’ t , ottaen huomioon kuinka hitaat kiintolevyt ovat. Harkitsin lisätä jotain aiheesta -c none, mutta se näyttää olevan epätyypillinen .
  • ’ Käsittelemme ~ 20G-tiedostoja, joten on melko tehoton käyttää salausta, jos sitä ei tarvita.
  • @lgeorget Salaus voidaan tehty paljon nopeammin kuin läpimenon, jonka hän ’ saa, joten se voitti ’ ei hidasta mitään. Mutta tuntuu turhalta käydä läpi SSH täällä. Jos tarvitset vain pakkaamista, on olemassa muita työkaluja?
  • @Thomas SSH: n etuna on, että jos ’ oletetaan pääsevän etäpalvelimeen, sitten se ’ käyttää melkein varmasti SSH: ta. Toinen vaihtoehto olisi pakata tiedosto paikallisesti, kopioida se palvelimelle, sitten ssh sisään ja purkaa se.

Vastaus

Tehokkuuden määritelmäsi on taaksepäin. Tehokkaampi toteutus tuhlaa vähemmän prosessorin aikaa. Paikallisessa kopiossa olet keskimäärin noin 74 Mt / s (luku + kirjoitus), mikä on suunnilleen yhtä hyvä kuin yksi kiintolevy saa.

Kommentit

  • Hups.Kun sanoin ” tehokas, ” tarkoitin ” nopeaa. ”

vastaus

cp toteutus ei todennäköisesti ole pullonkaula. Yritä tarkkailla IO: n käyttöä iotop kautta sekä palvelimen että klusterisolmun kautta. Tämä antaa sinulle idean, missä voit parantaa suorituskykyä.

Toinen vinkki on välttää kopioimasta samoja tietoja samasta isännästä. Esimerkiksi, jos sinulla on identtinen 20G-tiedosto jaettavaksi tiedostopalvelimelta verkon kautta kaikkiin klusterisolmuihin, se toimii paljon nopeammin, jos kopioit tiedostoja vertaisvertaisella tavalla yhden palvelimen ja kaikkien asiakkaiden välillä. Sen toteuttaminen on hieman monimutkaisempaa, mutta voit jopa yrittää käyttää komentorivip2p: tä, kuten suorakytkentäkeskitin.

Jos kyseisissä 20G-tiedostoissa osa on yleinen ja osa klusterisolmukohtaisia, harkitse jakamalla se yhteisiin ja erityisiin osiin ja jakamalla sitten yhteinen osa p2p-tavalla.

Kommentit

  • Jos ’ uudelleen lähiverkossa, sinun pitäisi pystyä suorittamaan monilähetys vertaisverkon sijaan. Sen pitäisi olla nopeampaa ja vähemmän kuormitettavaa verkolle.

Vastaa

Noiden tiedostojen luonteella / sisällöllä voi olla merkitystä. Ymmärsin, että sinun on kopioitava 200 tiedostoa (~ 20 Gt kukin) tietokoneelta toiselle , onko se?

Jos nämä tiedostot ovat pakattavissa tai samankaltaisilla / identtisillä kappaleilla, sinulla on kaksi lähestymistapaa:

  • zip ne ennen kopiointia tai luo tiedosto tunneli tietokoneiden välillä, joissa on zip-ominaisuus. Joten jos verkko on pullonkaula, se on hieman huono r

  • jos tiedostot ovat hyvin samankaltaisia tai jakavat joitain yleisen sisällön kappaleita keskenään, kokeile käyttää rsync . Se viettää jonkin aikaa tiedostojen yhteisen löytämiseen, eikä sitä tarvitse kopioida kirjaimellisesti , koska se ”rekonstruoi sen yleisen perusteella.

edit

Pitäisikö sinun kopioida nuo tiedostot monta kertaa ?? (kuten kopio -> käyttää niitä tiedostoja -> muuttaa jotain tiedostoista tietokoneessa A -> kopioi tiedostot uudelleen tietokoneeseen B)

Jos on, rsync on hyödyllinen, koska se ”yrittää havaita, mikä on yhtä suuri versioiden välillä, ja älä kopioi sitä, joka on muuttumaton.

Ja kolmas tapa: jos yllä oleva on oikein (muutokset tiedostossa, kopioi sitten kaikki tiedostot uudelleen toiseen tietokoneeseen), voit kokeilla binary diff muuta toisessa tietokoneessa mitä ensimmäisessä tietokoneessa muutettiin.

Vastaa

Näen täällä seuraavat, salaus ei ole hyvä idea, koska se saattaa lisätä LISÄÄ siirrettävien tietojen määrää.

Jos kopioit kahden järjestelmän välillä, pullonkaula on tietysti t palvelinten välinen yhteys.

Jos kopioit paikallisesti, katso kuinka prosessi etenee, se on SINGLE-kierteinen, joten tavalliset Linux-apuohjelmat käyttävät: 

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

Tällä toiminnolla ei ole yhtäläisyyttä.

Asioiden nopeuttamiseksi voit käyttää jotain tällaista: 

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

Katso lisätietoja puskurin (1) man-sivulta.

Puskurikomento asettaa kaksi prosessia suorittamaan kopiointiprosessin samanaikaisesti: yhden lukemista ja toisen kirjoittamista varten, ja se käyttää jaettua muistipuskuria tietojen välittämiseen kahden prosessin välillä. Jaettu muistipuskuri on klassinen pyöreä puskuri, joka estää kirjoittamattomien tietojen korvaamisen ja jo kirjoitettujen tietojen kirjoittamisen. Olen käyttänyt tätä ohjelmaa katkaisemaan noin 10-20% kopiointiajasta siirtämisessä levyltä nauhalle.

Kommentit

  • Itse asiassa on samanaikaisuus ” -kohdassa lukea lohko / kirjoittaa lohko ”, koska ” kirjoittaa lohkon ” laittaa sen oikeastaan vain ytimen ’ -puskuriin, ja ydin käsittelee varsinaisen lohkokirjoituksen taustalla (ainakin, kunnes aloita RAM-muistin loppuminen). Tai jos käytät jostain syystä O_DSYNC / O_SYNC.

Vastaa

Miksi ei kokeilla P2P-etenemisalgoritmia , jos sinun on päivitettävä koko klusterisi samanaikaisesti?

https://github.com/lg/murder on mitä twitter käyttää

Siellä on ”s BTSync , jota voit myös kokeilla.

Vastaa

Jos kopioit samoja tiedostoja usein paikalliselta tietokoneelta palvelimelle pienin muutoksin täällä ja siellä. Voit nopeuttaa siirtoa käyttämällä rsync tai DVCS (esim. Hg tai git).

git tai hg voivat seurata ja havaita deltoja ja siirtää vain deltoja. Jos käytössä on git, koska molemmilla osapuolilla on koko arkisto historia, delta-arvon selvittäminen on erittäin halpaa.

rsync käyttää rullaavan tarkistussumman algoritmia havaitsemaan deltat ilman etukäteen tietoa toisella puolella olevista asioista. Vaikka deltojen laskeminen vie enemmän työtä, rsync tarvitsee tallentaa koko tiedostohistoria.

Vastaa

Voit yrittää pakata kaikki tiedostot yhteen arkistoon (ei tarvitse pakata). Kokemukseni mukaan yhden arkiston kopiointi on nopeampi kuin suuren määrän yksittäisten tiedostojen kopiointi

Kommentit

  • Hyvä yleinen havainto, mutta kuten kysymyksessä sanotaan ”~ 200 isoa tiedostoa – kukin ~ 20 Gt”, en usko ’ uskoa, että tätä voidaan pitää todellisena vastauksena tähän ongelmaan.
  • @manatwork ah .. en lukenut ’ lukenut selvästi. Luulin, että hänellä oli 200 tiedostoa yhteensä 20 Gt

Vastaa

Kokeile bbcp . Ympäristömme testaus paljasti, että cp: llä oli jonkinlainen o f sisäänrakennettu governer. Ole vain varovainen, koska kun irrotat päällikkö, voit linjata palvelimesi ja aiheuttaa katkon. Meidän tapauksessamme otimme palvelimen offline-tilaan kopiointia varten, joten nopeampi oli parempi. Tämä paransi siirtoaikaa useita tunteja.

Vastaa

Varmista, että kohde tiedostoja ei ole ennen kopiointia.

Joskus on yllättävää, kuinka paljon aikaa kuluu edes vain kopioimalla samalle isännälle (ei verkkoa mukana).

Katso vastaukseni toiseen cp-kysymykseen täällä . Pitkä tarina, olemassa olevan tiedoston korvaaminen on paljon hitaampaa kuin sen katkaiseminen tai linkityksen purkaminen ensin jälkimmäinen on kahdeksan kertaa nopeampi 1,2 Gt: n tiedostolle.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *