Pripojenie domácich priečinkov cez sieť - pomalé spojenie

[ppolonec]

Ahojte,
som učiteľ ZŠ, z počítačovej učebne som spravil linuxovú miestnosť, žiakom som vytvoril LDAP účty a skúšam im nastaviť domáce priečinky na serveri, aby sa vedeli k svojim veciam dostať z ktoréhokoľvek počítača.
Nastavil som pripojenie priečinkov pomocou autofs, všetko funguje, avšak pri pripojení viacerých používateľov sa sieť značne spomalí.
Skúsil som hodiť triedu do vlastnej podsiete, nech zbytočne nezaťažujem celú školskú sieť.
Snažil som sa zistiť, čo ma brzdí - cez iftop a iotop som pozrel spojenia servera a jeho disk, pozrel som router, tie podľa všetkého stíhajú.
Máte prosím nejaké nápady ako to zrýchliť, resp. zistiť čo nás brzdí?
Ďakujem.

[Reklama]

[datlikMS]

Ahoj,
toto som nikdy neskusal, tak skusim napisat len, co by som skusil ja.
Chce to asi lepsi popis ... aky je hw (siet, server, ...), ako presne sa prejavuje problem (ked sa len prihlasia ziaci, tak to ide do stratena? alebo ked zacnu vsetci kopirovat? da sa to nasimulovat na virtualoch?)

Kedze sa jedna o komunikaciu v ramci jedneho subnetu, tak switch vie spravne urcit adresata, oddelenie sieti je vhodne z hladiska bezpecnosti.
Ak je server a pocitace v ramci jedneho subnetu, tak sa nic neroutuje ...

nie je zahlteny cpu na strane servera? .. top
tcpdump - analyzu trafficu (pripadne wireshark) - sledovat, co sa deje na sieti
zabbix/nagios mi pride ako overkill, ale da sa pri tom vela naucit

Osobne by som nerobil autofs, ale mount nfs/smb share po prihlaseni, nech sa aj nieco naucia...
m

[ppolonec]

Skúšal som top, procesor je OK, zvýšil som aj počet vlákien pre NFS.

[alex6bbc]

co zkusit ftp, scp a posilat vice dat at se vidi zda to je softem nebo hw/siti.

[Ignotus]

Skúšal som top, procesor je OK, zvýšil som aj počet vlákien pre NFS.

Čo to znamená - procesor je OK? Jeho celkové vyťaženie je nízke? To nemusí byť relevantné - ak má proces pridelený konkrétny počet vlákien, tieto môžu byť vyťažené na 100%.

[Reklama]

[prevadecspojitostivole]

NFS mas nastavene jako sync nebo async, velikost wsize/rsize mas jakou?

[Jose D]

a čím máš podložený ten nfs export, je to rotační disk, ssd, nějaký raid ?

může být, že nestíhá iops..., spousty malejch souborů, u mě má třeba jen mozilla v cache ~N0 000 files..

Jestli máš na všechny stanice ssh přístup, tak si zkus sjet nějaký IO benchmark, nejdřív z jedné, pak z dvou, čtyř...

Nu a při tom se koukej na router, na porty, na io na serveru..

doufám bavíme se o nějaké metalické síti a ne bezdrát?

[František Ryšánek]

Pokud správně rozumím, iotop ukazuje IO per proces.
Zajímavý údaj by byl, IO zátěž per block device = kolik toho hrne jednotlivý disk.
Doporučuji nainstalovat balík "sysstat" a poté použít
iostat 2
Bude Vám v intervalu 2s zobrazovat okamžité MBps a IOps na jednotlivé disky, zvlášť čtení a zvlášť zápis.
Jednotlivý točivý disk má strop asi 75 IOps, pokud jsou seeky skutečně náhodně rozmístěny po plotně. (Pokud nejsou seeky od sebe moc daleko, tak víc.)

Na jakém filesystému jsou ty home adresáře na serveru umístěny? (Ext4, XFS, btrfs apod.) Konkrétně btrfs v defaultním nastavení se zapnutým COW nemusí být to pravé oříškové pro všelijakou zátěž, která neustále mění stávající soubory (dnešní WWW browsery si udržují historii a další věci v DB souboru...) Máte ve fstabu pro ten svazek opšnu "noatime" ? Pokud jako emailového klienta nepoužíváte mutt, tak to ničemu nevadí a ušetří Vám to spoustu IOps.

Na serveru bych zkusil razantně zvednout dirty_ratio (90), dirty_background_ratio (80), dirty_expire_centisecs (třeba 6000). Tzn. zvětšit softwarovou write-back cache před diskem a prodloužit její trpělivost. Kolik máte v serveru RAMky a jak je využitá? Hodil by se výpis /proc/meminfo. Pokud fileserver nemá nic moc jiného na práci než servírovat disky, tak je nesmysl, aby měl spoustu volné ramky (free/available). Pokud je síťový disk subjektivně pomalý, měl byste se snažit, aby server měl co nejvíc v kolonkách "buffers", "cached" a "dirty". Zajímavý je údaj, kolik je v kolonce "writeback". Pokud je to hodně, znamená to, že disk hrubě nestíhá zápis.

NFS jede dneska by default nad TCP - doufám jste ho nepřepnul na UDP.

Co za ethernet je od serveru až na switch v učebně? Je tam aspoň gigabit? Ten řádově odpovídá sekvenční průchodnosti jednoho točivého disku.

Startuje na klientech okamžitě nějaký soft po přimountování síťového NFS svazku (home adresáře)? Třeba nějaký indexer pro rychlé vyhledávání (patrně spíš omylem)... Už tu padla zmínka o keši webových browserů - ta je taky v home adresáři... Projeví se problém ve chvíli, kdy děcka na klientech začnou browzdat? Tzn zkusit ten iotop na klientech.

Na kernel command line (do grubu) bych přidal intel_idle.max_cstate=1 (pokud CPU je intel) a pokud se nebojíte, tak ještě mitigations=off. Ale od toho už si velký výsledek neslibujte. Latence ospalých C-stavů by pod zátěží měly naopak ztratit vliv.

Co jsou zač switche v té síti? Mají management? Pokud ano, dokážete zjistit, zda mají zapnutý 802.3x flow control? Pokud je tahle věc zapnutá, zkuste ji vypnout. Totéž taky na serveru. Není to tutovka, ale mohlo by to pomoct. Jedná se o poměrně primitivní mechanismus, který ne vždy funguje správně a ku prospěchu věci. V lepším případě nevadí...

[ppolonec]

Čo to znamená - procesor je OK? Jeho celkové vyťaženie je nízke? To nemusí byť relevantné - ak má proces pridelený konkrétny počet vlákien, tieto môžu byť vyťažené na 100%.

Kontroloval som vyťaženie vlákien, ani tie neboli vyťažené na 100%

NFS mas nastavene jako sync nebo async, velikost wsize/rsize mas jakou?

NFS je nastavené na async, skúšal som rôzne hodnoty rsize a wsize, nakoniec som to nechal ako default, vypisuje mi že je to 1048576. Je lepšie dať menšiu alebo väčšiu veľkosť?

a čím máš podložený ten nfs export, je to rotační disk, ssd, nějaký raid ?

může být, že nestíhá iops..., spousty malejch souborů, u mě má třeba jen mozilla v cache ~N0 000 files..

Jestli máš na všechny stanice ssh přístup, tak si zkus sjet nějaký IO benchmark, nejdřív z jedné, pak z dvou, čtyř...

Nu a při tom se koukej na router, na porty, na io na serveru..

doufám bavíme se o nějaké metalické síti a ne bezdrát?

Ide to na rotačný disk, skúsil som aj SSD, bez zmeny rýchlosti. Sieť je kábel.

Na jakém filesystému jsou ty home adresáře na serveru umístěny? (Ext4, XFS, btrfs apod.) Konkrétně btrfs v defaultním nastavení se zapnutým COW nemusí být to pravé oříškové pro všelijakou zátěž, která neustále mění stávající soubory (dnešní WWW browsery si udržují historii a další věci v DB souboru...) Máte ve fstabu pro ten svazek opšnu "noatime" ? Pokud jako emailového klienta nepoužíváte mutt, tak to ničemu nevadí a ušetří Vám to spoustu IOps.

Je to Ext4, noatime nastavený nemám, vytvorím nový oddiel len pre tieto priečinky a skúsim tam dať noatime. Nechal som decká nech si cache prestavia na lokálny disk, to serveru viditeľne uľavilo. Ale stále bol problém pri pripojení viacerých počítačov.

Na serveru bych zkusil razantně zvednout dirty_ratio (90), dirty_background_ratio (80), dirty_expire_centisecs (třeba 6000). Tzn. zvětšit softwarovou write-back cache před diskem a prodloužit její trpělivost. Kolik máte v serveru RAMky a jak je využitá? Hodil by se výpis /proc/meminfo. Pokud fileserver nemá nic moc jiného na práci než servírovat disky, tak je nesmysl, aby měl spoustu volné ramky (free/available). Pokud je síťový disk subjektivně pomalý, měl byste se snažit, aby server měl co nejvíc v kolonkách "buffers", "cached" a "dirty". Zajímavý je údaj, kolik je v kolonce "writeback". Pokud je to hodně, znamená to, že disk hrubě nestíhá zápis.

Skúsim to pozrieť.

NFS jede dneska by default nad TCP - doufám jste ho nepřepnul na UDP.

Neprepínal som ho na UDP, teda by mal bežať na TCP.

PS: viacerí ste sa pýtali na swithc, ten je 1Gb. Jednotlivé káble asi neviem, ale skontrolujem kábel Switch-Server, ten tiež môže byť na vine.

Zatiaľ srdečne ďakujem za všetky rady a nápady, pustím sa do testovania. Ak by vám ešte niečo napadlo, veľmi rád si to prečítam. Prajem zatiaľ všetkým pekný deň.

[jjrsk]

NFS je neskutecne pomale samo o sobe, takze bych se vubec nedivil, pokud by to bylo proste tim. Sveho casu sem si testoval ruzne varianty sitovych disku, a jako jediny realne pouzitelny se mi jevil smb.

Pocitam ze se v tomhle pripade bavime o jedne tride = +-30 uzivatelu? Co tak +- delaji? Nejnarocnejsi appka kterou bezne useri pouzivaji byva browser a ten dokaze zatopit libovolnemu HW.

Mozna by bylo vhodnejsi jim do lokalniho home jen pripojit nejaky sitovy adresar. Horsi bude pak je primet ho vyuzivat.

Jinak pro test si to pripoj sam, az tam nikdo nebude a zkus kopirovat nejaky vetsi soubor, tim dostanes limit propustnosti a nebudou to limitovat IOps. I z jednoho disku by to na gigovy siti melo davat rekneme 80MB/s+ (na obe strany samozrejme). Pokud to da vyrazne min, je neco vyrazne spatne. Pokud je propustnost OK, tak dalsi v rade budou ty IOps. Ty bys vyrazne zvednul tim zminenym SSD, ale viz vejs, myslim si, ze te limituje zvoleny protokol.

Pouzivam smb u zakazniku, a limituje to jen a pouze rychlost site.

[ppolonec]

V podstate stačí, ak sa ja pripojím na multitermináli pripojím na jeden účet (cez su) a začína to štrajkovať, tie, ktoré sa vyhodnotia ako prvé idú celkom fajn, tie, ktoré sa vyhodnotia ako posledné idú pomaličky. Už som sa aj zmieril s tým, že to nepôjde tak ako som si predstavoval, ale uvidím, možno niektorá z vašich rád zafunguje
Čo je zvláštne, momentálne má každý PC pripojené 4 priečinky cez NFS a nejaké problémy s tým nie sú. Možno ešte vyskúšam statický mount cez fstab - mountnem celý /home a uvidím čo to povie. Alebo sa pozriem na tú Sambu.

[czechsys]

Jestli nevidite efekt rozdilu mezi ssd a hdd na serveru pro export nfs, tak ten problem bude bud nastaveni nfs nebo samotna sit/stanice. Proc sem nehodite konfiguraci nfs, proc sem nehodite, jake pouzivate klienty, verzi nfs atd?

[František Ryšánek]

• iostat 2 ukáže vytížení disků (MBps i IOps)
• iotop ukáže konkrétní proces, který generuje hodně IO per second
• top ukáže procesy, které žerou CPU
• pak třeba existuje ještě latencytop = kde jaký proces tráví hodně času čekáním (v zablokovaném syscallu, třeba na
• přístup k disku apod).

Bohužel na dálku Vám mnoho neporadíme.

Pokud říkáte, že přihlášení někde na konzolu a "su" způsobuje vytížení systému, tak je to dobrá haluz! V památných dobách prvních soukromých serverů na Silicon Hillu zvládla 486 se 16 MB RAM nízké trojciferné počty uživatelů, kteří pracovali pravda tehdy ještě spíš v telnetu než v ssh. Chci říct, že ta korelace s "su" spíš vypdá, že si něco špatně vykládáte.

Pokud nepoužíváte mutt (starobylý mailový klient), tak se myslím nemusíte stydět, přidat opšnu -o noatime do fstabu klidně pro kořenový svazek. By default souborový systém *zapisuje* do metadat čas posledního čtení ze souboru, i když se ze souboru pouze čte. Tahle fičura je schopná srazit reálnou průchodnost na půlku nebo třetinu = zdvojnásobí nebo ztrojnásobí počet IOps generovaný čtecí aktivitou. Kromě toho zkracuje životnost flaškám (SSD).

Stejně tak zvednutí dirty_ratio a dirty_background_ratio může pomoci dost citelně. Je to hodně znát třeba při instalaci (balíčkovacím systémem apt apod.) nebo při kompilaci kernelu, na stroji s moderním výkonným procesorem a relativně pomalým točivým diskem. Máte otevřená dvě terminálová okna, v jednom třeba kompilujete kernel. Vidíte, jak rychle roluje výpis. V druhém okně provedete
echo "90" > /proc/sys/vm/dirty_ratio
echo "80" > /proc/sys/vm/dirty_background_ratio
a okamžitě si všimnete, že disk poněkud ztichnul (přestal tak zuřivě seekovat) a rolování výpisu kompilace se nápadně zrychlilo.

...zmínil jste se už, co to máte za linux? Ony se historicky vyvíjejí také diskové IO schedulery. Osobně ale nechci tvrdit, že zrovna výměna scheduleru bude mít ve Vašem případě nějaký význam. Schválně mrkněte do /sys/block/sda/queue/scheduler . Defaultní IO scheduler v moderních distrech (jednu dobu frčelo cfq, později bfq, dnes ani nevím) se obvykle snaží o co nejlepší "svižnost desktopu" = krátké latence. Ovšem navrub úhrnné sekvenční průchodnosti. Pro serverové nasazení by mohlo mít smysl, použít scheduler "deadline" nebo i "none" (noop). Aspoň to zkusit. Výsledek / vhodná varianta scheduleru záleží na konkrétním mixu zátěže.

Zda to všechno pomůže konkrétně ve Vašem případě, to je těžko říct.
Nemohu vyloučit, že se na tom lví měrou podílí zejména NFS - dost se na něj nadává :-)
Osobně používám NFS jenom pro read-only root při diskless bootu. Svazky pro užitečná data mám na Sambě, a provozuji na tom převážně sekvenční zátěž. Zato klidně desítky klientů simultánně. Jeden konkrétní můj server má nějaké staré úsporné Core2 duo. Úzkým hrdlem bývá spíš gigová síť než disky v serveru.

Jo a taky zkuste nainstalovat smartmontools a zeptat se disku pomocí "smartctl -a /dev/sda", jak se mu daří.

[prevadecspojitostivole]

Jaky mas switch, neni to mikrotik, nebo podobna haluz? Ma to management?

Server je virtualizovany? Jake nastaveni, kolik RAM a jaky CPU? V Proxmoxu muzes mit aktivovane zaplaty na spectre a spol. nebo spatny driver na disk a tim to hoooooooodne zabrzdit.

Nemas tam nejaky vypeceny raid?

[Jose D]

@jjrsk:

NFS je neskutecne pomale samo o sobe, takze bych se vubec nedivil, pokud by to bylo proste tim. Sveho casu sem si testoval ruzne varianty sitovych disku, a jako jediny realne pouzitelny se mi jevil smb.

hele a co z toho SMB (čísla) dostaneš?
Jako obecně NFS má své mouchy, ale SMB jsem vnímal jako nenativní protokol, do které ho se jde až v momentě, kdy máš v síti win klienty..

..ať se nebavíme obecně.. recentní hw, 10G síť, na remote obyč (server) nvme/ssd, nfs (4.2) víceméně v default na Rocky8:

Kód: [Vybrat]

[root@n2 test_mount]# fio --filename=./testhere --direct=1 --rw=read --bs=1m --size=20G --numjobs=200 --runtime=60 --group_reporting --name=file1
file1: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
...
fio-3.19
Starting 200 processes
file1: Laying out IO file (1 file / 20480MiB)
Jobs: 200 (f=200): [R(200)][100.0%][r=1119MiB/s][r=1118 IOPS][eta 00m:00s]
file1: (groupid=0, jobs=200): err= 0: pid=5133: Fri Jun  2 11:58:50 2023
  read: IOPS=1118, BW=1118MiB/s (1173MB/s)(65.7GiB/60179msec)
    clat (msec): min=3, max=186, avg=178.46, stdev= 6.80
     lat (msec): min=3, max=186, avg=178.46, stdev= 6.80
    clat percentiles (msec):
     |  1.00th=[  176],  5.00th=[  178], 10.00th=[  178], 20.00th=[  178],
     | 30.00th=[  178], 40.00th=[  180], 50.00th=[  180], 60.00th=[  180],
     | 70.00th=[  180], 80.00th=[  180], 90.00th=[  182], 95.00th=[  182],
     | 99.00th=[  184], 99.50th=[  184], 99.90th=[  184], 99.95th=[  186],
     | 99.99th=[  186]
   bw (  MiB/s): min=  781, max= 1282, per=100.00%, avg=1119.66, stdev= 0.81, samples=23824
   iops        : min=  719, max= 1271, avg=1117.37, stdev= 0.82, samples=23824
  lat (msec)   : 4=0.01%, 10=0.02%, 20=0.03%, 50=0.07%, 100=0.11%
  lat (msec)   : 250=99.77%
  cpu          : usr=0.00%, sys=0.05%, ctx=68330, majf=2, minf=55740
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=67292,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=1118MiB/s (1173MB/s), 1118MiB/s-1118MiB/s (1173MB/s-1173MB/s), io=65.7GiB (70.6GB), run=60179-60179msec
[root@n2 test_mount]#