Dotaz: Linux server SMB, 1 gigabit, ale strašně pomalé - 50 MB/s

[palardd]

Příloha:

• Annotation 2020-09-01 104255.jpg (242096 bytů)

Zdar, obracím se na odborníky mám Linux server na Ubuntu 18, kde je RAID1 pole (pole jsou dvě) na tom Samba a sdílení pro W 10 počítače síť je gigiabit Cat 5 kabel Chci z toho vymačkat co nejvíce!!! Ale více než 300-400 mb/s to nejede. Čekal bych 100 MB/s aspoň. Přestože disky jsou OK

/dev/sda: Timing buffered disk reads: 398 MB in 3.01 seconds = 132.28 MB/sec /dev/sdb: Timing buffered disk reads: 526 MB in 3.01 seconds = 175.02 MB/sec /dev/sdc: Timing buffered disk reads: 366 MB in 3.01 seconds = 121.64 MB/sec /dev/sdd: Timing buffered disk reads: 528 MB in 3.00 seconds = 175.97 MB/sec /dev/sde: Timing buffered disk reads: 314 MB in 3.01 seconds = 104.25 MB/sec /dev/sdf: Timing buffered disk reads: 356 MB in 3.00 seconds = 118.58 MB/sec

Myslel jsem, že RAID 10 přidá výkon, čte se z obou najednou. A ten Ethernet by měl také dávat alespoň 80 % výkonu, tedy něco kolem 800 mb/s, ale jsem jakžtakž na polovině... Jedu přitom fullduplex... Kde je zakopaný pes? Máte někdo prosím prosím představu, kde to vylepšit, kam sáhnout?

---

---

Odpovědi

[Aleš Kapica]

Sorry, ale jaksi zapomínáš že vše má svou režii, takže těžko dosáhneš stejných rychlostí, jako při použití testu. Podle všeho to vypadá na rotační disky, možná SSHD.

[Heron]

Sorry, ale přijde ti normální rychlost 30MB/s? V roce 2020?

Saturovat sambou gigabit nebyl problém nikdy. Ano, dříve k tomu byla potřebná normální síťovka (tj vypnout integrovanej realtek a dát tam třeba Intel), ale hezkých pár let neřeším už ani to a defaultní instalace čehokoliv (Linux, FreeBSD, Widle) bezproblémů zahltí gigabit.

Tj pokud síť sama o sobě nedá cca 115MB/s, tak je něco špatně.

Pochopitelně tazatel může mít jiný problém. To jeho pole by mělo umět číst min 400MB/s, pokud neumí, je třeba hledat chybu tam.

[Michal Kubeček]

Ano, dříve k tomu byla potřebná normální síťovka (tj vypnout integrovanej realtek a dát tam třeba Intel)

A teď kacířská otázka: proč vlastně? Samozřejmě vím, že se to doporučuje, ale spíš by mne zajímal nějaký technický důvod. Checksum offloading (Tx i Rx) r8169 zvládne, scatter-gather taky, TSO taky, na GRO není podpora v hardware potřeba (a LRO je stejně většinou potřeba vypnout). Někomu by se možná hodil vlan tagging/stripping, ale zdaleka ne každému a na výkon to u gigabitu až takový vliv mít stejně nebude. Multiqueue… na serveru by se to hodit mohlo, ale, levnější NIC od Intelu (typicky ty s e1000 nebo e1000e driverem) mají jen jednu frontu, takže je potřeba něco "serverového", co stojí zhruba dvakrát tolik (aby ty fronty byly aspoň dvě).

To doporučení pochází ještě z doby 100Mb/s karet s 8139 chipsetem. Ne že by s těmi gigabitovými problémy nebyly, ale ty se týkají spíš power managementu a střídavého zakazování a povolování ASPM pro jednotlivé varianty, protože výrobce nespolupracuje a informace, co přesně má kde fungovat a jak, neposkytuje.

[Heron]

spíš by mne zajímal nějaký technický důvod

Já ho neznám. Podle mě za to tehdy mohly drivery nebo firmware. Netuším, nikdy jsem to nezkoumal, prostě jsem místo toho koupil jinou kartu.

Vím, že si někdo kompiloval vlastní drivery (jestli je sehnal přímo na realteku nevím), ale to je zase problém s update kernelu (a pokud se jedná o vzdálený síťový server, tak je to problém ještě větší).

[GeorgeWH]

Pretoze kedysi realtek sietovka s ovladacmi v jadre nefungovala (vsetko svietilo-blikalo, ale data netiekli). Po nahodeni driverov od vyrobcu to islo max 60-65MB/s. Druha sietovka fungovala s kernelovym modulom, ale tak isto nedala plnu linku. Tiez som vtedy ziskal averziu voci realteku a mam ju do dnes. Ale ano, s podobym problemom som sa uz od vtedy nestretol. Ale...

[Michal Kubeček]

Přesně kvůli tomuhle jsem zdůrazňoval, že mne zajímají technické důvody, ne citové. Performance je složitá věc obecně a síťování není výjimkou; nahrazovat analýzu problému cargo kultem není správná cesta.

Mně se prostě nelíbí, když kvůli tomu, že někdy před 20 lety 100Mb/s NIC Realteku neměly některé základní funkce, lidé dnes bez rozmyslu aplikují tuto zkušenost na dnešní gigabitové NIC s úplně jiných chipsetem a doporučují ostatním nahrazovat je "desktopovými" kartami od Intelu, které toho typicky budou umět tolik, co ten Realtek. Víc toho budou umět až "serverové" varianty, ale ty už jsou přeci jen trochu dražší a většina uživatelů stejně rozdíl nepozná, určitě ne na rychlosti jednoho TCP spojení po lokálním ethernetu (tj. bez ztrát a s minimální latencí).

Vůbec tím nechci říct, že aktuální stav kolem Realteku je ideální. Výrobce moc nespolupracuje, takže typicky chvíli trvá, než mainline driver začne podporovat nové verze chipsetů, a chronické problémy s (ne)fungováním ASPM a s tím související reverty revertů revertů jsou už tak trochu legendou. Ale pokud někomu integrovaný adaptér funguje, není obvykle důvod ho nahrazovat - a už vůbec ne jen proto, že "se to říká". Pokud člověk tak jako tak potřebuje přidat kartu, tak je to samozřejmě něco jiného, ale pokud má integrovaný adaptér a ten mu funguje, není důvod se plašit.

[Aleš Kapica]

Usuzuješ na rychlost pole z testu jednotlivých zařízení. To vůbec nic neznamená.

Je jasné, že problém bude nejspíš někde na straně úložiště. Ovšem nejprve by měl otestovat rychlost na datech sdílených z RAM disku.

Já také nedávno řešil strašně pomalé I/O. Měl jsem 2x SSD samsung a 1x kingston. Když byly jden dva disky, bylo vše ok. Jakmile byly tři, pomalé jak šnek. Nakonec jsem zjistil, že vždy brutálně brzdí disk, který řadič na desce detekuje jako sda (vůbec nezáleželo který z nich to byl). Vyřešil jsem to tak, že jsem ty disky vyměnil za 2x novější a větší SSD samsung, které jsem zapojil přes samostatné řadiče a je klid. Holt deska je stará a něco už po deseti letech nepřetržité služby odchází do kopru.

[palardd]

Sorry, ale jaksi zapomínáš že vše má svou režii, takže těžko dosáhneš stejných rychlostí, jako při použití testu. Podle všeho to vypadá na rotační disky, možná SSHD.

To jsem samozřejmě zvážil a proto jsem psal třeba u gigabitu jen 80 % kapacity média.

Proto jsem psal rychlosti disků, i kdyby se 20 % ztrácelo na arbitráž apod. Pořád je to hrozně pomalé.

[pavele]

No já bych začal nejprve s testováním propustnosti sítě pomocí iperf, je pro Linux i Windows.

Pokračoval bych testováním maximální rychlosti zápisu souboru velikosti 4 GB a více do pole pomocí dd (dd if=/dev/zero of=/cesta/k/adresáři/samby/test1.img bs=4G count=1 oflag=dsync) - nemělo by v tom výpisu být něco jako "md0", když se jedná o raid?

Vyloučil bych vliv Windows 10 použitím jiného OS (např. live verze Ubuntu).

Teprve potom bych se začal zabývat Sambou, verzí smb1-2-3 atd.

[palardd]

No já bych začal nejprve s testováním propustnosti sítě pomocí iperf, je pro Linux i Windows.

Děkuji, že mi pomáháš. Tohle vypadlo. Client connecting to 192.168.1.102, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.22 port 53218 connected with 192.168.1.102 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 852 MBytes 715 Mbits/sec Takže kolem těch 700 Mb/s by to mělo zvládnout.

[pavele]

No já bych začal nejprve s testováním propustnosti sítě pomocí iperf, je pro Linux i Windows.

Děkuji, že mi pomáháš. Tohle vypadlo. Client connecting to 192.168.1.102, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.22 port 53218 connected with 192.168.1.102 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 852 MBytes 715 Mbits/sec Takže kolem těch 700 Mb/s by to mělo zvládnout.

Promiň jestli to blbě čtu, ale 715 Mbits/sec rozhodně nedá 700 Mb/s (715 Mbit = 89.375 MB)...

[Michal Kubeček]

Proč ne? Všimněte si, že je tam "Mb", ne "MB".

[Nereknu]

šéfe, nějak si pleteš MB/s s Mb/ ;)

[Nereknu]

Mb/s

[palardd]

Pokračoval bych testováním maximální rychlosti zápisu souboru velikosti 4 GB a více do pole pomocí dd (dd if=/dev/zero of=/cesta/k/adresáři/samby/test1.img bs=4G count=1 oflag=dsync) - nemělo by v tom výpisu být něco jako "md0", když se jedná o raid?

AAA:~# time dd if=/dev/zero of=/Video/PHOTOGRAPHY/image.iso bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 42.1266 s, 51.0 MB/s

real    0m42.290s
user    0m0.000s
sys     0m4.203s

zápis na RAID1 pole se dvěma disky. /Video namontováno jako RAID1 pole.
ČTENÍ

AAA:~# time dd of=/dev/null if=/Video/PHOTOGRAPHY/image.iso bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 1.58343 s, 1.4 GB/s

real    0m1.672s
user    0m0.000s
sys     0m1.668s

[Heron]

Ten zápis je podezřele pomalej.

Čtení evidentně běží z iocache, tj ram.

Hele, co to je za HW?

[palardd]

Ten zápis je podezřele pomalej.

Čtení evidentně běží z iocache, tj ram.

Hele, co to je za HW?

16 GB RAM
AMD Phenom(tm) II X6 1055T Processor, 1312 MHz
Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
                      AMD Family 10h Processor Miscellaneous Control
                       AMD Family 10h Processor Address Map
                       AMD RS780/RS880 PCI to PCI bridge (int gfx)
                       ATI SB7x0/SB8x0/SB9x0 LPC host controller
                       AMD RS880 Host Bridge
                       AMD Family 10h Processor Link Control
                       AMD Family 10h Processor DRAM Controller
                       ATI SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0)
                       AMD Family 10h Processor HyperTransport Configuration
                       ATI SBx00 PCI to PCI Bridge
                       AMD RS780/RS880 PCI to PCI bridge (PCIE port 5)

Uvnitř je 8 disků na SATA
- systém SATA 1 TB
RAID1 (2 disky) 2x 4 TB
RAID1 (2 disky) 2x 3 TB
obyčejný mount na další disk bez RAID (1x 1,5 TB)
disk:
  /dev/sdf             WDC WD30EFRX-68E
  /dev/sdd             WDC WD40EZRZ-00G
  /dev/sdb             WDC WD40EZRZ-00G
  /dev/sde             SAMSUNG HD154UI
  /dev/sdc             WDC WD30EFRX-68E
  /dev/sda             ST2000VX002-1AH1

[Michal Kubeček]

Podle té rychlosti u druhého příkazu to vypadá, že jste ho spustil hned po tom prvním, takže bylo všechno ještě v page cache a z toho pole se nečetlo vůbec nic. Zkuste buď přidat ještě iflag=direct nebo mezi těmi dvěma příkazy spustit

  echo 3 >/proc/sys/vm/drop_caches

[palardd]

Podle té rychlosti u druhého příkazu to vypadá, že jste ho spustil hned po tom prvním, takže bylo všechno ještě v page cache a z toho pole se nečetlo vůbec nic. Zkuste buď přidat ještě iflag=direct nebo mezi těmi dvěma příkazy spustit

  echo 3 >/proc/sys/vm/drop_caches

OK, udělal jsem: Výsledek:

AAA:~# time dd if=/dev/zero of=/Video/PHOTOGRAPHY/image.iso bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 31.4933 s, 68.2 MB/s

real    0m31.603s
user    0m0.004s
sys     0m3.929s
AAA:~# echo 3 >/proc/sys/vm/drop_caches
AAA:~# time dd of=/dev/null if=/Video/PHOTOGRAPHY/image.iso bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 25.5666 s, 84.0 MB/s

real    0m26.106s
user    0m0.008s
sys     0m4.505s

[pavele]

Podle té rychlosti u druhého příkazu to vypadá, že jste ho spustil hned po tom prvním, takže bylo všechno ještě v page cache a z toho pole se nečetlo vůbec nic. Zkuste buď přidat ještě iflag=direct nebo mezi těmi dvěma příkazy spustit

  echo 3 >/proc/sys/vm/drop_caches

OK, udělal jsem: Výsledek:

AAA:~# time dd if=/dev/zero of=/Video/PHOTOGRAPHY/image.iso bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 31.4933 s, 68.2 MB/s

real    0m31.603s
user    0m0.004s
sys     0m3.929s
AAA:~# echo 3 >/proc/sys/vm/drop_caches
AAA:~# time dd of=/dev/null if=/Video/PHOTOGRAPHY/image.iso bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 25.5666 s, 84.0 MB/s

real    0m26.106s
user    0m0.008s
sys     0m4.505s

Jak chceš saturovat 1 GB síť, když máš rychlost zápisu na disk 68.2 MB/s nebo 84.0 MB/s? To je nějak málo na RAID10, ne?

[palardd]

Jak chceš saturovat 1 GB síť, když máš rychlost zápisu na disk 68.2 MB/s nebo 84.0 MB/s? To je nějak málo na RAID10, ne?

Celou dobu mluvím o RAID 1. A i kdyby, disky mají 130 MB čtení, je to RAID, takže těch 130 MB bych velice rád dosáhl ve čtení. A hledám cestu, jak.

[Heron]

Myslel jsem, že RAID 10 přidá výkon, čte se z obou najednou.

Hele, možná by ten dotaz chtělo strukturovat a napsat celý znovu.

V původním dotazu se píše o raid10 a kopírování se testuje na 1.3GB souboru. Potom uvádíš raw fotky a Lr a teď raid1. Do toho se motá samba, síť, disky. V tomhle se nikdo nevyzná.

Takže teď je evidentní, že je problém v pomalosti pole, zatímco disky se zdají být v pořádku. Btw, co smart? Jsou ty disky skutečně ok?

[palardd]

Myslel jsem, že RAID 10 přidá výkon, čte se z obou najednou.

Hele, možná by ten dotaz chtělo strukturovat a napsat celý znovu.

V původním dotazu se píše o raid10 a kopírování se testuje na 1.3GB souboru. Potom uvádíš raw fotky a Lr a teď raid1. Do toho se motá samba, síť, disky. V tomhle se nikdo nevyzná.

Takže teď je evidentní, že je problém v pomalosti pole, zatímco disky se zdají být v pořádku. Btw, co smart? Jsou ty disky skutečně ok?

Ale je jedno, jestli je to 4GB file nebo 100x40MB, pokaždé (podle toho, jak se dívám na síťové rozhraní a zápis na lokální dost a čtení ze serveru, je to cca 50 MB/s).

Právě proto se motám dokola a nevím, kde začít rozmotávat.

Disky mají kolem 150 MB/s (kromě jednoho, který není v RAIDu a ten mě nezajímá)

Síť má propustnost dostatečnou na 700 Mb/s

Zůstává mi něco v samba...Takže vyzkoušet nějaké FTP?

[palardd]

Disky smartctl všechny OK

[palardd]

FTP (SSL) jede dokonce jen 22 MB/s ze serveru na notebook, kde je NVMe disk

[Heron]

Zůstává mi něco v samba...

Jak se to může týkat samby, když to pole má při lokálním testu zápis 68 a čtení 84MB/s?

Ano, v sambě může být ještě nějaký další problém, ale pokud je to pole takto pomalé, tak je nutné vyřešit nejdřív toto. Na 150MB/s diskách není normální mít 68MB/s zápis na pole.

Co na to říká mdadm --detail /dev/pole? Ať víme, jak je sestavené.

[palardd]

Co na to říká mdadm --detail /dev/pole? Ať víme, jak je sestavené.

/dev/md0:
           Version : 1.2
     Creation Time : Sat Jul 29 10:54:04 2017
        Raid Level : raid1
        Array Size : 2930134016 (2794.39 GiB 3000.46 GB)
     Used Dev Size : 2930134016 (2794.39 GiB 3000.46 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Tue Sep  1 16:31:55 2020
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : debian:0
              UUID : e65ce113:bd09ac82:0513cda0:0f13218d
            Events : 6095

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       81        1      active sync   /dev/sdf1

A

/dev/md33:
           Version : 1.2
     Creation Time : Sat Jun 15 07:37:46 2019
        Raid Level : raid1
        Array Size : 3906884608 (3725.90 GiB 4000.65 GB)
     Used Dev Size : 3906884608 (3725.90 GiB 4000.65 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Tue Sep  1 17:33:25 2020
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : nadarnas:33  (local to host nadarnas)
              UUID : 27e349df:93320b5b:4075bad2:5cca8808
            Events : 57147

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       2       8       17        1      active sync   /dev/sdb1

[Michal Kubeček]

Na 150MB/s diskách není normální mít 68MB/s zápis na pole.

Ne do pole, ale do filesystému na tom poli, to může být rozdíl. Další potenciální problém je ten nešťastný parametr "bs=4G". Nedíval jsem se do zdrojáků, ale vůbec bych se nedivil, kdyby chudák dd musel nejdřív naalokovat 4 GB paměti, ze které pak půlku opravdu použil (při čtení; při zápisu asi všechno). Jestli při tom bylo potřeba flushnout nějaké stránky (na tytéž disky), aby se udělalo místo, tak to na klasickém disku s pomalým seekem taky na rychlosti nepřidá.

Možná by stálo za to zkusit ten test zopakovat s rozumnější velikostí bloku ("bs=1M count=4M" by mělo bohatě stačit).

[Michal Kubeček]

("bs=1M count=4M" by mělo bohatě stačit).

Oops, samozřejmě "bs=1M count=4K"

[Heron]

Ano, skutečně lze dosáhnout reálné rychlosti 117MB/s. Samba může bez problémů saturovat gigabit. (Fakt nechápu v roce 2020 komentáře, že 30MB/s je ok. To nebylo ani v roce 2008.)

Jaký je původ těch souborů? Nebyly staženy torrentem (a tedy jsou značně fragmentované), lze na tom nasku pustit něco jako pv ten_soubor > /dev/null nebo třeba jen cat a změřit čas?

A vedle toho nezávisle změřit průchod sítě (komentář výše).

[Heron]

Příloha:

• w10-1GbE.png (47204 bytů)

A to i v W10 (příloha).

[Michal Kubeček]

A když se ukáže, že to není síť (což by opravdu neměla), bylo by dobré pro další pokus eliminovat storage. Na straně Linuxu nasdílením adresáře na tmpfs, Windows neznám, ale nejspíš tam něco podobného taky bude. Tím by se mělo ukázat, je-li problémem implementace CIFS (ať už na kterékoli straně) nebo storage (ať už na kterékoli straně).

[palardd]

Ano, skutečně lze dosáhnout reálné rychlosti 117MB/s. Samba může bez problémů saturovat gigabit. (Fakt nechápu v roce 2020 komentáře, že 30MB/s je ok. To nebylo ani v roce 2008.)

Jaký je původ těch souborů? Nebyly staženy torrentem (a tedy jsou značně fragmentované), lze na tom nasku pustit něco jako pv ten_soubor > /dev/null nebo třeba jen cat a změřit čas?

A vedle toho nezávisle změřit průchod sítě (komentář výše).

Soubory jsou z fotoaparátu, tedy kolem 30-40 MB. Jsou to RAWy. Načítá je na stanici LIghtroom přes samba ze serveru.

[Heron]

Moment, v původním dotazu je scrshot s kopírováním nějakého (asi) filmu o velikosti 1.3GB. Jak s tím souvisí LightRoom?

Jinak dokáže Lr ty rawy zpracovat tak rychle? Zkouším Lr 5.7 (protože na CC mě fakt nenalákali) a na Ryzen R7 to zvládá tak 300Mbps max (načítání na grid + develop jednoho snímku). To není příliš dobrý test propustnosti.

[ZAH]

Co tahle sem dát smb.conf. Není tam například něco takového

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE

[_]

Co tohle dělá?

[ZAH]

Dřív to nastavovalo vlastnosti socketu samby dnes je to řasto příčina mal= propustnosti. V smb.conf může být více problematických parametrů,

[Heron]

testparm na to i upozorňuje:

Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
WARNING: socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE
This warning is printed because you set one of the
following options: SO_SNDBUF, SO_RCVBUF, SO_SNDLOWAT,
SO_RCVLOWAT
Modern server operating systems are tuned for
high network performance in the majority of situations;
when you set 'socket options' you are overriding those
settings.

Linux in particular has an auto-tuning mechanism for
buffer sizes (SO_SNDBUF, SO_RCVBUF) that will be
disabled if you specify a socket buffer size. This can
potentially cripple your TCP/IP stack.

Getting the 'socket options' correct can make a big
difference to your performance, but getting them wrong
can degrade it by just as much. As with any other low
level setting, if you must make changes to it, make
 small changes and test the effect before making any
large changes.

[Michal Kubeček]

SO_RCVBUF=8192 SO_SNDBUF=8192

Slovy klasika: to dává slovu hrůza nový rozměr. Nejhorší na tom asi je, že to druhé je dodnes v smb.conf(5) jako příklad…

[palardd]

Co tahle sem dát smb.conf. Není tam například něco takového

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE

Socket mám zakomentovaný

#socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384

[PetebLazar]

Prvně bych ověřil průchodnost LAN mezi oběma stroji například pomocí IPERF3 (iperf3 -s na straně serveru a iperf3 -c se.rv.er.IP na straně klienta).

Myslím, že SaMBou se dá saturovat i 10Gbps LAN, u 1Gbps LAN by to mělo asi jít i bez podpory Jumbo Frame.

Myslel jsem, že RAID 10 přidá výkon, čte se z obou najednou.

Toť otázka. I v případě že algoritmus RAID1 bude optimálně číst u čistě sekvenčního IO pouze polovinu dat z každého členu (u RAID0 musí), při malé (typické) velikosti stripe vůči kapacitě tracku budou oba HDD trávit čas na stejném tracku čekaním než se jim pod hlavou protočí všechny "jejich" sektory. Což bude o obou členů znamenat typicky jednu celou otáčku.

[Michal Kubeček]

Jumbo frames až tak velký efekt nemají a obecně na ně stejně nelze spoléhat.

[cyberpunk2077]

do /etc/sysctl.conf hodit toto:

 
net.core.rmem_default = 31457280
net.core.rmem_max = 12582912
net.core.wmem_default = 31457280
net.core.wmem_max = 12582912
net.core.somaxconn = 4096
net.core.netdev_max_backlog = 65536
net.core.optmem_max = 25165824
net.ipv4.tcp_mem = 65536 131072 262144
net.ipv4.udp_mem = 65536 131072 262144
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_no_metrics_save = 1
net.core.rmem_max=8388608
net.core.wmem_max=8388608
net.core.rmem_default=65536
net.core.wmem_default=65536
net.ipv4.tcp_rmem=4096 87380 8388608
net.ipv4.tcp_wmem=4096 65536 8388608
net.ipv4.tcp_mem=8388608 8388608 8388608
net.ipv4.route.flush=1

do /etc/samba/smb.conf pridat do [global]

 
socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288 IPTOS_LOWDELAY
socket options = SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65535 SO_RCVBUF=65535
read raw = yes
write raw = yes
max connections = 65535
max open files = 65535
write cache size = 1809715200
read cache size = 1809715200
read raw = Yes
write raw = Yes
min receivefile size = 16384
use sendfile = true
aio read size = 96384
aio write size = 96384

a daj vysledok ci pomohlo

[Michal Kubeček]

net.ipv4.tcp_no_metrics_save = 1

Jestli tazatel opravdu kopíruje soubory o velikosti 30-40 MB (tj. relativně malé), tak by tohle mohl být trochu problém, záleží na tom, jestli samba používá dlouhodobě jedno spojení nebo jestli opakovaně otevírá nová.

socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288 IPTOS_LOWDELAY
socket options = SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65535 SO_RCVBUF=65535

Neznám z hlavy syntaxi smb.conf, abych byl schopný říct, která z těch tří velikostí bufferu se nakonec použije, ale pokud by to byla ta poslední, tak vás to začne limitovat už při RTT kolem 0.5 ms. Vzhledem k tomu, že typické hodnoty v nezatížené domácí gigabitové síti mívám někde kolem 0.2 ms, tak to není moc velká rezerva.

[palardd]

<net.ipv4.tcp_no_metrics_save = 1

Jestli tazatel opravdu kopíruje soubory o velikosti 30-40 MB (tj. relativně malé), tak by tohle mohl být trochu problém, záleží na tom, jestli samba používá dlouhodobě jedno spojení nebo jestli opakovaně otevírá nová.

Je to velice různé, z 20-30 procent kopíruju velké archívy, námi natočené videa, stovky MB až jednotky GB. A pak ze 70 procent soubory, 40 MB každý

Ale výkon je pořád do těch 50 MB

[palardd]

neee, vše při starém

[ZAH]

Dvě věci.

1. Jaké je vytížení procesoru 2. Verze protokolu samby.

[palardd]

Dvě věci.

1. Jaké je vytížení procesoru 2. Verze protokolu samby.

1. kolem 30 až 50 procent (max) 2. Version 4.7.6-Ubuntu, protokol

client min protocol = SMB2
client max protocol = SMB3   

[ET]

co tam mas za FS?

[palardd]

co tam mas za FS?

ext4

[palardd]

Doplnění

• Test rsync ze samba z Linux seerveru - Utilizace cca 30-50 procent - Přenos 33 MB/s (pokud je to v cache, jede to 100 MB/s = to je MAX a je to těch 800 Mb/s pro Ethernet
• FTP (SSL) - Přenos cca 20-30 MB/s

[SE]

Zkuste NFS, Linux - Linux, kolik to pojede a podle výsledku bych hledal dál. NFS by mělo 100 MB/s dát, pokud je síť a pole OK.

[AraxoN]

Potvrdzujem - po porovnávacom teste Samba vs NFS som nakoniec dlho používal NFS (prakticky až do prechodu na Ceph).

[palardd]

Potvrdzujem - po porovnávacom teste Samba vs NFS som nakoniec dlho používal NFS (prakticky až do prechodu na Ceph).

To asi nepomůže, když mám na straně klienta Widle

[k3dAR]

Windows maji nativniho NFS klienta, nicmene dokud neodstranis problem s pomalem cteni z disku, tak nema cenu resit Samba Vs NFS...

uz si zkusil nasdilet Sambou neco z "RAM"? => adresar /dev/shm nasdilej, neco tam hodi a klientem to cti klidne tou sambou...

[frr]

Bylo tu několik rad ohledně síťovin. Tuším nebyl zmíněn tenhle atribut:

net.ipv4.tcp_slow_start_after_idle=0

Ten jsem sice našel v souvislosti s NFS, ale odhadem Sambě by taky mohl pomoct.

Co je to za filesystém? Ext4? Mountujete ho s opšnou "noatime"? Jaký IO scheduler? Co to je za Linux?

Obecně bych ještě doporučil, poladit chování VM = povolit větší využití volné systémové RAM pro cachování diskových operací, a možná zkusit přepnout IO scheduler na "deadline" a třeba ho ještě taky trochu poladit. Rychlosti čtení to asi moc nepomůže, ale jestli máte hodně RAMky, měl byste vidět její efekt (hlavně při zápisu, kdy se uplatní write-back buffering).

[palardd]

Bylo tu několik rad ohledně síťovin. Tuším nebyl zmíněn tenhle atribut:

net.ipv4.tcp_slow_start_after_idle=0

Ten jsem sice našel v souvislosti s NFS, ale odhadem Sambě by taky mohl pomoct.

Zkusím díky

Co je to za filesystém? Ext4? Mountujete ho s opšnou "noatime"? Jaký IO scheduler? Co to je za Linux?

Nee mám tohle ve fstab /dev/md0 /Video ext4 defaults,nofail,discard 0 0 /dev/md33 /home ext4 defaults,nofail,discard 0 0

Obecně bych ještě doporučil, poladit chování VM = povolit větší využití volné systémové RAM pro cachování diskových operací, a možná zkusit přepnout IO scheduler na "deadline" a třeba ho ještě taky trochu poladit. Rychlosti čtení to asi moc nepomůže, ale jestli máte hodně RAMky, měl byste vidět její efekt (hlavně při zápisu, kdy se uplatní write-back buffering).

Díky kouknu se TP

[palardd]

To je zvláštní, teď jsem kopíroval 4GB file na pole a jelo to 100 MB/s Fakt to přestávám chápat.

[kapo]

To pouze znamená, že v sambě problém nebude. 4GB soubor se vejde do 16GB RAMky,takže jste jen saturoval síť. Zkuste kopírovat soubor >16GB a uvidíte.

[frr]

Nebo to znamená, že zápis na disky jede plnou rychlostí.

Kdežto při čtení z FS, bez explicitního -o noatime, způsobí aktualizace "access time" takové mrhání IOps, že rychlost spadne třeba na půlku až třetinu toho, co jinak disky umí sekvenčně. Toto jsou moje historická pozorování. A jak správně říkáte, nebyl by to problém v sambě.

S defaultním nastavením dirty/writeback poměrů a časů není systémová writeback cache blokových zařízení příliš hluboká a trpělivá, Vaší hypotéze by to příliš neodpovídalo.

[dustin]

Překvapuje mě, že noatime stále ještě není default.

[kol-ouch]

Zkus tu rychlost otestovat přes cifs (bod 4) https://www.abclinuxu.cz/poradna/linux/show/458986#89

Mě to dost překvapilo

[kapo]

Možná bude problém v použité staré verzi samby. Zkusil bych na serveru zadat jen podporovanou verzi protokolu SMB3:

client min protocol = SMB3
client max protocol = SMB3

viz odkaz na konfiguraci.

[kol-ouch]

Ok, zkusím. Dík moc

[palardd]

[SOLVED]

Jakmile jsem pořídil nový HW ASROCK J5040-ITX, na to 8 GB paměti (poloviční než ten původní) a rozšiřující kartu AXAGON PCES-SA2, abych měl potřebných 6 SATA III portů. IHNED to běhá 100-110 MB/s při čtení i zápisu na SAMBA.

Takže někde mezi HW desky, síťovkou a rozhraním SATA byl problém.