[Debian] Samba heeft enorm slechte write-performance

[Tachyon]

Een paar dagen geleden mijn fileserver opnieuw geinstalleerd.
OS is Debian 3.1 Sarge Stable. Kernel = 2.6.8-2-686.

Hardware: P4 2.4, 1GB mem, 1Gbit NIC (Realtek 8169).
HDD's: 120GB P-ATA Hitachi voor OS, Maxtor S-ATA 200GB voor data en 2x Hitachi 160G P-ATA in RAID0, ook voor data.

Op zich werkt alles OK, maar een dag of wat geleden kwam ik er achter dat het schrijven naar een van de Samba-shares echt pathetic traag was:



Het duurt gewoon 10 minuten om 100MB te kopieren
Dit is vanaf een XP-bak naar de Samba-server. In de XP-bak zit ook een GB-NIC.

Het vreemde is dat de read-snelheid wel OK is. Dus van de Samba-server naar de XP gaat alles razendsnel, zoals het hoort.

Dit is mijn smb.conf:

code:

[global]
    log file = /var/log/samba/log.%m
    passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
    socket options = TCP_NODELAY SO_SNDBUF=16384 SO_RCVBUF=16384
    obey pam restrictions = yes
    write list = tachyon
    encrypt passwords = true
    passwd program = /usr/bin/passwd %u
    passdb backend = tdbsam guest
    dns proxy = no
    netbios name = holodeck1
    server string = fileserver
    invalid users = root
    workgroup = subspace
    os level = 20
    syslog = 0
    create mode = 600
    security = user
    panic action = /usr/share/samba/panic-action %d
    max log size = 1000
    directory mode = 700

[Docs]
    comment = Docs
    path = /media/md0/docs

[Audio]
    comment = Audio
    path = /media/md0/audio

[Stuff]
    comment = Stuff
    path = /media/md0/stuff

[Video]
    comment = Video
    path = /media/md0/video

[Movie]
    comment = Movies
    path = /media/sda2

[Capture]
    comment = Captures
    path = /media/sda1

[Meuk]
    comment = Meuk
    path = /media/hda3

Tijdens het schrijven is de CPU-load van de Samba-server zo'n 2%. Die staat dus gewoon uit zijn neus te vreten. Mijn schijven draaien allemaal keurig in DMA en een test met hdparm wijst uit dat ze ook allemaal hun snelheid halen.

Nu heb ik het volgende gemerkt: als ik tijdens het trage kopieren van bestanden vanuit mijn server een ping doe naar mijn XP-bak, dan vliegt de snelheid plotseling omhoog

Ik heb daarom het idee dat het misschien wat met DNS/resolving te maken heeft?

Maar voor zover ik weet staat alles OK: ik kan gewoon op hostnaam pingen en op het netwerk browsen.

Wie heeft enig idee?

[budi]

Als je met FTP een 100mb groot bestand beide kanten op transporteert, gaat het dan wel snel? Zo krijg je misschien een idee in welke richting je het moet zoeken. Als dit ook traag gaat, ligt het waarschijnlijk aan je bekabeling of duplex instellingen, gaat dit niet traag, dan is het idd waarschijnlijk wel iets met samba.

Zie je nog foutmeldingen in je /var/log/samba/log.smbd (of log.nmbd)?

[MrBarBarian]

Tachyon schreef op vrijdag 21 oktober 2005 @ 19:42:
Wie heeft enig idee?

Je logfiles hebben wel een idee...

sambalogs, messages en syslog.

[Nitroglycerine]

De lees en schrijfsnelheid kun je niet 1 op 1 vergelijken als je gebruik maakt van journaling, zoals ext3 of jfs. Het journaling zorgt voor een significante vertraging in het schrijven, aangezien naast het wegschrijven van de bitjes ook het journaal aangemaakt moet worden (voor restore/rebuild acties).
Bij het lezen heb je dit probleem niet.

[Boudewijn]

Nitroglycerine schreef op vrijdag 21 oktober 2005 @ 23:08:
De lees en schrijfsnelheid kun je niet 1 op 1 vergelijken als je gebruik maakt van journaling, zoals ext3 of jfs. Het journaling zorgt voor een significante vertraging in het schrijven, aangezien naast het wegschrijven van de bitjes ook het journaal aangemaakt moet worden (voor restore/rebuild acties).
Bij het lezen heb je dit probleem niet.

klopt

vraagje alleen, waarom haal ik dan met een gewoon oude bak (p3) ook 9meg dik per sec op ext3?
hiermee bedoel ik; het scheelt inderdaad, maar niet dit soort factoren.

[Verwijderd]

hdparm aan?

[Tachyon]

budi schreef op vrijdag 21 oktober 2005 @ 22:59:
Als je met FTP een 100mb groot bestand beide kanten op transporteert, gaat het dan wel snel? Zo krijg je misschien een idee in welke richting je het moet zoeken. Als dit ook traag gaat, ligt het waarschijnlijk aan je bekabeling of duplex instellingen, gaat dit niet traag, dan is het idd waarschijnlijk wel iets met samba.

Zie je nog foutmeldingen in je /var/log/samba/log.smbd (of log.nmbd)?

Ik draai geen FTP, dus dat kan ik niet testen. Mijn netwerkkaarten staan allebei op 1000Mbps Full-duplex opration en de kabel heb ik voor alle zekerheid ook vervangen, maar dat maakt niet uit. En een defecte kabel is volgens mij sowieso vrij zeldzaam.

MrBarBarian schreef op vrijdag 21 oktober 2005 @ 23:01:
[...]

Je logfiles hebben wel een idee...

sambalogs, messages en syslog.

Ik kan met de beste wil van de wereld niks vreemds ontdekken in mijn logs. In ieder geval geen foutmeldingen of iets dergelijks. Maar ik wil ze eventueel best posten.

Nitroglycerine schreef op vrijdag 21 oktober 2005 @ 23:08:
De lees en schrijfsnelheid kun je niet 1 op 1 vergelijken als je gebruik maakt van journaling, zoals ext3 of jfs. Het journaling zorgt voor een significante vertraging in het schrijven, aangezien naast het wegschrijven van de bitjes ook het journaal aangemaakt moet worden (voor restore/rebuild acties).
Bij het lezen heb je dit probleem niet.

Vertraging met schrijven naar een journaling FS? OK, kan ik me in vinden. Maar we hebben het hier over de write-snelheid van een gemiddelde FDD...

Bovendien gaat de snelheid fors omhoog als ik een ping doe, en dat heeft weinig met filesystem-performance van doen denk ik.

Verwijderd schreef op zaterdag 22 oktober 2005 @ 02:07:
hdparm aan?

Wat bedoel je daarmee? Mijn schijven draaien, zoals gezegd, al in DMA, dus volgens mij heb ik hdparm dan helemaal niet meer nodig. Ik gebruik het alleen even om te testen ofdat de schijven hun doorvoersnelheid wel halen en dat doen ze dus.
Mijn array zit op zo'n 85MB/s dus dat lijkt me niet de bottleneck.


Afijn, ik heb het min of meer opgelost door op de server een DNS-server te installeren (Bind9) en het probleem lijkt zo goed als opgelost. De write-performance is nu een stuk hoger, alhoewel ik het idee heb dat het allemaal nog veel beter kan.

Nog iets vreemds: schrijven gaat nu sneller dan lezen
Samba blijft op dit gebied toch wel erg gevoelig. Als ik met de search zoek op 'samba traag' dan krijg je erg veel topics met soortgelijke problemen.

Ik ben ervan overtuigd dat het aan Samba ligt, want lees- en schrijfacties tussen mijn 2 XP-bakken onderling gaat gewoon helemaal goed.

Misschien dat iemand met een optimaal werkende samba-server zijn conf eens kan posten?

[Nitroglycerine]

Hardware: p3 800 MHz met Promise PCI IDE controller. OS draait op een stripeset van 2 3GB schijfjes, data staat op 3 IDE schijven (160 en 2*20) die op de promise zijn aangesloten. OS = FC4.
De shares heb ik met LVM gedefinieerd.

code:

[global]
   workgroup = WERKGROEP
   server string = Filewall
   hosts allow = 192.168.0. 127.
   log file = /var/log/samba/%m.log
   max log size = 250
   security = user
   password level = 8
   username level = 6
   encrypt passwords = yes
   smb passwd file = /etc/samba/smbpasswd

   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
   interfaces = 192.168.0.1/24

   dns proxy = no
#============================ Share Definitions ==============================
   idmap uid = 16777216-33554431
   idmap gid = 16777216-33554431
   template shell = /bin/false
   winbind use default domain = no

[datashare]
   comment = Data share
   path = /samba/data/share
   valid users = abc def
   public = no
   writable = yes
   printable = no
   create mask = 0765

[muziek]
   comment = Muziek
   path = /samba/muziek/share
   public = no
   valid users = abc def
   read only = yes

[film]
   comment = Films
   path = /samba/film/share
   public = no
   valid users = abc def
   read only = yes

[input]
   comment = Muziek input
   path = /samba/input/input
   valid users = abc def
   public = no
   writable = yes
   printable = no
   create mask = 0775

[foto]
   comment = Digitale foto's
   path = /samba/foto/share
   valid users = abc def
   public = no
   writable = yes
   printable = no
   create mask = 0664

[Tachyon]

Nitroglycerine, wat voor snelheden (read en write) haal je met je systeem?

Ik heb de write performance nu onder controle door het installeren van de DNS-server, maar hierdoor is de read-speed weer verslechterd:



Het linkergedeelte is als de DNS-server draait, het rechter als ik hem uitzet. Dit is dus exact het tegenovergestelde van de write-speed. Hoe kan het toch dat die DNS-server zo'n invloed heeft? En waarom hij dan een gunstige invloed heeft op de write-speed, maar een ongunstige op de read-speed?

[Z-Dragon]

Misschien heb je iets aan dit verhaal, dat aansluit op je eigen theorie.

[cool_zero]

Samba heeft niets met dns te maken, dus als dit het probleem oplost dan zit dat probleem niet bij samba. Als ik zo de problemen zie dan ligt het waarschijnlijk aan de hardeschijf of aan de netwerkverbinding.(full duplex/half duplex probleem misschien?) Een handige manier om er zeker van te zijn dat het niet aan samba ligt is om gewoon even een ftp server erop te zetten.

[TD-er]

Kijk anders ook eens met NetIO wat er aan snelheid haalbaar is tussen je windows- en linux-bak.
Dus beide kanten op testen. Als dat al erg van elkaar verschilt (de richtingen) qua snelheid, dan zou je daar ook nog eens naar kunnen kijken.
Heb je je Linux-netwerkkaart al eens geforceerd op 100 Mbit (bijv een switch ertussen hangen) en zodoende een lees- en schrijfsnelheid van zo'n 9 a 10 MB/s kunnen halen?

Staan alle windows-updates erop? indien ja, dan kan het daar ook aan liggen. Laatst was er namelijk een update die problemen op dit gebied zou kunnen veroorzaken.

[Wilke]

Verwijderd schreef op zaterdag 22 oktober 2005 @ 02:07:
hdparm aan?

Lees de topicstart, etc...

[pinockio]

Hoe benader je je samba-bak? \\ip-adres\share of \\naam\share?
Soms is het gewoon slim in het hosts-bestand van XP bakken de server hard te coden:

192.168.0.1 samba-server (of iets dergelijks)

En: heb je een mapped network drive? Het werkt in mijn ervaring bij XP beter om niet te rechts-klikken op een share en dan 'netwerkverbinding maken' te kiezen maar het ouderwets te doen met een logon script.
Zet bijv. dit in je opstart-map: een netuse.bat file waarin staat:

net use x: \\samba-server\share password /persistent:no

Hierdoor krijg je bijv. al een snellere weergaven van je schijven in de verkenner. Of het scheelt voor write-performance? Probeer het uit zou ik zeggen.

Ik heb een Debian samba-servertje draaien (kernel 2.4, Celeron 333, 7200 toeren harddisk) waarmee ik 8.7 megabyt/s haal (lezen of schrijven). De bottleneck is hierbij denk ik de udma-controller van het mobo...

[Tachyon]

cool_zero schreef op zaterdag 22 oktober 2005 @ 17:06:
Samba heeft niets met dns te maken, dus als dit het probleem oplost dan zit dat probleem niet bij samba. Als ik zo de problemen zie dan ligt het waarschijnlijk aan de hardeschijf of aan de netwerkverbinding.(full duplex/half duplex probleem misschien?)

Samba heeft opzich inderdaad vrij weinig met DNS te maken, maar heeft wel een goed werkende DNS/resolving nodig. Het begint er op te lijken dat het niet Samba zelf, maar een ander onderliggend probleem is. Problemen met de harde schijf sluit ik uit, want dan zouden alle drie de schijven in de server er last van moeten hebben
En de netwerkkaarten draaien ook op full-duplex. Nog even de output van hdparm:

code:

root@holodeck1:/media/hda3# hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   2244 MB in  2.00 seconds = 1121.61 MB/sec
 Timing buffered disk reads:  164 MB in  3.01 seconds =  54.46 MB/sec

root@holodeck1:/media/hda3# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   2208 MB in  2.00 seconds = 1103.06 MB/sec
 Timing buffered disk reads:  186 MB in  3.03 seconds =  61.46 MB/sec

root@holodeck1:/media/hda3# hdparm -tT /dev/md0

/dev/md0:
 Timing cached reads:   2224 MB in  2.00 seconds = 1109.95 MB/sec
 Timing buffered disk reads:  278 MB in  3.02 seconds =  92.01 MB/sec

TD-er schreef op zaterdag 22 oktober 2005 @ 17:18:
Kijk anders ook eens met NetIO wat er aan snelheid haalbaar is tussen je windows- en linux-bak.
Dus beide kanten op testen. Als dat al erg van elkaar verschilt (de richtingen) qua snelheid, dan zou je daar ook nog eens naar kunnen kijken.

Output van NetIO, beide kanten op:

code:

C:\NETIO\bin>nt -t 10.0.0.101

NETIO - Network Throughput Benchmark, Version 1.14
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size  1 KByte:   34456 KByte/s
Packet size  2 KByte:   40872 KByte/s
Packet size  4 KByte:   46136 KByte/s
Packet size  8 KByte:   46064 KByte/s
Packet size 16 KByte:   65794 KByte/s
Packet size 32 KByte:   80258 KByte/s

Van XP naar Samba-server.

code:

root@holodeck1:/media/hda3# ./linux -t 10.0.0.103

NETIO - Network Throughput Benchmark, Version 1.13
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size  1 k bytes:   70719 k bytes/sec
Packet size  2 k bytes:   71493 k bytes/sec
Packet size  4 k bytes:   71492 k bytes/sec
Packet size  8 k bytes:   71628 k bytes/sec
Packet size 16 k bytes:   71635 k bytes/sec
Packet size 32 k bytes:   71661 k bytes/sec

Van Samba-server naar XP.


Ziet er op zich toch goed uit? Op low-level niveau lijkt het wel in orde.

pinockio schreef op zaterdag 22 oktober 2005 @ 19:52:
Hoe benader je je samba-bak? \\ip-adres\share of \\naam\share?
Soms is het gewoon slim in het hosts-bestand van XP bakken de server hard te coden:

192.168.0.1 samba-server (of iets dergelijks)

En: heb je een mapped network drive? Het werkt in mijn ervaring bij XP beter om niet te rechts-klikken op een share en dan 'netwerkverbinding maken' te kiezen maar het ouderwets te doen met een logon script.
Zet bijv. dit in je opstart-map: een netuse.bat file waarin staat:

net use x: \\samba-server\share password /persistent:no

Hierdoor krijg je bijv. al een snellere weergaven van je schijven in de verkenner. Of het scheelt voor write-performance? Probeer het uit zou ik zeggen.

Ik benader alles op \\hostnaam\share. En dat werkt prima, dus je zou toch zeggen dat het hele resolving gebeuren gewoon werkt In mijn host-bestanden staan ook verwijzingen naar de diverse machines.

Het vreemde is dat het altijd prima gewerkt heeft, tot het moment dat ik die server opnieuw installeerde. Dus het moet bijna een configuratie fout zijn. Maar welke

Ik zit een beetje op een dood spoor en begin het eigenlijk wel beu te worden. Ik had nog liever dat het helemaal niet werkte dan half-half.

[Z-Dragon]

Kun je NetIO dan niet met DNS proberen?

Edit: hoe loopt het als je de config van Nitroglycerine 1:1 overneemt en alleen de shares aanpast? Hij defineert bijv. geen NetBIOS-naam. Ik weet niet of dat uitmaakt, maar NetBIOS zelf is een erg traag protocol. Bovenstaande dus a.u.b. even proberen.

[ Voor 89% gewijzigd door Z-Dragon op 22-10-2005 23:46 . Reden: Toevoeging ]

[Tachyon]

Ik heb Nitro's setup even geprobeerd. Maakt (bijna) niets uit. Ik heb op internet tientallen draadjes gelezen van mensen met exact hetzelfde probleem. Maar helaas eigenlijk nooit een oplossing

Telkens weer kom je dezelfde 'open deuren' tegen: het ligt aan je kabels, staat hdparm wel aan, draai je wel met full-duplex enz. enz.

Nog iets raars: als ik vanaf 2 verschillende machines een bestand kopieer naar de samba-server, dan zijn beide kopieeracties gewoon bloedsnel. Totdat 1 van de acties beeindigd is; dan stort de snelheid van de andere kopieeractie weer helemaal in. Als er een concurrente verbinding is gaat het dus goed.

Het is niet eens dat het 'gewoon' traag is, maar echt ridicuul traag: ik heb even gemeten met een bestand van 150MB en de doorvoersnelheid ligt op ongeveer 600KB/s....
Daar sta je dan met je Gigabit-netwerk; mijn internetverbinding is nog sneller...

Ter vergelijking: mijn gemeten read-speed ligt op ongeveer 22MB/s, bijna 37 x zo snel.

Er was 1 iemand die dit probleem ook had en het opgelost zag door zijn NIC te vervangen door een betere (Intel Pro 1000). Ik heb natuurlijk ook een el-cheapo NIC. (realtek 8169) Misschien is die toch wat buggy. Maar met zo'n Intel ben je toch al gauw weer een paar tientjes armer en dan weet ik nog niet of dat het uberhaupt wel zin heeft.

Wie een oplosing heeft krijgt een koekje...

Ik ga morgen ook maar eens een FTP-servertje opzetten, kijken wat dat oplevert.

[pinockio]

Heb je dit al geprobeerd?

Zet bijv. dit in je opstart-map: een netuse.bat file waarin staat:

net use x: \\samba-server\share password /persistent:no

Hierdoor krijg je bijv. al een snellere weergaven van je schijven in de verkenner. Of het scheelt voor write-performance? Probeer het uit zou ik zeggen.

Waarschijnlijk is het de combinatie van Windows XP en Samba. Het kan aan beide kanten liggen.

[cool_zero]

Als je de debuglevel omhoog zet van samba staan er dan oplock problemen in de log-files van samba?

[LinuX-TUX]

Ik heb exact dezelfde situatie hier. Terwijl ik nog steeds niet weet waaraan het ligt (kan ook realtek specifiek zijn hoor)

Workaround voor mij is met mii-tool m'n ethernet device op half duplex zetten en ik haal de snelheden van full duplex

mii-tool -F 100BaseTx-HD eth0

Nooit geprobeerd is altijd mis (hd -> werkt het nog niet? -> 1 tandje terug naar 100(FD/HD))

edit:

Je hebt je netwerk al op orde
Daar zou ik 123 geen antwoord op weten, waarom schrijven sneller is dan lezen

Maar dan nog, nooit geschoten is altijd mis

[ Voor 29% gewijzigd door LinuX-TUX op 24-10-2005 09:13 ]

[ShellGhost]

LinuX-TUX schreef op maandag 24 oktober 2005 @ 09:07:
Ik heb exact dezelfde situatie hier. Terwijl ik nog steeds niet weet waaraan het ligt (kan ook realtek specifiek zijn hoor)

Workaround voor mij is met mii-tool m'n ethernet device op half duplex zetten en ik haal de snelheden van full duplex

Ik wilde dit net gaan aanhalen.
Zet windows en debian is op half duplex ipv full.
Windows vind half duplex leuker dan full is mijn ervaring, vreemd genoeg.

[Tachyon]

pinockio schreef op maandag 24 oktober 2005 @ 08:05:
Heb je dit al geprobeerd?

Zet bijv. dit in je opstart-map: een netuse.bat file waarin staat:

net use x: \\samba-server\share password /persistent:no

Hierdoor krijg je bijv. al een snellere weergaven van je schijven in de verkenner. Of het scheelt voor write-performance? Probeer het uit zou ik zeggen.

Waarschijnlijk is het de combinatie van Windows XP en Samba. Het kan aan beide kanten liggen.

Dit heb ik ook al geprobeerd, maar dat maakt niets uit. Sowieso is het browsen door mijn netwerkomgeving gewoon snel. Maar toch bedankt voor de tip

cool_zero schreef op maandag 24 oktober 2005 @ 08:57:
Als je de debuglevel omhoog zet van samba staan er dan oplock problemen in de log-files van samba?

log-level staat nu op 6, maar er staan nog steeds geen foutmeldingen of anderssoortige rare zaken in de logs. Het ziet er allemaal goed uit

LinuX-TUX schreef op maandag 24 oktober 2005 @ 09:07:
Ik heb exact dezelfde situatie hier. Terwijl ik nog steeds niet weet waaraan het ligt (kan ook realtek specifiek zijn hoor)

Workaround voor mij is met mii-tool m'n ethernet device op half duplex zetten en ik haal de snelheden van full duplex

mii-tool -F 100BaseTx-HD eth0

Nooit geprobeerd is altijd mis (hd -> werkt het nog niet? -> 1 tandje terug naar 100(FD/HD))

Ik weet niet waar het aan ligt, maar elke optie die ik probeer met mii-tool geeft als resultaat "Operation not supported"

Maar ik heb wel de duplex-settings van mijn XP-bak kunnen aanpassen. Helaas kan ik niet kiezen voor 1000Mbps half-duplex, want die optie staat er niet bij. Als ik 100Mbps half-duplex selekteer krijg ik in ieder geval wel 'normale resultaten' die bij die verbinding horen. De write-speed is dan zo'n 3MB/s. Nog steeds niet geweldig, maar al wel vele malen beter dan die 600KB/s. Het vreemde is dat als ik vervolgens 100Mbps full-duplex selecteer voor de verbinding van die XP-bak, dat dan read-speed weer helemaal instort....

Ik ga die realtek er maar eens even uithalen en kijken hoe de ingebouwde netwerkkaart van de server zich gedraagt. Het lijkt er een beetje op dat full-duplex inderdaad niet helemaal goed werkt in de combinatie debian/realtek/XP. want tussen mijn beide XP-bakken draait gewoon een bloedsnelle 1Gbps full-duplex verbinding, zowel voor lezen als voor schrijven.

edit:
De samba-bak draait nu met de ingebouwde netwerkkaart (overigens ook een Realtek... ) in 100baseTx-FD en mijn XP-bak op 1000Mbps FD. Zowel de read- als de writespeed zitten nu op hun verwachte niveau en zijn exact aan elkaar gelijk, namelijk zo'n 9,8MB/s Op zich een prima snelheid voor een 100Mbit-verbinding.

Het lijkt er een beetje op dat de 8169 toch de boosdoener was en gewoon niet in staat is om op een normale manier zonder kunstgrepen de 1000Mbps FD te halen.

Ik ga toch maar een Intel 1Gbps Pro halen, want ik heb natuurlijk niet voor niks een Gbit-netwerk liggen.

[ Voor 12% gewijzigd door Tachyon op 24-10-2005 15:12 . Reden: Nieuwe info ]