Végzős hallgató vagyok, és a csoport, amelyben dolgozom, fenntart egy Linux fürtöt. A fürt minden csomópontjának megvan a maga helyi lemeze, de ezek a helyi lemezek viszonylag kicsiek, és nincsenek automatikus mentéssel ellátva. Tehát a csoporthoz tartozik egy fájlkiszolgáló, sok TB-vel a tárhely. Viszonylag kezdő Linux vagyok, ezért nem vagyok biztos abban, hogy mik a fájlszerver adatai a sebesség, a hálózati képesség stb. Szempontjából. Tapasztalatból tudom, hogy a helyi lemezek jelentősen gyorsabbak, mint a fájlszerverek az I / O szempontjából . Körülbelül egy tucat ember használja a fájlszervert.
A (z) cp használatával ~ 20 GB-os fájl másolása a fájlszerverről az egyik helyi lemezre átlagosan körülbelül 11,5 percet vesz igénybe valós időben (a time). Tudom, hogy ez az cp művelet nem túl hatékony, mert (1) time azt mondja nekem, hogy egy ilyen másolat rendszerideje csak ~ 45 másodperc; és mert (2) amikor a top elemet vizsgálom a másolás során, % CPU meglehetősen alacsony (ellenőrzéssel durván 0-10% átlagosan).
Az cp használatával ugyanazt a ~ 20 GB-os fájlt másolja a helyi lemez egyik mappájából egy másik mappára ugyanazon a helyi lemezen kevesebb időbe telik – kb. 9 perc valós időben (~ 51 másodperc a rendszeridőben, a time szerint). Úgy tűnik tehát, hogy a fájlszerver a vártnál kissé lassabb, mint a helyi lemez, de talán nem lényegesen lassabb. Meglep, hogy a helyi és a helyi másolás nem gyorsabb, mint 9 perc.
~ 200 nagy fájlt – egyenként ~ 20 GB – át kell másolnom a fájlszerverről az egyik helyi lemezre. Tehát a kérdésem a következő: Van-e gyorsabb alternatíva a cp -hez a nagy fájlok Linuxos másolásához? (Vagy vannak olyan zászlók a cp belül, amelyeket használhatnék, ami felgyorsítaná a másolást?) Még akkor is, ha valahogy el tudnám borotválni egy percet ettől a másolási időtől, ez óriási segítség.
Biztos vagyok abban, hogy új, gyorsabb hardverlemezeket vásárolok, de nem férek hozzá ilyen erőforrásokhoz. Nem vagyok rendszergazda – csak (kezdő) felhasználó vagyok – – így nem férek hozzá részletesebb információkhoz a lemezeken lévő terhelésről. Tudom, hogy bár naponta körülbelül egy tucat ember használja a fájlkiszolgálót, egyedül én használom ezt a csomópontot / helyi lemezt.
Megjegyzések
Válasz
% CPU legyen alacsony a másolás során. A CPU azt mondja a lemezvezérlőnek, hogy “ragadja meg az adatokat az X – Y szektorból a memória pufferbe Z-nél”. Aztán megy, és csinál valami mást (vagy alszik, ha nincs más). A hardver megszakítást indít, ha az adatok a memóriában vannak. Ezután a CPU-nak néhányszor le kell másolnia, és azt mondja a hálózati kártyának, hogy “csomagokat továbbít az A, B és C memóriahelyeken”. Ezután visszatér valamire.
~ 240mbps-t nyomsz.Gigabites LAN-on legalább 800 MB / s sebességre van szükség, de:
- Ezt mindenki megosztja a fájlkiszolgáló (és esetleg a kapcsolók közötti kapcsolat stb.) Felhasználóival
- Ezt korlátozza az a sebesség, amelyet a fájlszerver képes kezelni az írás során, szem előtt tartva, hogy a lemez I / O sávszélességét mindenki megosztja.
- Nem adta meg, hogyan hozzáfér a fájlszerverhez (NFS, CIFS (Samba), AFS stb.). Lehet, hogy be kell hangolnia a hálózati csatlakozást, de bármi, ami nemrégiben történt, az alapértelmezett értékek általában elég ésszerűek.
A szűk keresztmetszet felderítéséhez iostat -kx 10 hasznos parancs lesz. Ez megmutatja a helyi merevlemezek kihasználtságát. Ha ezt a fájlszerveren futtathatja, akkor elmondja, hogy a fájlszerver mennyire van elfoglalva.
Az általános megoldás a következő lesz: gyorsítsa fel ezt a szűk keresztmetszetet, amire természetesen nincs költségvetése. De van néhány speciális eset, ahol gyorsabb megközelítést találhat:
- Ha a fájlok tömöríthetők, és gyors CPU-ja van, a minimális tömörítés menet közben gyorsabb lehet. Valami például
lzopvagygzip --fastest. - Ha csak néhány bitet változtat itt-ott, majd visszaküldi a fájlt, akkor csak a delták küldése lesz sokkal gyorsabb. Sajnos
rsyncitt nem igazán segít, mivel a delta megtalálásához mindkét oldalon el kell olvasnia a fájlt. Ehelyett szükség van valamire, amely a fájl megváltoztatása során nyomon követi a delta értékét … A legtöbb megközelítés itt alkalmazásspecifikus. De lehetséges, hogy valamit fel tud szerelni, például: device-mapper (lásd a vadonatúj dm-korszak célpontját ) vagy a btrfs. - Ha ugyanazokat az adatokat másolja több gépre, akkor valami hasonlót használhat az udpcast segítségével, hogy egyszerre elküldje az összes gépnek.
És, mivel megjegyzi, hogy nem Ön a rendszergazda, azt hiszem, ez azt jelenti, hogy van rendszergazdája. Vagy legalábbis valaki felelős a fájlszerver & hálózatért. Valószínűleg megkérdezze tőle / Nekik sokkal jobban ismerniük kell a telepítés sajátosságait. A rendszergazdáknak legalább tudniuk kell megmondani, hogy milyen átviteli sebességre számíthat ésszerűen.
Megjegyzések
- +1 az iostat -kx 10-hez 🙂
Válasz
Ez valószínűleg gyorsabb alternatíva lehet, és két napig nem fogja eltömíteni a hálózatot: Vegyen egy vagy két nagyméretű USB-t (ha van, USB 3) vagy FireWire-lemezt, csatlakoztassa a szervert, és másolja a fájlokat a lemezre. Vigye a lemezt a helyi gépre. Másolja a fájlokat a gépre.
Megjegyzések
- Sneakernet ( hu.wikipedia.org/ wiki / Sneakernet ) nagyon gyors lehet: Soha ne becsülje alá az autópályán végighúzódó szalagokkal teli kombi sávszélességét.
Válasz
Ha közvetlen SSH (vagy SFTP) hozzáféréssel rendelkezik (kérdezze meg a rendszergazdáját), használhatja az scp fájlt tömörítéssel (-C):
scp -C you@server:/path/to/yourfile . Természetesen ez csak akkor hasznos, ha a fájl tömöríthető, és ez több CPU-időt fog igénybe venni, mivel titkosítást (mert SSH felett van) és tömörítést fog használni.
Megjegyzések
- Ebben az esetben hasznos lenne letiltani a titkosítás. Ne feledje, hogy megpróbáljuk gyorsabbá tenni a másolást .
- @lgeorget gyanítom, hogy a titkosítás rezsije ‘ nem lesz jelentős , figyelembe véve a merevlemezek lassúságát. Úgy gondoltam, hogy adok hozzá valamit a
-c nonetémához, de úgy tűnik, hogy nem szabványos . - ‘ ~ 20G fájlokkal foglalkozunk, így eléggé nem hatékony használni a titkosítást, ha nincs rá szükség.
- @lgeorget Titkosítás lehet sokkal gyorsabban végzett, mint az általa ‘ kapott teljesítmény, tehát nem nyert ‘ semmit sem. De feleslegesnek tűnik itt átmenni az SSH-n. Ha csak tömörítésre van szüksége, vannak más eszközök is?
- @Thomas Az SSH előnye, hogy ha ‘ állítólag hozzáférése van a távoli szerverhez, akkor ‘ szinte biztosan SSH-t futtat. Egy másik lehetőség a fájl helyi tömörítése, másolása a szerverre, majd
sshbeírása és kicsomagolása.
Válasz
A hatékony definíciója visszafelé mutat. A hatékonyabb megvalósítás kevesebb CPU-t pazarol. A helyi példányon átlagosan kb. 74 MB / s átviteli sebességet (olvasás + írás) jelent, ami nagyjából olyan jó, mint amennyi egyetlen merevlemezre jut.
Megjegyzések
- Hoppá.Amikor azt mondtam, hogy ” hatékony, ” gyorsan “. ”
Válasz
A cp a megvalósítás valószínűleg nem szűk keresztmetszet. Próbálja meg megfigyelni az IO használatát a iotop keresztül a kiszolgálón és a fürt csomóponton egyaránt. Ez ötletet ad Önnek, ahol javíthatja a teljesítményt.
Egy másik tipp az, hogy kerüljük az ugyanazon adatok másolását ugyanazon állomásról. Például, ha azonos 20G fájlja van a fájlkiszolgálóról a hálózaton keresztül az összes fürtcsomópontra, akkor sokkal gyorsabban fog működni, ha a fájlokat peer-to-peer módon másolja, nem pedig egy-szerverről-mind-kliensre. Kicsit bonyolultabb a megvalósítása, de még megpróbálhat használni néhány parancssori p2p-t is, például a direct connect hubot.
Ha ezen a 20G-fájlon belül egy rész gyakori, más része pedig fürtcsomópont-specifikus, fontolja meg felosztása közös és specifikus részekre, majd a közös rész elosztása p2p módon.
Megjegyzések
- Ha ‘ ha LAN-on van, képesnek kell lennie a multicast elvégzésére a peer-to-peer helyett. Ennek gyorsabbnak és kevesebb terhelésnek kell lennie a hálózaton.
Válasz
Ezeknek a fájloknak a jellege / tartalma változhat. Megértettem, hogy 200 fájlt (egyenként ~ 20 GB) kell másolnia egyik számítógépről a másikra , ez az?
Ha ezek a fájlok összenyomhatók vagy hasonló / azonos darabokkal vannak ellátva, akkor kétféle megközelítése van:
-
másolás előtt tömörítse őket, vagy hozzon létre egy alagút a zip funkcióval rendelkező számítógépek között. Tehát, ha a hálózat a szűk keresztmetszet, akkor kicsit r
-
ha a fájlok nagyon hasonlóak, vagy megosztanak köztük néhány közös tartalmat, próbálkozzon a rsync a használatával >. “El fog tölteni egy kis időt azzal, hogy megtalálja azt, ami a fájlok között elterjedt, és nem kell másolnia szó szerint , mert” a közös alapján rekonstruálja.
szerkesztés
Sokszor le kell másolnia ezeket a fájlokat ?? (például másolat -> ezeket a fájlokat használni -> valamit módosítani a fájlokban az A számítógépen -> másolja újra a fájlokat a B számítógépre)
Ha igen, akkor az rsync hasznos lesz, mert “megpróbálja felderíteni, hogy mi egyenlő a verziók között, és nem másolja a változatlant.
És egy harmadik módszer: ha a fentiek helyesek (változások a fájlban, majd az összes fájlt másolja újra a második számítógépre), megpróbálhat néhány binary diff -t változtassa meg a második számítógépen az első számítógépen megváltoztatottakat.
Válasz
Itt a következőket látom, a titkosítás nem jó ötlet, mivel ez NÖVELheti az átvihető adatok mennyiségét.
Ha két rendszer között másol, akkor a szűk keresztmetszet természetesen t a szerverek közötti kapcsolat.
Ha helyileg másol, akkor nézze meg, hogyan halad a folyamat, SINGLE menetes, így a szokásos Linux segédprogramok ezt használják:
- for all blocks in a file read a block write a block A műveletnek NINCS egyidejűsége.
A dolgok felgyorsítása érdekében használhat ilyesmit:
buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte További információ a puffer (1) man oldalán található.
A puffer parancs két folyamatot állít be a másolási folyamat egyidejű futtatására: az egyiket az olvasásra, a másikat az írásra, és megosztott memória puffert használ az adatok közlésére a két folyamat között. A megosztott memória puffer a klasszikus kör alakú puffer, amely megakadályozza az íratlan adatok felülírását és a már írt adatok írását. Ezt a programot használtam arra, hogy a lemezről szalagra történő átvitel során a másolási idő 10-20% -át levágjam.
Megjegyzések
- Valójában van egyidejűség a ” blokkban / blokk írása “, mert ” egy blokkot ír ” valójában csak a kernel ‘ s pufferébe teszi, és a kern kezeli a tényleges blokkírást a háttérben (legalábbis addig, amíg kezd fogyni a RAM). Vagy ha valamilyen okból használja az O_DSYNC / O_SYNC alkalmazást.
Válasz
Miért ne próbálná ki a P2P terjedési algoritmust , ha egyszerre frissítenie kell a teljes fürtöt?
https://github.com/lg/murder mit használ a twitter
Van “s BTSync , amelyet Ön is kipróbálhat.
Válasz
Ha ugyanazokat a fájlkészleteket gyakran másolja a helyi számítógépéről a szerverre, itt-ott kisebb változtatásokkal. Az rsync vagy a DVCS (pl. Hg vagy git) használatával felgyorsíthatja az átvitelt.
A git vagy a hg nyomon követheti és észlelheti a deltákat, és csak ezeket a deltákat továbbíthatja. Git használata esetén, mivel mindkét fél teljes múltú a tárházról, a delta kitalálása nagyon olcsó.
Az rsync a gördülő ellenőrző összegző algoritmus egyik formáját használja a delták észlelésére anélkül, hogy előzetesen tudná, mi a helyzet a másik oldalon. Bár az rsync-nek több munkára van szüksége a delták kiszámításához, nem kell az egészet tárolnia fájlelőzmények.
Válasz
Kipróbálhatja az összes fájlt egyetlen archívumba csomagolni (nem kell tömöríteni). Tapasztalatom szerint az egyik archívum másolása gyorsabb, mint nagyszámú egyedi fájl másolása
Megjegyzések
- Jó általános megfigyelés, de ahogy a kérdés mondja „~ 200 nagy fájl – egyenként ~ 20 GB”, nem hiszem, hogy ez tényleges válasznak tekinthető erre a problémára.
- @manatwork ah .. Nem olvastam ‘ nem egyértelműen. Azt hittem, hogy 200 fájlja van, összesen 20 GB
Válasz
Próbálja ki a bbcp elemeket. Környezetünkben végzett tesztekből kiderült, hogy a cp-nek valamilyen f beépített governer. Csak légy óvatos, mert amikor leveszed a gondnokot, újravonalazhatod a szerveredet, és kiesést okozhatsz. Esetünkben a szervert offline állapotba helyeztük a másolás elkészítéséhez, így jobb volt a gyorsabb. Ez több órával tovább javította az átviteli időt.
Válasz
Ellenőrizze, hogy a cél a fájlok nem léteznek másolás előtt.
Néha meglepő, hogy mennyi időt töltenek el még csak másolások is ugyanazon a gazdagépen (nincs hálózat).
Lásd itt található válaszomat egy újabb cp kérdésre . Hosszú történet, röviden: egy meglévő fájl felülírása sokkal lassabb, mint annak csonkítása vagy az első leválasztása, majd másolás. Ez utóbbi 1,2-szeres fájl esetén 8x gyorsabb.
ddésrsync, hogy összehasonlíthassa, melyik működik gyorsabban a környezetébendd-et, de most arsync-et próbáltam ki. A valós idő körülbelül 11,5 perc, a rendszeridő pedig körülbelül 1,5 perc volt atimeszerint./dev/sda1-ről/dev/sdb1-re gyorsabb lesz, mint az egyik helyről történő másolás a/dev/sda1a/dev/sda1másik helyre vagy a/dev/sdamásik partíciójára, mert a merevlemez ‘ t nyert további kereséseket kell végrehajtanunk az olvasások és az írások között (feltételezve a hagyományos merevlemezeket forgó lemezekkel és mozgó fejekkel; az SSD nyilvánvalóan más).