Sunt student absolvent, iar grupul în care lucrez menține un cluster Linux. Fiecare nod al clusterului are propriul său disc local, dar aceste discuri locale sunt relativ mici și nu sunt echipate cu backup automat. Deci, grupul deține un server de fișiere cu multe TB de spațiu de stocare. Sunt un novice relativ la Linux, deci nu sunt sigur care sunt specificațiile serverului de fișiere în ceea ce privește viteza, capacitatea de rețea etc. Știu din experiență că discurile locale sunt semnificativ mai rapide decât serverul de fișiere în ceea ce privește I / O . Aproximativ o duzină de oameni folosesc serverul de fișiere.

Utilizarea cp pentru a copia un fișier de ~ 20 GB de pe serverul de fișiere pe unul dintre discurile locale durează în medie aproximativ 11,5 minute în timp real (conform time). Știu că această operațiune cp nu este foarte eficientă deoarece (1) time îmi spune că timpul de sistem pentru o astfel de copie este doar ~ 45 de secunde; și pentru că (2) când examinez top în timpul copierii, % CPU este destul de scăzut (prin inspecție, aproximativ 0-10% în medie).

Utilizarea cp pentru a copia același fișier de ~ 20 GB dintr-un folder de pe discul local într-un alt folder de pe același disc local necesită mai puțin timp – aproximativ 9 minute în timp real (~ 51 de secunde în timpul sistemului, conform time). Deci, se pare că serverul de fișiere este ceva mai lent decât discul local, așa cum era de așteptat, dar poate nu semnificativ mai lent. Sunt surprins că copierea de la local la același local nu depășește 9 minute.

Am nevoie să copiez ~ 200 de fișiere mari – fiecare ~ 20 GB – de la serverul de fișiere pe unul dintre discurile locale. Deci, întrebarea mea este: Există o alternativă mai rapidă la cp pentru copierea fișierelor mari în Linux? (Sau există semnalizări în cadrul cp pe care le-aș putea folosi, care ar accelera copierea?) Chiar dacă aș putea cumva să scutesc un minut din acest timp de copiere, ajuta imens.

Sunt sigur că cumpărarea unor discuri hardware noi și mai rapide, dar nu am acces la astfel de resurse. De asemenea, nu sunt administrator de sistem – sunt doar un utilizator (începător) – – deci nu am acces la informații mai detaliate despre încărcarea pe discuri. Știu că, în timp ce aproximativ o duzină de persoane folosesc serverul de fișiere zilnic, sunt singura persoană care folosește acest nod / disc local.

Comentarii

  • Asta face aproximativ 29 MB / s, ceea ce este destul de rapid dacă mă întrebați. Nu ‘ nu cred că există ‘ orice comandă care va accelera acest lucru, ” blocaj ” este cel mai probabil a) rețeaua sau b) serverul de fișiere.
  • tink este 100% corect. ‘ nu am văzut niciodată nimic care să poată îmbunătăți acest lucru. Singurul lucru pe care l-am făcut ‘ în trecut este să comprim datele înainte de a le trimite, dar asta înseamnă că ‘ adăugați timp cu pașii de comprimare și pași de decompresie, dar uneori merită ‘ dacă datele sunt un bun candidat pentru a fi comprimate!
  • Puteți încerca și dd și rsync pentru a compara care funcționează mai repede în mediul dvs.
  • @Salton Mulțumesc. Nu am încercat încă dd, dar am încercat rsync. Timpul real a fost de aproximativ 11,5 minute, iar timpul sistemului a fost de aproximativ 1,5 minute, conform time.
  • I ‘ M-am mirat că nimeni nu a subliniat că discul local pe copia locală a discului ar putea deveni mai eficient prin montarea mai multor discuri. Copierea de la /dev/sda1 la /dev/sdb1 va fi mai rapidă decât copierea dintr-o locație pe /dev/sda1 la o altă locație de pe /dev/sda1 sau altă partiție pe /dev/sda deoarece hard disk-ul a câștigat ‘ t trebuie să fac căutări suplimentare între citiri și scrieri (presupunând că hard disk-urile tradiționale cu discuri rotative și capete în mișcare; SSD-ul este evident diferit). = „answer”>

    % CPU ar trebui să fie scăzut în timpul copierii. CPU îi spune controlerului de disc „preluați date din sectoarele X – Y în memoria tampon la Z”. Apoi merge și face altceva (sau doarme, dacă nu există altceva). Hardware-ul declanșează o întrerupere atunci când datele sunt în memorie. Apoi procesorul trebuie să-l copieze de câteva ori și spune cartelei de rețea „transmite pachete în locațiile de memorie A, B și C”. Apoi se întoarce la a face altceva.

    Împingi ~ 240mbps.Pe o rețea LAN gigabit, ar trebui să puteți face cel puțin 800 Mbps, dar:

    1. Acest lucru este partajat între toți utilizatorii serverului de fișiere (și, eventual, o conexiune între comutatoare etc.)
    2. Acest lucru este limitat de viteza pe care serverul de fișiere o poate gestiona la scriere, ținând cont de lățimea de bandă I / O a discului este partajată de toți utilizatorii.
    3. Nu ați specificat cum accesați serverul de fișiere (NFS, CIFS (Samba), AFS etc.). Este posibil să trebuiască să vă reglați montarea în rețea, dar pentru orice elemente semi-recente, valorile implicite sunt de obicei destul de sănătoase.

    Pentru urmărirea blocajului, iostat -kx 10 va fi o comandă utilă. Vă va arăta utilizarea pe hard disk-urile locale. Dacă puteți rula acest lucru pe serverul de fișiere, vă va spune cât de ocupat este serverul de fișiere.

    Soluția generală va fi să accelerați blocajul, pentru care, desigur, nu aveți bugetul. Dar există câteva cazuri speciale în care puteți găsi o abordare mai rapidă:

    • Dacă fișierele sunt comprimabile, și aveți un procesor rapid, a face o compresie minimă din mers ar putea fi mai rapid. Ceva de genul lzop sau poate gzip --fastest.
    • Dacă schimbați doar câțiva biți aici și colo și apoi trimiteți fișierul înapoi, numai trimiterea deltelor va fi mult mai rapidă. Din păcate, rsync nu va ajuta cu adevărat aici, deoarece va trebui să citească fișierul de ambele părți pentru a găsi delta. În schimb, aveți nevoie de ceva care să țină evidența deltei pe măsură ce schimbați fișierul … Cele mai multe abordări de aici sunt specifice aplicației. Dar este posibil să puteți instala ceva cu, de exemplu, dispozitiv-mapper (consultați noul țintă dm-era ) sau btrfs.
    • Dacă copiați aceleași date pe mașini multiple , puteți utiliza ceva de genul udpcast pentru a le trimite la toate mașinile simultan.

    Și, întrucât observați că nu sunteți administratorul de sistem, presupun că asta înseamnă că aveți un administrator de sistem. Sau cel puțin cineva responsabil pentru rețeaua serverului de fișiere &. ei / ei, ar trebui să fie mult mai familiarizați cu specificul configurării dvs. Administratorii dvs. ar trebui cel puțin să vă poată spune la ce rată de transfer vă puteți aștepta în mod rezonabil.

    Comentarii

    • +1 pentru iostat -kx 10 🙂

Răspuns

Aceasta ar putea fi, posibil, o alternativă mai rapidă și nu veți înfunda rețeaua timp de două zile: luați unul sau două discuri USB mari (USB 3 dacă aveți) sau FireWire, conectați-le la pe server și copiați fișierele pe disc. Transportați discul pe mașina dvs. locală. Copiați fișierele pe aparat.

Comentarii

Răspuns

Dacă aveți acces SSH direct (sau SFTP) (întrebați-vă administratorul), puteți utiliza scp cu compresie (-C): 

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

Desigur, acest lucru este util numai dacă fișierul este compresibil, iar acest lucru va folosi mai mult timp CPU, deoarece va folosi criptarea (deoarece este peste SSH) și comprimarea.

Comentarii

  • În acest caz, ar fi util să dezactivați criptarea. Amintiți-vă că încercăm să facem copia mai rapidă .
  • @lgeorget Bănuiesc că cheltuielile generale ale criptării nu vor fi ‘ t semnificative , având în vedere cât de lente sunt hard diskurile. Am luat în considerare adăugarea a ceva despre -c none, dar acel pare să nu fie standard .
  • ‘ ne ocupăm de fișiere ~ 20G, deci este destul de ineficient să folosim criptarea dacă nu este necesară.
  • @lgeorget Criptarea poate fi făcut mult mai repede decât debitul pe care l-a ‘ obținut, așa că a „b9af5ea283”>

nu a încetinit nimic. Dar pare inutil să treci prin SSH aici. Dacă aveți nevoie doar de comprimare, cu siguranță există și alte instrumente?

  • @Thomas Avantajul SSH este că, dacă ‘ trebuie să aveți acces la serverul de la distanță, atunci ‘ aproape sigur rulează SSH. O altă opțiune ar fi comprimarea fișierului local, copierea acestuia pe server, apoi ssh și decomprimarea acestuia ..

    • Răspuns

    Definiția dvs. despre eficient este inversă. O implementare mai eficientă pierde mai puțin timpul procesării. Pe copia locală, calculați în medie aproximativ 74 MB / s de transfer (citire + scriere), ceea ce este la fel de bun pe cât va obține un singur hard disk.

    Comentarii

    • Hopa.Când am spus ” eficient, ” am vrut să spun ” rapid. ”

    Răspuns

    cp implementarea nu este cel mai probabil un blocaj. Încercați să observați utilizarea IO prin iotop atât pe server cât și pe nodul cluster. Acest lucru vă va oferi o idee unde puteți îmbunătăți performanța.

    Un alt sfat este să evitați copierea acelorași date de la aceeași gazdă. De exemplu, dacă aveți un fișier 20G identic de distribuit de la serverul de fișiere prin rețea la toate nodurile clusterului, acesta va funcționa mult mai repede dacă copiați fișierele peer-to-peer, mai degrabă decât de la un server la toți clienții. Este puțin mai complicat de implementat, dar puteți încerca chiar să folosiți o linie de comandă p2p, cum ar fi hub-ul de conectare directă.

    Dacă în acele fișiere 20G, o parte este comună, iar altele sunt specifice nodului cluster, luați în considerare împărțind-o în părți comune și specifice, apoi distribuie partea comună în mod p2p.

    Comentarii

    • Dacă ‘ reîntr-o rețea LAN, ar trebui să puteți face multicast în loc de peer-to-peer. Ceea ce ar trebui să fie mai rapid și mai puțin încărcat în rețea.

    Răspuns

    Natura / conținutul acelor fișiere pot face o diferență. Am înțeles că trebuie să copiați 200 de fișiere, de fiecare ~ 20 GB fiecare, de la un computer la altul , nu-i așa?

    Dacă acele fișiere sunt comprimabile sau cu piese similare / identice, aveți două abordări:

    • zip-le înainte de copiere sau creați un tunel între computerele cu activare zip. Deci, dacă rețeaua este blocajul, va fi un pic faste r

    • dacă fișierele sunt foarte similare sau partajează unele conținuturi comune între ele, încercați să utilizați rsync . Va „petrece ceva timp găsind ceea ce este obișnuit printre fișiere și nu va trebui să îl copiați literal , deoarece îl va reconstrui pe baza a ceea ce este comun.

    edit

    Va trebui să copiați acele fișiere de multe ori ?? (cum ar fi o copie -> utilizați acele fișiere -> modificați ceva din fișiere în computerul A -> copiați fișierele din nou pe computerul B)

    Dacă da, rsync va fi util, deoarece va încerca să detecteze ceea ce este egal între versiuni și nu va copia ceea ce este neschimbat.

    Și o a treia metodă: dacă cele de mai sus sunt corecte (modificări ale fișierului, apoi copiați din nou toate fișierele pe al doilea computer) puteți încerca câteva binary diff doar schimbați în al doilea computer ceea ce a fost schimbat în primul computer.

    Răspundeți

    Văd aici următoarele, criptarea nu este o idee bună, deoarece s-ar putea să crească cantitatea de date de transferat.

    Dacă copiați între două sisteme, atunci blocajul este, desigur, t conexiunea între servere.

    Dacă copiați local, uitați-vă la modul în care merge procesul, este SINGLE threaded, astfel utilitățile standard Linux folosesc: 

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

    NU există concurență la această operațiune.

    Pentru a accelera lucrurile, puteți utiliza ceva de genul acesta: 

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

    Consultați pagina de manual tampon (1) pentru mai multe informații.

    Comanda tampon configurează două procese pentru a rula procesul de copiere simultan: unul pentru citire și celălalt pentru scriere și folosește un buffer de memorie partajată pentru a comunica datele între cele două procese. Bufferul de memorie partajată este bufferul tău circular clasic, care previne suprascrierea datelor nescrise și scrierea datelor deja scrise. Am folosit acest program pentru a reduce aproximativ 10-20% din timpul de copiere în transferurile de pe disc pe bandă.

    Comentarii

    • De fapt, există concurență în ” citiți un bloc / scrieți un bloc ” deoarece ” scrieți un bloc ” îl pune de fapt doar în buffer-ul ‘ s, iar nucleul gestionează scrierea blocului real în fundal (cel puțin, până când începeți să rămâneți fără memorie RAM). Sau dacă utilizați O_DSYNC / O_SYNC din anumite motive.

    Răspuns

    De ce nu încercați un algoritm de propagare P2P , dacă trebuie să vă actualizați întregul cluster în același timp?

    https://github.com/lg/murder este ce folosește twitter

    Există „s BTSync pe care le puteți încerca și dvs.

    Răspundeți

    Dacă copiați frecvent aceleași seturi de fișiere de pe computerul dvs. local pe server cu modificări minore aici și acolo. Puteți accelera transferul utilizând rsync sau un DVCS (de exemplu, hg sau git).

    git sau hg pot urmări și detecta deltele și pot transfera doar deltele respective. În cazul utilizării unui git, deoarece ambele părți au un istoric complet al depozitului, a afla delta este foarte ieftin.

    rsync folosește o formă de rulare a algoritmului de sumă de verificare pentru a detecta deltele fără știrea prealabilă a ceea ce este de cealaltă parte. Deși rsync necesită mai multă muncă pentru a calcula deltele, nu trebuie să stocheze întregul istoricul fișierelor.

    Răspuns

    S-ar putea să doriți să încercați să împachetați toate fișierele într-o singură arhivă (nu trebuie să fie comprimate). Din experiența mea, copierea acelei arhive este mai rapidă decât copierea unui număr mare de fișiere individuale

    Comentarii

    • Observație generică bună, dar așa cum spune întrebarea „~ 200 fișiere mari – fiecare ~ 20 GB”, nu cred că ‘ nu cred că acest lucru poate fi considerat un răspuns real la această problemă.
    • @manatwork ah .. ‘ nu am citit clar. Am crezut că are 200 de fișiere în valoare totală de 20 GB

    Răspuns

    Încercați bbcp . Testarea în mediul nostru a arătat că cp avea un fel de construit în guvernator. Aveți grijă doar pentru că, atunci când îl scoateți pe guvernator, vă puteți reda linia serverului și puteți provoca o întrerupere. În cazul nostru, luam serverul offline pentru a face copia, deci mai rapid era mai bine. Acest timp de transfer îmbunătățit de câteva ore.

    Răspuns

    Asigurați-vă că ținta fișierele nu există înainte de copiere.

    Uneori este surprinzător cât de mult este petrecut chiar și doar copierea pe aceeași gazdă (nu este implicată nicio rețea).

    Vedeți răspunsul meu la o altă întrebare CP aici . Scurtă poveste, suprascrierea unui fișier existent este mult mai lentă decât trunchierea sau deconectarea acestuia mai întâi, și apoi copiere. Acesta din urmă este de 8 ori mai rapid pentru un fișier de 1,2 GB.

    Lasă un răspuns

    Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *