Jeg er kandidatstuderende, og gruppen, hvor jeg arbejder, opretholder en Linux-klynge. Hver node i klyngen har sin egen lokale disk, men disse lokale diske er relativt små og er ikke udstyret med automatisk sikkerhedskopiering. Så gruppen ejer en filserver med mange TBer lagerplads. Jeg er en relativ Linux-novice, så jeg er ikke sikker på, hvad specifikationerne til filserveren er med hensyn til hastighed, netværksmuligheder osv. Jeg ved af erfaring, at de lokale diske er betydeligt hurtigere end filserveren med hensyn til I / O . Cirka et dusin mennesker bruger filserveren.

Brug af cp til at kopiere en ~ 20 GB fil fra filserveren til en af de lokale diske tager i gennemsnit ca. 11,5 minutter i realtid (ifølge time). Jeg ved, at denne cp operation ikke er særlig effektiv, fordi (1) time fortæller mig, at systemtiden for en sådan kopi kun er ~ 45 sekunder og fordi (2) når jeg undersøger top under kopien, % CPU er ret lav (ved inspektion ca. 0-10% i gennemsnit).

Brug af cp til at kopiere den samme ~ 20 GB-fil fra en mappe på den lokale disk til en anden mappe på den samme lokale disk tager kortere tid – ca. 9 minutter i realtid (~ 51 sekunder i systemtid ifølge time). Så tilsyneladende er filserveren noget langsommere end den lokale disk, som forventet, men måske ikke signifikant langsommere. Jeg er overrasket over, at kopiering fra lokal til samme lokale ikke er hurtigere end 9 minutter.

Jeg har brug for at kopiere ~ 200 store filer – hver ~ 20 GB – fra filserveren til en af de lokale diske. Så mit spørgsmål er: Er der et hurtigere alternativ til cp til kopiering af store filer i Linux? (Eller er der nogen flag inden for cp, som jeg kunne bruge, hvilket ville fremskynde kopieringen?) Selvom jeg på en eller anden måde kunne barbere et minut af denne kopieringstid, ville det hjælp enormt.

Jeg er sikker på, at jeg køber nye, hurtigere harddiske, men jeg har ikke adgang til sådanne ressourcer. Jeg er heller ikke systemadministrator – jeg er kun en (nybegynder) bruger – – så jeg har ikke adgang til mere detaljerede oplysninger om belastningen på diskene. Jeg ved, at mens cirka et dusin mennesker bruger filserveren dagligt, er jeg den eneste person, der bruger netop denne node / lokale disk.

Kommentarer

  • Det gør omkring 29 MB / s, hvilket er ret hurtigt, hvis du spørger mig. Jeg tror ikke ‘ der ‘ er enhver kommando, der vil fremskynde dette, ” flaskehals ” er sandsynligvis a) netværket eller b) filserveren.
  • tink er 100% korrekt. Jeg ‘ har aldrig set noget, der kan forbedre dette. Det eneste, jeg ‘ tidligere har gjort, er at komprimere dataene inden jeg sender dem, men det betyder at du ‘ tilføjer tid med komprimeringstrin og dekompressionstrin, men nogle gange er ‘ det værd, hvis dataene er en god kandidat til at blive komprimeret!
  • Du kan også prøve dd og rsync for at sammenligne hvilken der fungerer hurtigere i dit miljø
  • @Salton Tak. Jeg har endnu ikke prøvet dd, men jeg har lige prøvet rsync. Den virkelige tid var ca. 11,5 minutter, og systemtiden var ca. 1,5 minutter ifølge time.
  • I ‘ Jeg er overrasket over, at ingen har påpeget, at den lokale disk til lokale disk kopi kunne gøres mere effektiv ved at have flere diske monteret. Kopiering fra /dev/sda1 til /dev/sdb1 vil være hurtigere end kopiering fra et sted på /dev/sda1 til en anden placering på /dev/sda1 eller en anden partition på /dev/sda fordi harddisken vandt ‘ t er nødt til at søge yderligere mellem læsning og skrivning (forudsat at traditionelle harddiske med roterende diske og bevægelige hoveder; SSD er tydeligvis anderledes).

Svar

% CPU skal være lav under en kopi. CPUen fortæller diskcontrolleren “grab data fra sektorer X – Y til hukommelsesbuffer ved Z”. Så går det og gør noget andet (eller sover, hvis der ikke er noget andet). Hardwaren udløser et afbrydelse, når dataene er i hukommelsen. Derefter skal CPUen kopiere det et par gange og fortæller netværkskortet “sende pakker på hukommelsesstederne A, B og C”. Derefter går det tilbage til at gøre noget andet.

Du skubber ~ 240 Mbps.På et gigabit LAN bør du være i stand til at gøre mindst 800 Mbps, men:

  1. Det deles blandt alle, der bruger filserveren (og muligvis en forbindelse mellem switche osv.)
  2. Dette er begrænset af den hastighed, filserveren kan håndtere skrivningen, idet dens I / O-båndbredde deles af alle, der bruger den.
  3. Du specificerede ikke, hvordan du har adgang til filserveren (NFS, CIFS (Samba), AFS osv.). Du skal muligvis indstille din netværksmontering, men på noget, der er halvt nylig, er standardindstillingerne normalt ret sane.

For at spore flaskehalsen iostat -kx 10 vil være en nyttig kommando. Det viser dig brugen på dine lokale harddiske. Hvis du kan køre det på filserveren, fortæller det dig, hvor travl filserveren er.

Den generelle løsning vil være at fremskynde flaskehalsen, som du selvfølgelig ikke har budgettet til. Men der er et par specielle tilfælde, hvor du kan finde en hurtigere tilgang:

  • Hvis filerne er komprimerbare, og du har en hurtig CPU, at lave en minimal komprimering on-the-fly kan være hurtigere. Noget som lzop eller måske gzip --fastest.
  • Hvis du kun ændrer et par bits her og der og derefter sender filen tilbage, vil det kun være hurtigere at sende deltas. Desværre rsync vil ikke virkelig hjælpe her, da det bliver nødvendigt at læse filen på begge sider for at finde deltaet. I stedet har du brug for noget, der holder styr på deltaet, når du ændrer filen … De fleste tilgange her er appspecifikke. Men det er muligt, at du kan rigge noget op med f.eks. Enhedsmapper (se det splinternye dm-era-mål ) eller btrfs.
  • Hvis du kopierer de samme data til flere maskiner, kan du bruge noget som udpcast til at sende dem til alle maskiner på én gang.

Og, da du bemærker, at du ikke er sysadmin, gætter jeg på, at du har en sysadmin. Eller i det mindste en person, der er ansvarlig for filserveren & netværk. Du bør nok spørge ham / hende / dem, de burde være meget mere fortrolige med detaljerne i din opsætning. Dine sysadmin (r) skal i det mindste være i stand til at fortælle dig, hvilken overførselshastighed du med rimelighed kan forvente.

Kommentarer

  • +1 for iostat -kx 10 🙂

Svar

Dette kan muligvis være et hurtigere alternativ, og du tilstopper ikke netværket i to dage: Tag en eller to store USB (USB 3, hvis du har det) eller FireWire-diske, tilslut den til serveren og kopiere filerne til disken. Bær disken til din lokale maskine. Kopier filerne til maskinen.

Kommentarer

Svar

Hvis du har direkte SSH (eller SFTP) adgang (spørg din sysadmin), kan du bruge scp med komprimering (-C): 

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

Det er selvfølgelig kun nyttigt, hvis filen er komprimerbar, og dette vil bruge mere CPU-tid, da det bruger kryptering (fordi det er over SSH) og komprimeres.

Kommentarer

  • I dette tilfælde ville det være nyttigt at deaktivere krypteringen. Husk, at vi forsøger at gøre kopien hurtigere .
  • @lgeorget Jeg formoder, at krypteringsomkostningerne ‘ ikke har betydning overvejer, hvor langsomme harddiske er. Jeg overvejede at tilføje noget om -c none, men at ser ud til at være ikke-standard .
  • Vi ‘ beskæftiger os med ~ 20G-filer, så det er ret ineffektivt at bruge kryptering, hvis det ikke er nødvendigt.
  • @lgeorget Kryptering kan være gjort langt hurtigere end den gennemstrømning, han ‘ får, så det vinder ‘ ikke noget langsommere. Men det virker unødvendigt at gå gennem SSH her. Hvis du bare har brug for komprimering, er der sikkert andre værktøjer?
  • @Thomas Fordelen ved SSH er, at hvis du ‘ formodes at have adgang til fjernserveren, så kører det ‘ næsten helt sikkert SSH. En anden mulighed ville være at komprimere filen lokalt, kopiere den til serveren, derefter ssh ind og dekomprimere den ..

Svar

Din definition af effektiv er bagud. En mere effektiv implementering spilder mindre CPU-tid. På den lokale kopi har du gennemsnitligt ca. 74 MB / s gennemløb (læs + skriv), hvilket er omtrent lige så godt som en enkelt harddisk vil få.

Kommentarer

  • Ups.Da jeg sagde ” effektiv, ” mente jeg ” hurtigt. ”

Svar

cp implementering er sandsynligvis ikke en flaskehals. Prøv at observere IO-brug via iotop på både server og klyngenode. Dette giver dig en idé om, hvor du kan forbedre ydeevnen.

Et andet tip er at undgå at kopiere de samme data fra samme vært. For eksempel, hvis du har identisk 20G-fil, der skal distribueres fra filserver over netværket til alle klyngenoder, fungerer den meget hurtigere, hvis du kopierer filer på peer-to-peer-måde snarere end en-server-til-alle-klienter. Det er lidt mere kompliceret at implementere, men du kan endda prøve at bruge nogle kommandolinje p2p som direkte forbindelseshub.

Hvis der inden for de 20G-filer er en del almindelig, og nogle er klyngenode-specifikke, overvej opdele det i almindelige og specifikke dele og derefter distribuere fælles del på p2p-måde.

Kommentarer

  • Hvis du ‘ på et LAN skal du være i stand til at udføre multicast i stedet for peer-to-peer. Hvilket skal være hurtigere og mindre belastning på netværket.

Svar

Arten / indholdet af disse filer kan gøre en vis forskel. Jeg forstod, at du skal kopiere 200 filer, ~ 20 GB hver, fra en computer til en anden , er det det?

Hvis disse filer er komprimerbare eller med lignende / identiske stykker, har du to tilgange:

  • zip dem inden kopiering, eller opret en tunnel mellem computere med zip-aktiveret på det. Så hvis netværket er flaskehalsen, vil det være lidt fast r

  • hvis filerne er meget ens eller deler nogle af fælles indhold blandt dem, så prøv at bruge rsync . Det vil bruge lidt tid på at finde ud af, hvad der er almindeligt blandt filerne, og behøver ikke at kopiere det bogstaveligt talt , fordi det rekonstruerer det ud fra, hvad der er almindeligt.

redigering

Skal du kopiere disse filer mange gange ?? (som en kopi -> bruge disse filer -> ændre noget i filerne i computeren A -> kopier filer igen til computer B)

Hvis det er tilfældet, vil rsync være nyttigt, fordi det “forsøger at opdage, hvad der er lige mellem versionerne og ikke kopiere det, der er uændret.

Og en tredje metode: hvis ovenstående er korrekt (ændringer i fil, så kopier alle filer igen til den anden computer), kan du prøve noget binary diff til bare ændring i den anden computer, hvad der blev ændret på den første computer.

Svar

Jeg ser følgende her, kryptering er ikke en god idé, da det muligvis ØGER mængden af data, der skal overføres.

Hvis du kopierer mellem to systemer, er flaskehalsen selvfølgelig ikke forbindelsen mellem serverne.

Hvis du kopierer lokalt, skal du se på, hvordan processen går, den er ENKELT gevind, så standard Linux-værktøjer bruger: 

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

Denne handling er INGEN samtidighed.

For at fremskynde tingene kan du bruge noget som dette: 

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

Se bufferen (1) mandesiden for mere information.

Bufferkommandoen opretter to processer til at køre kopiprocessen samtidigt: den ene til læsning og den anden til skrivning, og den bruger en delt hukommelsesbuffer til at kommunikere dataene mellem de to processer. Den delte hukommelsesbuffer er din klassiske cirkulære buffer, som forhindrer overskrivning af uskrevne data og skrivning af allerede skrevne data. Jeg har brugt dette program til at afskære ca. 10-20% af kopitiden i overførsler fra disk til tape.

Kommentarer

  • Der er faktisk samtidighed i ” læs en blok / skriv en blok ” fordi ” skriv en blok ” placerer det faktisk bare i kernen ‘ s buffer, og kernen håndterer den aktuelle blokskrivning i baggrunden (i det mindste indtil du start med at løbe tør for RAM). Eller hvis du bruger O_DSYNC / O_SYNC af en eller anden grund.

Svar

Hvorfor ikke prøve en P2P-formeringsalgoritme , hvis du har brug for at opdatere hele din klynge på samme tid?

https://github.com/lg/murder er hvad twitter bruger

Der er “s BTSync , som du også kan prøve.

Svar

Hvis du ofte kopierer de samme sæt filer fra din lokale computer til serveren med mindre ændringer her og der. Du kan fremskynde overførslen ved hjælp af rsync eller en DVCS (f.eks. Hg eller git).

git eller hg kan holde styr på og opdage deltaer og kun overføre disse deltaer. I tilfælde af brug af en git, da begge sider har fuld historik over arkivet, er det meget billigt at finde ud af deltaet.

rsync bruger en form for rullende kontrolsummingsalgoritme til at opdage deltas uden forudgående viden om, hvad der er på den anden side. Selvom det kræver mere arbejde for rsync at beregne deltas, behøver det ikke at gemme hele filhistorik.

Svar

Det kan være en god idé at prøve at pakke alle filerne i et enkelt arkiv (behøver ikke komprimeres). Efter min erfaring er det hurtigere at kopiere det ene arkiv end at kopiere et stort antal individuelle filer

Kommentarer

  • God generisk observation, men som spørgsmålet siger “~ 200 store filer – hver ~ 20 GB”, jeg tror ikke ‘ at dette kan betragtes som et faktisk svar på dette problem.
  • @manatwork ah .. jeg læste ikke ‘. Jeg troede, at han havde 200 filer på i alt 20 GB

Svar

Prøv bbcp . Testning i vores miljø afslørede, at cp havde en slags o f indbygget guvernør. Bare vær forsigtig, for når du tager guvernøren af, kan du redline din server og forårsage afbrydelse. I vores tilfælde tog vi serveren offline for at lave kopien, så hurtigere var bedre. Denne forbedrede overføringstid flere timer.

Svar

Sørg for, at målet filer findes ikke før kopiering.

Nogle gange er det overraskende, hvor meget tid der bruges, bare kopiering på den samme vært (intet netværk involveret).

Se mit svar på et andet cp-spørgsmål her . Lang historie kort, at overskrive en eksisterende fil er meget langsommere end at trunke den eller fjerne tilknytningen først, og derefter kopiering. Sidstnævnte er 8 gange hurtigere for en 1,2 GB fil.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *