Dotaz: NFS - lak pri kopirovani velkych suborov

[Milan]

Zdravim,

mam debian server a na nom zvielam NFSv4 disk. Na druhom PC dam kopirovat z NFS velky subor (50 GB). Ked zacnem paralelne prechadzat v mc NFS disk tak je tam velky lag. Vyzera ze cela siet je pouzita na to kopirovanie. Da sa to nejak limitovat ?

Odpovědi

[debian]

nie cela siet, ale trafik ...

pouzi iny file-manager s moznostou nastavit limit rychlosti pri kopirovani.

[Milan]

ked tam bude viac uzivatelov ako sa to potom bude spravat ? Budu navzajom lagovat ?

[debian]

Ak pretazis pocitac, tak bude spomaleny. ...

Ak chces obmedzit NFS4, tak kukni https://serverfault.com/a/510225

Na nahravanie nepouzivaj NFS, ale pouzi (s)ftp. Ma mensiu systemovu narocnost.

Totiz, nie je prikaz ako prikaz. Preniest 50MB sa da 2 sposobmi: dd if=in_file of=out_file bs=1M count=50 dd if=in_file of=out_file bs=10M count=5

Ale druhy sposob menej zozerie systemovych prostriedkov (vykon). Pri druhom sposobe menej dochadza prepinani jadro/system. Lepsie sa pouzije cache. Lebo plati, cim vecsie bloku presuvas, tym je mensia rezia dat. Pokial NFS pracuje na rezime malych bloko 500k, tak nestihne nieco to tak rychlo spracovat (lebo aj system musi nechat cas na vykonanie ukonu napr. zapis realne na disk, ostatny musia cakat).

Pri nts je dotazovanie client-server vecsie. ....

Pri nfp vies nastavit rychlost na servere/client aby nevytazoval az tak system, ze by brzdil druhych.

[debian]

Totiz, nie je prikaz ako prikaz. Preniest 50MB sa da 2 sposobmi:

dd if=in_file of=out_file bs=1M count=50
dd if=in_file of=out_file bs=10M count=5

[Michal Kubeček]

Na nahravanie nepouzivaj NFS, ale pouzi (s)ftp. Ma mensiu systemovu narocnost.

SFTP? To myslíte vážně?

Pri druhom sposobe menej dochadza prepinani jadro/system.

Kdybyste používal třeba 4KB bloky tak neřeknu. Ale takhle musím přemýšlet, jak asi máte rychlou síť a disky, aby těch 45 context switchů hrálo nějak významnou roli.

[debian]

SFTP ak chce, aby nikto nevidel, co prenasa. (aj ked existuje nejaka alternativa - sifrovovane prenasa rychlo subory, len neviem ako sa vola).

Pri sftp je viac narocnejsia na vypoctovy vykon .... a ked servery vecsinou nerobia nic, mozno to problem nie je ...

[lertimir]

SFTP v domácí lokální gigabitové sítí? To fakt myslíte vážně?

[Michal Kubeček]

Což o to, já běžně používám scp na kopírování i mezi dvěma počítači propojenými přímo kabelem, obvykle proto, že je s tím nejméně práce (tedy pro mne). Ale určitě bych si netroufl to zdůvodňovat "menší systémovou náročností". :-)

[lertimir]

To já také, ale je to pak jednorázové kopírování, a NFS je zpřístupnění filesystému.

[Peter Golis]

Ohľadne scp, ešte existuje sshfs. Ale ten nerieši pôvodný požiadavku na nastavenie priority toku.

[Peter Golis]

To, že ti prenos NFS dokáže využiť pásmo celej sieťovky je fajn. To, že si si nenastavil QoS pre NFS už nemusí byť fajn. Cez QoS si to môžeš kľudne limitovať.

Teda za predpokladu že nemáš domácu sieť založenú na WiFi 2.4GHz spolu s BT audiotechnikou. Vtedy je problém niekde inde.

PS: To QoS sa dá aj naklikať na domácom routeri.

[Milan]

ja mam PC1 <- gigabit -> PC2

problem mam ze ak dam sucasne kopirovat jeden 50 gb subor a potom vela malych suborov tak ta rychlost sa nerozlozi rovnomerne.... Toto by som chcel na strane servera. Ak kopirujem cez vsftpd tak ziaden problem...

[lertimir]

No nenapsal jsi jaké parametry máš okolo. Mohlo by to bý i něco zcela jiného. zkus si na obou stranách nainstalovat atom a zjistit, co se děje. To co mě napadá při pohledu křištálové koule je:

1. Utopíš disk na serveru. Vzhledem k tomu, že sít má cca 100MB/s a disk má tak 130MB/s při seriovém čtení zápisu a mnohem méně při random, tak když dáš "vela malých souborov" bude to "vela random" a pomalé.
2. Máš příkazy v bufferech. Nejsem odborník na interní strukturu NFS, ale očekávám následující: NFS je FS na souborovém levelu. Po sítí běhají příkazy které něco po serveru chtějí. V okamžiku kdy zadáš požadavek na výpis adresáře tak se zařadí do fronty, která je plná požadavků na přenos. Jestli NFS nemá nějakou specifickou prioritizaci požadavku na adresář, který by ve frontě předbíhal, musíš počkat až se vyřídí všechny požadavky ve frontě.
3. Velikost dirty_pages. viz NFS operací se to týká také.

[lertimir]

překlep. máš nainstalovat atop

[Milan]

1. ten disk je SSD t.j. 500MB/s
2. to mam aj pri ftp a tam tento problem nemam. ak kopirujem v 2 threadoch rychlost sa medzi ne rozdeli. Cakal som ze nieco taketo dokaze aj NFS - je to nativny network filesystem. Mam taky pocit ze asi aj samba/cifs je na tom lepsie ako NFS
3. na to sa pozriem vdaka. Kazdopadne FTP to pouziva asi tiez a ziaden problem

[MP]

Aby 50GB a XX souboru melo 1:1 sirku pasma je nesmysl uz by default (rezie metadat). Neni ten vsftpd nahodou single thread?

[Kit]

Nejsem si jist, zda je použití NFS pro takové účely vhodné. Hodně záleží na povaze toho 50GB souboru. Pro video bych použil jiný typ sdílení než pro databázi, ale NFS se nehodí ani pro jedno z toho.

Přimluvil bych se za FTP, ale skutečně záleží na tom, co se přenáší.

[Max]

...ale NFS se nehodí ani pro jedno z toho.

Nesouhlasím, produkční db (Oracle 12.2) jedeme přes NFS4.1 (2x10Gbit) pro cca 1k klientských procesů. IOPS nám na poli u DB leze na 5000
Pole je z ssd disků a celé je to rychlejší, jak předchozí pole s 24x15K SAS přes FC 8Gbit.
Zdar Max

[Kit]

Oracle to má vyřešeno, ale nedovedu si představit, že by jiné dva databázové stroje sdílely úložiště přes NFS.

[Max]

Pokud jsi narážel na sdílení db souborů, tak to ok, já myslel, že narážíš na používání db s datovými soubory uloženými na NFS. V tom totiž problém také nevidím.
Zdar Max

[Odpadlik]

Pouzij mensi bloky. Defaultne ma totiz NFS tendenci jit po velkych jumbo paketech coz pak zpomaluje odezvu jinde.