Fórum Root.cz
Hlavní témata => Software => Téma založeno: creco 17. 10. 2012, 13:01:34
-
V serveru mam velke diskove pole na ktere neustale nekdo pristupuje ale diskove pole uz nestiha a tak se jeho sviznost dosti zpomalila. K severu jsem připojil nove disky a vytvoril druhe pole s myslenkou ze rozdelim zatez mezi obe dve pole.
Jenomze kdyz dam kopirovat data z disku na disk tak to server pretizi natolik ze klienti maji strasne dlouhe odezvy a neda se stim pracovat protoze disky jedou na 100%
Hledam prikaz/nastroj... kterym bych mohl dat kopirovat data z disku na disk pod ubuntu v konzoli a omezit rychlost kopirovani treba na 5MB/s tak aby to nepretezovalo disky na kterych pracuji soucasne i uzivatele.
Nepodarilo se mi nic vygooglit
-
Rychlost kopírování z disku na disk lze prý v linuxu značně zvýšit, pokud se ext3 žurnály plácnou na SSD.
http://insights.oetiker.ch/linux/external-journal-on-ssd/
jinak rsync má parametr --bwlimit=KBPS
nestačilo by to?
-
no zkusit to muzu. ale myslel jsem si jestli neexistuje nejaky parametr k prikazu "cp" nebo v "mc" nelze zapnout limit kopirovani....
-
Rychlost kopírování z disku na disk lze prý v linuxu značně zvýšit, pokud se ext3 žurnály plácnou na SSD.
A jak dlouho pak takové SSD vydrží? Připadá mi to ve vztahu k SSD podobně likvidační jako swap, nebo spíš ještě více...
-
a co treba ionice? ten nelimituje bandwidth, ale prioritu
ionice -c3 cp /vodkud/* /kam
-
A jak dlouho pak takové SSD vydrží? Připadá mi to ve vztahu k SSD podobně likvidační jako swap, nebo spíš ještě více...
Pokud to ssd bude sloužit jenom pro ten žurnál (bude plné max. z 10%), potom se wear leveling neprojeví tak výrazně a mělo by to vydržet poměrně dlouho. Nevidím nic špatného na tom použít to k urychlení, záleží samozřejmě na prioritách a ceně kterou jste za to choten zaplatit...
-
buffer -u 150 -m 16m -s 100m -p 75 -i src -o dst
zvyš -u pro menší zátěž...
-
jo btw pro vysvětlenou: http://manpages.ubuntu.com/manpages/natty/man1/buffer.1.html
-u microseconds
After every write pause for this many microseconds. Defaults to
zero. (Surprisingly a small sleep, 100 usecs, after each write
can greatly enhance throughput on some drives.)
-
A nebo jak by jste postavili diskove pole pro 100 uzivatelu ktery tam maji data, profily atd... tak aby de disky nezblaznily?
Vykonny radic, raid 10, nebo disky s 15000 ot/s????
-
Vykonny radic, raid 10, nebo disky s 15000 ot/s????
Všechno z toho :-) . Jinak pro omezení rychlosti kopírování je ten --bwlimit u rsyncu.
-
Vykonny radic, raid 10, nebo disky s 15000 ot/s????
Všechno z toho :-) . Jinak pro omezení rychlosti kopírování je ten --bwlimit u rsyncu.
raid10 je nejrychlejsi ... oponoval bych
delal jsem testy s polem osazenym 36 disky a ruznou konfiguraci, raid10 nebyl spatny, ale ztrata kapacity byla velka. Nekolik Raid6 s hot spare a dobre nakonfigurovane LVM se stripingem (raid60 by se dalo rict ) je stejne rychle s podobnou bezpecnosti a lepsi kapacitou. Dokonce i u 4HDD kdyz udelate 2x Raid1 a stripnete LVM, je to rychlejsi nez defaultni mdraid10.
15k rpm a SSD ... vyborny vykonovy skok pro nahodne pristupy. nikoliv pro sekvencni, kde se dostanete na limit moznosti prenosu (pres sit apod.) i s 7k2 rpm
vykonny radic ... mate tip na vyzkouseni vykonneho radice? rad se poucim a pomerim treba s levnejsim SAS2008. hw a sw raid neni velky rozdil. pokud chcete skutecny vykon, tak kupujete cele reseni datoveho uloziste a na to nemate penize, presto rychlost neni az tak rozdilna proti sestaveni vlastniho pole a dobre konfigurace, protoze opet muzete prenaset jen do rychlosti mozneho pristupu.
-
A jak dlouho pak takové SSD vydrží? Připadá mi to ve vztahu k SSD podobně likvidační jako swap, nebo spíš ještě více...
Pokud to ssd bude sloužit jenom pro ten žurnál (bude plné max. z 10%), potom se wear leveling neprojeví tak výrazně a mělo by to vydržet poměrně dlouho. Nevidím nic špatného na tom použít to k urychlení, záleží samozřejmě na prioritách a ceně kterou jste za to choten zaplatit...
Aha, takže když budu mít třeba 1 GB žurnál (což už mi připadá jako doopravdy velký žurnál) tak na jinak prázdném SSD disku řekněme 250 GB budu likvidovat jeden gigabajt po druhém, disk bude neustále přemapovávat, a jdu do toho s tím že jednou (ale až za hodně dlouho) to ten disk zlikviduje. To zní akceptovatelně.
-
Wear leveling se snaží právě odcházení buňěk předcházet, takže ten žurnál bude rozprostřený po celém disku a měl by (teoreticky) opotřebovávat rovnoměrně celý disk. A řekl bych (ale to je jen můj názor, prosím o vyvrácení :) ), že 1GB žurnál na 250GB SSD nebude mít o moc horší vliv, než když na tom samém SSD budete mít 180 GB dat i se systémem.
-
Omezení rychlosti příliš nepomůže a naopak bude zdržovat daleko delší dobu. Pro tento účel se používá ionice, kde io scheduler v jádře řídí zápisy a čtení ze zařízení. Pokud jsou pod tím přímo disky a ne nejaké pole s vlastní chytrystikou, tak to funguje ok.
Co se týče pole pro 100 lidí, tak tam bych očekával spíše více malých požadavků než sekvenčních. Takže něco co má vysoké IOPS. SSD, rychlé 15k SASy apod. RAID10 pomůže hlavně pro sekvenční čtení. Ale na rozdím od paritních raidů má velmi dobrý náhodný zápis. A jako vždy, dostatek paměti hodně pomůže (na našem poli pro cca 60VM se odehrávají především zápisy, čtení je obhospodařeno z paměti (jak pole, tak i těch VM)).
-
podepření klackem:
1) disky nasdílet přes síť, třeba pomocí nfs (klidně přes 2. loopback)
2) limitovat propustnost síťového spojení pomocí iptables
-
Aha, takže když budu mít třeba 1 GB žurnál (což už mi připadá jako doopravdy velký žurnál) tak na jinak prázdném SSD disku řekněme 250 GB budu likvidovat jeden gigabajt po druhém, disk bude neustále přemapovávat, a jdu do toho s tím že jednou (ale až za hodně dlouho) to ten disk zlikviduje. To zní akceptovatelně.
Pokud clovek potrebuje SSD opravdu jen pro zurnal, pak bych doporucil Intel 311/313 20/24GB. Jde o SSD typu "SLC", a to ma radove vetsi schopnost zapisu/prepisu nez MLC. Opravdu bych se nebal, ze jej neco jako zurnal zlikviduje. Pro paranoidni je tady jeste moznost dat 2xSSD/SLC do raid1. Pri cene kolem 100€/kus je to akceptovatelne...
-
Přidat RAM, provozovat žurnál na tmpfs a v případě výpadku napájení ošetřit zápis na HD, než to UPD vypne.
-
podepření klackem:
1) disky nasdílet přes síť, třeba pomocí nfs (klidně přes 2. loopback)
2) limitovat propustnost síťového spojení pomocí iptables
Bud prosim konretní a hod sem nejaky odkazy na konretni hardware abych se mohl inspirovat
http://www.atcomp.cz/zbozi_detail.aspx?zbozi=252250
4ks http://www.atcomp.cz/zbozi_detail.aspx?zbozi=159310
http://www.atcomp.cz/zbozi_detail.aspx?zbozi=141835
a RAID 10???
-
Tole je zrovna low end řešení, které Vám zrovna moc nepomůže, navíc jak se dívám na ceny, je to oproti jiným e-shopům celkem drahé, rozhodně tedy server s hotplug klecí, lepší řadič s cache a baterií např http://www.senetic.cz/product/631674-B21, popřípadě lze zátěž řešit doplnění dalšího pole a nejvíce zatížené svazky rozložit na další HW a přes noc ne křížem zálohovat, příčina může být také v nevhodně zvolenému FS vůči struktuře souborů na poli.
Zvolil bych i server s více kójemi pro další budoucí rozšíření kapacity, zauvažovat třeba nad použitím ZFS. Další a dražší možností je zakoupení již hotového a odzkoušeného řešení od renomovaných společností. Myslím, že více jak 100 uživatelů online je už důvodem k zamyšléní o investici do profesionálního řešení.
-
lepší řadič s cache a baterii
...
zauvažovat třeba nad použitím ZFS.
drobne protireceni - ZFS je udelane tak ze nepotrebuje disk s battery cache ani hardware RAID (ten spis nesnasi), ZFS je delane tak ze mam uplne tupe HBA a vsechno resi chytry software. jedine co se mu hodi je aby disk spravne reagoval na flush cache (coz ale chce kazde rozumne pouziti), a multipathing nebo dostatecnou redundanci, aby umreni jednoho z radicu nevyradilo server z behu
druha vec je ze ZFS neni uplne to spravne reseni performance-wise, diky COW ma super featury, ale ta rychlost nebyva az tak skvela (coz neni potreba, typicke pouziti je treba nahrada SAN s mnoho disky, kde rychlost site je podstatne nizsi nez cista rychlost modernich disku)