Dotaz: Pomaly upload veľkých súborov v SAMBE

[/dev/null]

Pri veľkých súboroch (cca 10 a viac GB) sa mi stáva nasledovné:
- začiatok kopírovania cca 90 - 100MB/s
- akonáhle sa naplní RAMkou kopírovacia cache (na stroji na ktorý kopírujem - pekne to vidieť na htop) dochádza k spadnutiu rýchosti na cca 50-70MB/s
- po čase sa rýchlosť postupne dostane na cca 25 - 30MB/s čo je pre mňa už neprijateľné

Otázka do pléna - ako to riešiť? Server na ktorý kopírujem ma 4GB RAM (využitá RAM je asi 200MB pri idle je tam len SSH, SAMBA a nič viac) a disky musia stihat zapisovat 100 MB v kuse - neverim ze je to v rychlosti diskov.

Ešte prikladám [global] sekciu zo smb.conf

[global]
 workgroup = XXXXX
 server string = XXXXXX
 netbios name = XXXXXXX
 name resolve order = lmhosts bcast wins host
 dns proxy = no
 log file = /var/log/samba/%m.log
 create mask = 0664
 directory mask = 0775
 force create mode = 0664
 force directory mode = 0775
 read raw = Yes
 server signing = No
 write raw = Yes
 strict locking = No
 socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072
 min receivefile size = 16384
 use sendfile = Yes
 aio read size = 16384
 aio write size = 16384

Odpovědi

[rastos]

Kedysi som niečo čítal, že to závisí na verzii SMB protokolu, ktorý si tie stroje dohodnú. Pátranie po detailoch som nedotiahol, vykašlal som sa na to a prenášam cez ssh (resp. scp alebo rsync).

[PetebLazar]

Co je klientem Linux/Win (pouziva klient antivirus)? Jaky je pouzity filesystem? (moznost fragmentace na jedne ci druhe strane, u HDD to muze hrat roli)? Jake je vytizeni CPU procesem smbd dle top pri zapisu? Jaka je pruchodnost sitoveho spojeni (napr. iperf3)?

[/dev/null]

Klient1: Win 7
Klient2: Ubuntu 19.04
Server: Debian Linux 9.9, JFS, 2 x 4TB HDD RAID1, cpu vytazenie do 25 percent, iperf3 som neskusal ale linka ma 920Mbps upload/download

[PetrLazar]

Jde o zatez primo konkretniho procesu (v topu), 25% vytizeni z celeho CPU(quad-core) muze klidne znamenat zastropovani vykonu procesu o silu jednoho jadra. Pokud bude mit proces u sebe 100% znamena to, ze byl schopen plne vytizit jedno jadro (u singlethread zateze).

[Max]

RAID1 - zapisuji rychlostí jednoho disku. Nevím, jak přesně funguje mdadm, ale pokud čeká na potvrzení zápisu z obou disků a jeden bude vadný, nebo bude zlobit, bude degradovaná rychlost celého pole.
Takže bych nejdříve zkontroloval SMART obou disků a přes noc na ně pustil long test.
Zkontroloval bych dmesg, zda tam nebudou nějaké chyby s ATA.
Pokud vše ok a CPU opravdu při kopírování neleze nahoru ke 100%, bych otestoval rychlost pole jako takového. Záleží totiž, co je to za disky. Pokud jsou to nějaké greeny a fragmentace je ve větší míře, může být problém. Rychlost pole můžeš do začátku otestovat hloupým zapisováním nul :

dd if=/dev/zero of=/mnt/datastore/test.img bs=4096 count=1048576

Při tom sleduj jednak vytížení CPU, dále i IO pomocí iotop

Jinak osobně nevěřím, že by jeden SATA disk zvládl kontinuálně 100MiB/s.
Zdar Max

[PetebLazar]

Dnešní slušné 3,5" 7200 ot/min dají na vnějších stopách snad i přes 200MB/s (na vnitřeních >100MB/s). https://www.alza.cz/seagate-exos-7e8-3tb-d5283784.htm

[Max]

Výkonné pro 24/7 za nějakých podmínek ano. Ale disky alá WD Green apod., to je smutnější písnička. Obzvláště, když se k tomu přidá i nějaká ta fragmentace, nebo nedejbože požadavek na více operací.
Zdar Max

[PetebLazar]

Samozrejme jsem mel na mysli low-cost FS, či dd. Tazatel zmiňuje JFS, tam patrně bude režie větší než u "čisté" sekvenční write zátěže. Nedávno jsem si pořídil jeden z levnějších 4TB modelů a při zálohování SSD/NVMe ddckem na něj se k těm 200MB/s docela přiblížil.

[Robert Kupka]

Rovnake chovanie ma aj Samba 3.6 na Turris NAS routroch, normalne 50-90 Mb/s, ale po zaplneni bufferov pada aj na pár stoviek kB/s. Spolahlive riesenie (nemam odskusane, ale vraj sa problem vyriesi) je upgrade Samby na verziu 4.x Inak funguje len flushovanie cache a odporucane nastavenie smb.conf:

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE

Babrem sa s tym uz rok a pre Sambu 3.6 nikdo ziaden rozumny fix nevymyslel.

[Max]

V Debianu 9.9 je snad samba 4.5.16, ne?
Zdar Max

[Zaphod]

Chovanie zodpovedá zapojeniu SMR (Shingled Magnetic Recording) diskov do raidu.

Starý ale dobrý článok je na diit. Hlavne kapitola "Zahlcení disku do bezvědomí" je dobrá.

Ak sú disky Seagate je pravdepodobné použitie SMR.

[PetebLazar]

A to SMR se dostalo do menších kapacit (4TB v tomto případě), měl jsem za to že pokud tak je záležitostí předevších vyšších kapacit HDD 8/10/..TB?

[k3dAR]

dostalo, minimalne u 2.5" pro 3TB a vyse (tusim ze nektere vyrobce/modely uz od 2TB), vyjimkou u 3TB je "Toshiba MQ03ABB300", vsichni ostatni jsou SMR... pred casem sem to resil tady, nakonec poridil prave 2x tu Toshibu... (btw: jedno z indicii ze jde o SMR, je kdyz ma disk cache 128MB)

[PetebLazar]

O těch 2,5" jsem se dočetl, tady si z neznámého důvodu sugeruji že jde o 4TB 3,5" HDD. Zkusil jsem dd proti cca 5let+ starému 3TB modelu Seagate 7200 ot/min (ST3000DM001), a při i 75% zaplneni jeste dáva ~150MB/s trvalého zapisu (ext4).

[Zaphod]

Mám ST1000LM035 - 2,5" 1TB externý Seagate. Je SMR. Aby som to zistil musel som stiahnuť Product Manual k diskom. Je to skryté v texte, krátka poznámka. Zápis <55TB za rok, inak padne záruka. Celá rada 500GB až 2TB je SMR.

Disk mal pomalý zápis pod NTFS aj ext4. Pomohol btrfs. Montujú ho do notebookov ako systémový disk. Update Win10 na SMR disku musí byť zážitok.

[k3dAR]

over zda nejde o "klasiku" nevhodne automaticky nastavene cache, viz(btw: problem neni/nebyl jen s USB Flash ale i s HDD)...

echo 104857600 | sudo tee /proc/sys/vm/dirty_background_bytes
echo 209715200 | sudo tee /proc/sys/vm/dirty_bytes

pokud by to resilo problem, pridej do /etc/rc.local:

echo 104857600 > /proc/sys/vm/dirty_background_bytes
echo 209715200 > /proc/sys/vm/dirty_bytes

[/dev/null]

zlepšilo sa to - minimálna rýchlosť je cca 75-80MB/s. Ďakujem

[j]

Places na spatnym hrobe, mas proste pomalej disk. Jak bylo receno, bud mas disk spatnej (= vcetne ty frikulinsky technologie), nebo ti tam hrabe jeste neco dalsiho (a je jedno jesli dalsi uzivatel pres sambu nebo nejakej dalsi proces).

Samba da naprosto vpohode bez jakyhokoli ladeni stovky MB/s. Ostatne to ze neni problem v sambe naprosto jasne indikuje stav, kdy ti do zaplneni cache saturuje sit.

Pokud by ti tam generovalo provoz neco dalsiho, pocitej s tim, ze je uplne jedno kolik toho zapisuje nebo cte, podstatny je, kolik generuje IO. Tvuj disk se 100% jistotou neda vic nez +- 150 IOps (a ty SMR kramy spis tak ctvrtinu).

Pro predstavu, jen torrenti klient generujici radove jednotky MB/s je schopen zblajznout cca 30% rychlosti.