Ha te kliensként mountolod a sharet és teszel fel rá valamit akkor a te kliensed is számit hogy milyen gyorsan tudja küldeni amit kell, a közben utba eső eszközöké is pl, majd a végén a szerver is hogy éppen mit csinál , van-e esetleg más szolgáltatás rajta ami hálózatot, cpu-t akármit fogyaszt.
Iperf-fel merd meg a halozat sebesseget, utana a gepen masolj egy fajlt, lasd mennyi az ssd/bus atvitele. Probalj ki mas protokollt, gepre tolts le http-n valami nagyot.
Ha már itt tartunk: 10GbE fölött nem nagyon tudok elérni Samba-val 4-5Gbps feletti sebességet. Ugyanaz a fájl ugyanarról a szerverről HTTPS fölött (Apache a szerveren, wget a kliensen) 9,27Gbps-sel jön. Akinek van 10 gigás ethernet és Samba kéznél, rá tudna kérem kukkantani, hogy nála mennyi az annyi?
Sparse fájllal (is) próbálom, nem várunk háttértárra...
hat en azt tapasztaltam az elmult kb 20 ev alatt hogy a linuxos samba mindig csak kb a 40%-at tudja kihasznalni a raw halozati sebessegnek (vagy pl. ftp-vel osszehasonlitva). mind1 hogy 10, 100 mbitrol vagy gigabitekrol beszelunk. ez van. gondolom valami implementacios nyug. pedig eleg sok sambat uzemeltetek sokfele vason, foleg szervereken rendes kartyaval, es akkor is. ugyanakkor egy sima win7 vagy win10 desktop alol megosztva meg majdnem megvan a wirespeed...
valahol talaltam 1x egy leirast milyen kernel parameterek (foleg tcp stack tuning) erdemes allitgatni, de emlekeim szerint segitett valamit de nem latvanyosan.
a route-olast meg kulonosen utalja, akkor meg jobban leesik a speed, mintha lanon belul nezzuk.
Nem is szabad... talán 2020-as SambaXP környékén volt perf konfiggal kapcsolatos előadás (archívumban biztos fenn van), kb. 0 szabály, hogy csak mert random fórumban / stackoverflow-n van egy konfig részlet ami valakinek, valahol, valamikor és valamire működött, még nem szabad használni.
Fejből írom de: 1) gyakorlatilag főverziónként változhatnak ezeknek a paramétereknek a teljesítményhatásuk 2) mindig egy adott use case-re működhetnek [adott verzióval!] 3) a kliens is fontos szerepet játszik.
Pl. a fentiben ott van a use sendfiles, amivel az aszinkron IO-t gyakorlatilag lelőtted (és egyébként semmi hatása nincs, mióta van encryption protokoll-szinten, ha a handshake során megegyeznek egy titkosításban, úgyis meg kell kerülni a kernelt).
Inkább kísérletezz, pl. próbáld ki, hogy a vfs_aio_linux változtat-e valamit (https://www.samba.org/samba/docs/4.3/man-html/vfs_aio_linux.8.html), nézd meg, hogy a kliens és a szerver miben egyezik meg (protokoll verzió, titkosítás etc.), simán lehet, hogy nem a hálózati alrendszer a bottleneck.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Én ezeket a samba dolgokat elengedném, nincs manapság open source google drive / dropbox szerű cucc, ami szinkronizálgat szépen?
nálunk van minden (gDrive, OneDrive, Dropbox, iCloud), nextcloud is, de azt csak webről.
nagyon ritka ugyanis az, hogy neked olyan fájlok kellenek gyorsan, amikkel még sose találkoztál, és a fenti cuccok abban nagyon jók, hogy prediktálják, neked melyik fájlra lesz szükséged, amire lekattintanád már le van töltve.
Ennyit nem ront a gagyi alaplapi Realtek csip sem. Tapasztalatom szerint az 1GbE interfészen 500-600 Mbps meg szokott lenni a leggagyibb kártyával is, ha nem túl régi a kernel (friss a driver). Itt meg egy század sebességet mér...
Azért érdemes mindenféle hw gyorsítást kilőni a driverből, hátha, valamint a gigabit milyen késleltetésű, mert arra is érzékeny, a VPN-t pl nagyon nem komálja az SMB.
Ezt sajnos tapasztalom. Eddig VPN-en át egyedül Telekom optika - netcup irányba (és fordítva) sikerült elérni reszponzív működést (mappalista, másolás etc.). DIGI-ről például elég gyenge.
Internet oldalon megy szépen ahogy kell. Gyakorlatilag gigabit. Most a kérdés az hogy smb miért korlátoz... semmi értelme nincs az egésznek. Azért kell amúgy samba mert meghajtó szépen csatolva van, otthon ah összes gépről látom a média tartalmakat. Szerver tárolja és tölti amit kell, user pedig használja akár a kert végében is laptopról. Ez a lényeg itt kérem szépen.
Hozzászólások
Persze, pl a HDD/SSD, filerendszer....
Ha te kliensként mountolod a sharet és teszel fel rá valamit akkor a te kliensed is számit hogy milyen gyorsan tudja küldeni amit kell, a közben utba eső eszközöké is pl, majd a végén a szerver is hogy éppen mit csinál , van-e esetleg más szolgáltatás rajta ami hálózatot, cpu-t akármit fogyaszt.
ssd, ext4
mindegyik gépbe ssd van, arról másol és arról ír. van rajt egy apache, meg egy samba. nagyjából ez a felállás. régi gép viszonylag, core 2, 4gb ram.
Jah, közel 15 éves :)
Iperf-fel merd meg a halozat sebesseget, utana a gepen masolj egy fajlt, lasd mennyi az ssd/bus atvitele. Probalj ki mas protokollt, gepre tolts le http-n valami nagyot.
Smb iras vagy olvasas is lassu?
Smb írás és olvasás is lassú. Viszont internet oldalról pedig jobb. Ssd io az ilyen 2000mbps körül mozog.
Ha már itt tartunk: 10GbE fölött nem nagyon tudok elérni Samba-val 4-5Gbps feletti sebességet. Ugyanaz a fájl ugyanarról a szerverről HTTPS fölött (Apache a szerveren, wget a kliensen) 9,27Gbps-sel jön. Akinek van 10 gigás ethernet és Samba kéznél, rá tudna kérem kukkantani, hogy nála mennyi az annyi?
Sparse fájllal (is) próbálom, nem várunk háttértárra...
hat en azt tapasztaltam az elmult kb 20 ev alatt hogy a linuxos samba mindig csak kb a 40%-at tudja kihasznalni a raw halozati sebessegnek (vagy pl. ftp-vel osszehasonlitva). mind1 hogy 10, 100 mbitrol vagy gigabitekrol beszelunk. ez van. gondolom valami implementacios nyug. pedig eleg sok sambat uzemeltetek sokfele vason, foleg szervereken rendes kartyaval, es akkor is. ugyanakkor egy sima win7 vagy win10 desktop alol megosztva meg majdnem megvan a wirespeed...
valahol talaltam 1x egy leirast milyen kernel parameterek (foleg tcp stack tuning) erdemes allitgatni, de emlekeim szerint segitett valamit de nem latvanyosan.
a route-olast meg kulonosen utalja, akkor meg jobban leesik a speed, mintha lanon belul nezzuk.
most rakeresve itt adnak par otletet:
https://superuser.com/questions/713248/home-file-server-using-samba-has…
egy probat meger:
Ezt megprobalom, olvastam a cikket én is. Vaktában nem akartam kísérletezni.
Nem is szabad... talán 2020-as SambaXP környékén volt perf konfiggal kapcsolatos előadás (archívumban biztos fenn van), kb. 0 szabály, hogy csak mert random fórumban / stackoverflow-n van egy konfig részlet ami valakinek, valahol, valamikor és valamire működött, még nem szabad használni.
Fejből írom de: 1) gyakorlatilag főverziónként változhatnak ezeknek a paramétereknek a teljesítményhatásuk 2) mindig egy adott use case-re működhetnek [adott verzióval!] 3) a kliens is fontos szerepet játszik.
Pl. a fentiben ott van a use sendfiles, amivel az aszinkron IO-t gyakorlatilag lelőtted (és egyébként semmi hatása nincs, mióta van encryption protokoll-szinten, ha a handshake során megegyeznek egy titkosításban, úgyis meg kell kerülni a kernelt).
Inkább kísérletezz, pl. próbáld ki, hogy a vfs_aio_linux változtat-e valamit (https://www.samba.org/samba/docs/4.3/man-html/vfs_aio_linux.8.html), nézd meg, hogy a kliens és a szerver miben egyezik meg (protokoll verzió, titkosítás etc.), simán lehet, hogy nem a hálózati alrendszer a bottleneck.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Én ezeket a samba dolgokat elengedném, nincs manapság open source google drive / dropbox szerű cucc, ami szinkronizálgat szépen?
nálunk van minden (gDrive, OneDrive, Dropbox, iCloud), nextcloud is, de azt csak webről.
nagyon ritka ugyanis az, hogy neked olyan fájlok kellenek gyorsan, amikkel még sose találkoztál, és a fenti cuccok abban nagyon jók, hogy prediktálják, neked melyik fájlra lesz szükséged, amire lekattintanád már le van töltve.
Otthoni ESXi, Dell PowerEdge T140, Intel Xeon E-2224 CPU 3.4 GHz, erősen powersave-re hangolva.
VM-ek Debian 10.12, kernel 4.19.248, Ethernet controller: VMware VMXNET3
Extra opciók a szerver konfig-jában:
Sejtésem szerint alaplapi hálókártyát használsz. Az sokat levehet. Tegyék bele rendes szerver hálókártyát. Hátha.
Csak akkor szólok hozzá egy témához, ha értelmét látom.
Ennyit nem ront a gagyi alaplapi Realtek csip sem. Tapasztalatom szerint az 1GbE interfészen 500-600 Mbps meg szokott lenni a leggagyibb kártyával is, ha nem túl régi a kernel (friss a driver). Itt meg egy század sebességet mér...
Azért érdemes mindenféle hw gyorsítást kilőni a driverből, hátha, valamint a gigabit milyen késleltetésű, mert arra is érzékeny, a VPN-t pl nagyon nem komálja az SMB.
Ezt sajnos tapasztalom. Eddig VPN-en át egyedül Telekom optika - netcup irányba (és fordítva) sikerült elérni reszponzív működést (mappalista, másolás etc.). DIGI-ről például elég gyenge.
TheAdam
azt se tudjuk egyáltalán jó-e a net a két gép között
Gábriel Ákos
protokoll veletlenul nincs smb v1 -re korlatozva ?
Mert azzal a windows se tud 25-30 MB/s -nél többet.
az otthoni alap sambam mindenfele varazslas nelkul 90MB/s körül teljesit.
HUP te Zsiga !
Internet oldalon megy szépen ahogy kell. Gyakorlatilag gigabit. Most a kérdés az hogy smb miért korlátoz... semmi értelme nincs az egésznek. Azért kell amúgy samba mert meghajtó szépen csatolva van, otthon ah összes gépről látom a média tartalmakat. Szerver tárolja és tölti amit kell, user pedig használja akár a kert végében is laptopról. Ez a lényeg itt kérem szépen.
Akkor már csak néhány információ kéne:
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- Version 4.15.5-Ubuntu
- samba config
- Linux srv1 5.15.0-39-generic #42-Ubuntu SMP Thu Jun 9 23:42:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
-Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
tmpfs 191M 4,2M 187M 3% /run
/dev/sda3 109G 71G 34G 68% /
tmpfs 954M 0 954M 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
/dev/sda2 512M 5,3M 507M 2% /boot/efi
tmpfs 191M 120K 191M 1% /run/user/1000
- perpill lehalt egy ram így 2gb ram, core 2 cpu, kihasználtság 0. samba, webszerver, qtorrent.
Másolás közben nézd meg a top-ot, ott a system, user és iowait mezőket.