Samba/NFS traag vanaf linux client?

[Darkvater]

Ik heb net een fileserver geinstalleerd met daarop Samba shares en een RAID5 opstelling van 3 harde schijven.
Het vreemde is nu dat de performance van file transfers echt belachelijk traag is.

Als ik iets met SAMBA kopieer vanaf mijn linux bakkie haal ik ongeveer 150KB/s, met een NFS share ditto. Het maakt niet uit of het op die RAID5 schijven of gewoon / gaat, het is allemaal even langzaam.

De netwerk is goed aangezien een simpele wget van de andere PC's webserver met 6-7MB/s gaat. Ook de windows clients die naar de SAMBA share schrijven halen 6-7MB/s...alleen mijn linux client niet??

Het vreemdste is nog dat een WindowsXP op VMware op dezelfde linux pc *WEL* snelheden van 5MB/s haalt.

Wat is er nou fout en hoe kan ik dit oplossen?

[Darkvater]

Zelfs een SFTP connectie (vanuit konqueror) gaat met 6-7MB/s... ik snap het echt niet

[ph0t0nix]

Als je via Samba/NFS kopieert schiet je load dan omhoog? Geeft 'top' nog info die ons zou kunnen helpen?
Hoe loopt het als je op de fileserver zelf een van de directories via NFS mount (dus via localhost:/share of servername:/share)?
Of als je op de server zelf via Samba een van z'n eigen shares mount?
Gebruiken client en server wel dezelfde NFS/Samba versie?
Staat er misschien info in '/var/log/messages' of '/var/log/syslog' waar je iets wijzer van wordt? Of de samba log files?

[Darkvater]

ph0t0nix schreef op dinsdag 05 februari 2008 @ 13:31:
Als je via Samba/NFS kopieert schiet je load dan omhoog? Geeft 'top' nog info die ons zou kunnen helpen?

Nee, CPU load komt amper boven de 1-2% uit voor het systeem. Dit was ook te verwachten aangezien kopieren vanaf windows clients *wel* snel gaat

ph0t0nix schreef op dinsdag 05 februari 2008 @ 13:31:Hoe loopt het als je op de fileserver zelf een van de directories via NFS mount (dus via localhost:/share of servername:/share)?
Of als je op de server zelf via Samba een van z'n eigen shares mount?

Nee, geen verschil...

ph0t0nix schreef op dinsdag 05 februari 2008 @ 13:31:Gebruiken client en server wel dezelfde NFS/Samba versie?

Ja, beiden zijn versie 3.0.26a-3.5-1616-SUSE-SL10.3, alhoewel de min x86_64 is en de server 32 bits.

ph0t0nix schreef op dinsdag 05 februari 2008 @ 13:31:Staat er misschien info in '/var/log/messages' of '/var/log/syslog' waar je iets wijzer van wordt? Of de samba log files?

Nee, helemaal niks, het enige wat ik heb is dat er een connectie gemaakt is het volgende (zie hieronder). Ik heb nog even log level 3 aangezet maar kon niks zien wat op een of andere error wees.

code:

[2008/02/12 13:11:21, 1] smbd/service.c:make_connection_snum(1033)
  arrakis (192.168.1.100) connect to service raid initially as user nobody (uid=65534, gid=65533) (pid 8923)

Ik snap er geen bal van . Sorry voor de late antwoord maar ik was een paar daagjes onverwacht weg.

[Darkvater]

Ik heb nog gespeeld met Samba en heb wat vooruitgang geboekt, alhoewel ik niet weet waardoor het komt.

NFS performance is nog steeds crappy 1.1MB/s, maar dat boeit me niet zo
Lezen met samba vanaf de RAID5 gaat met 5.8MB/s, acceptabel dus. Als ik lokaal via samba mount en een lokale kopie doe haal ik 8.9MB/s. Een lokale kopie zonder samba is 10.5MB/s. Dit is dus allemaal lezen vanaf de RAID5.

Schrijven is nog steeds vreselijk. Een normale schrijf-actie gaat met zo'n 600KB/s over het netwerk en lokaal met 5.8MB/s. Een lokale kopie naar de RAID is 6.1MB/s

Het is goed mogelijk dat lokale lees/schrijf-acties zo langzaam zijn omdat linux zelf ook op een van die RAID5 schijven draait. Maar dat is helemaal geen reden om maar 600KB/s te halen tijdens een SAMBA kopie, terwijl windows wel in staat is om hoge snelheden te halen

Heeft iemand nog enige ideeen? Mijn smb.conf is het volgende:

code:

[global]
        server string = %h - Samba Server
        netbios name = Solaris
        workgroup = HOMELAN
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        use client driver = no
        map to guest = Bad User
        include = /etc/samba/dhcp.conf
        #logon path = \\%L\profiles\.msprofile
        #logon home = \\%L\%U\.9xprofile
        logon drive = H:
        logon script = login.vbs
        usershare allow guests = Yes
        add machine script = /usr/sbin/useradd  -c Machine -d /var/lib/nobody -s /bin/false %m$
        domain logons = Yes
        domain master = Yes
        local master = Yes
        os level = 65
        preferred master = Yes
        security = user
        hide unreadable = yes
        hide dot files = yes
        hide files = /desktop.ini/ntuser.ini/NTUSER.*/?humbs.db/
        socket options = TCP_NODELAY SO_SNDBUF=32768 SO_RCVBUF=32768
[homes]
       comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes

[freggy]

Probeer eens die socket options weg te halen, die zijn achterhaald met Linux 2.6.

Verder, mount je het als smbfs of als cifs? cifs is normaal moderner en de te verkiezen versie.

[eghie]

freggy schreef op dinsdag 19 februari 2008 @ 09:21:
Probeer eens die socket options weg te halen, die zijn achterhaald met Linux 2.6.

Verder, mount je het als smbfs of als cifs? cifs is normaal moderner en de te verkiezen versie.

TCP_NODELAY is niet achterhaald en ook gewenst. De send en recieve buffer instellingen wel ja. Het is zelfs zo, dat ze je verbinding kunnen vertragen, aangezien ze de send en recieve buffer tuning in de weg zitten. Laat alleen de nodelay in de socket options staan.

Er van uit gaande dat het netwerk een 100mbit netwerk is. Probeer dit eens in je /etc/sysctl.conf te stoppen:

code:

# See: http://dsd.lbl.gov/TCP-tuning/linux.html
# increase TCP max buffer size setable using setsockopt()
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
# set max to at least 4MB, or higher if you use very high BDP paths
net.ipv4.tcp_rmem = 4096 87380 16777216 
net.ipv4.tcp_wmem = 4096 65536 16777216

# don't cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
# recommended to increase this for 1000 BT or higher
net.core.netdev_max_backlog = 2500
# for 10 GigE, use this
# net.core.netdev_max_backlog = 30000

en dan het commando sysctl -p draaien. Misschien eventueel opnieuw opstarten. Alleen zou dit wel kunnen uitmaken, maar dan zou SFTP en WGET ook sneller gaan en dit lost niet het probleem op dat Samba en NFS traag zijn.

Wat staat er in exports en hoe mount je je NFS? Mount je de Samba share met smbfs of met cifs? En welke mount opties gebruik je?

Probeer NFS4 ook eens.

[Darkvater]

Ik heb een cifs mount (//solaris/raid on /tmp/bla type cifs (rw,mand)) gedaan voor de benchmark in mijn vorige post, maar normaal gezegd ga ik vanuit Konqueror gewoon naar smb://solaris/raid, geen idee hoe dat gemount wordt.

In /etc/exports voor NFS stond gewoon "/home/archives *(ro)" en een simpele mount ala "mount solaris:/home/archives tmp". Met wget haal ik trouwens ook gewoon 6MB/s

Dank je wel eghie heb die sysctl gedaan, ja 100mbit network, maar het heeft niet geholpen, alsmede de send/receive buffer aangepast in smb.conf.