Chapter 39. Samba Performance Tuning

Chapter 39. Samba Performance Tuning
Prev	Part VI. Appendixes	Next

Paul Cochrane

Dundee Limb Fitting Centre

<paulc@dth.scot.nhs.uk>

Jelmer R. Vernooij

The Samba Team

<jelmer@samba.org>

John H. Terpstra

Samba Team

<jht@samba.org>

Table of Contents

Comparisons
Socket options
Read size
Max xmit
Log level
Read raw
Write raw
Slow Logins
Client tuning
Samba performance problem due changing kernel
Corrupt tdb Files

Comparisons

+The Samba server uses TCP to talk to the client. Thus if you are +trying to see if it performs well you should really compare it to +programs that use the same protocol. The most readily available +programs for file transfer that use TCP are ftp or another TCP based +SMB server. +

+If you want to test against something like a NT or WfWg server then +you will have to disable all but TCP on either the client or +server. Otherwise you may well be using a totally different protocol +(such as NetBEUI) and comparisons may not be valid. +

+Generally you should find that Samba performs similarly to ftp at raw +transfer speed. It should perform quite a bit faster than NFS, +although this very much depends on your system. +

+Several people have done comparisons between Samba and Novell, NFS or +WinNT. In some cases Samba performed the best, in others the worst. I +suspect the biggest factor is not Samba vs some other system but the +hardware and drivers used on the various systems. Given similar +hardware Samba should certainly be competitive in speed with other +systems. +

Socket options

+There are a number of socket options that can greatly affect the +performance of a TCP based server like Samba. +

+The socket options that Samba uses are settable both on the command +line with the -O option, or in the smb.conf file. +

+The socket options section of the smb.conf manual page describes how +to set these and gives recommendations. +

+Getting the socket options right can make a big difference to your +performance, but getting them wrong can degrade it by just as +much. The correct settings are very dependent on your local network. +

+The socket option TCP_NODELAY is the one that seems to make the +biggest single difference for most networks. Many people report that +adding socket options = TCP_NODELAY doubles the read +performance of a Samba drive. The best explanation I have seen for this is +that the Microsoft TCP/IP stack is slow in sending tcp ACKs. +

Read size

+The option read size affects the overlap of disk +reads/writes with network reads/writes. If the amount of data being +transferred in several of the SMB commands (currently SMBwrite, SMBwriteX and +SMBreadbraw) is larger than this value then the server begins writing +the data before it has received the whole packet from the network, or +in the case of SMBreadbraw, it begins writing to the network before +all the data has been read from disk. +

+This overlapping works best when the speeds of disk and network access +are similar, having very little effect when the speed of one is much +greater than the other. +

+The default value is 16384, but very little experimentation has been +done yet to determine the optimal value, and it is likely that the best +value will vary greatly between systems anyway. A value over 65536 is +pointless and will cause you to allocate memory unnecessarily. +

Max xmit

+ At startup the client and server negotiate a maximum transmit size, +which limits the size of nearly all SMB commands. You can set the +maximum size that Samba will negotiate using the max xmit option +in smb.conf. Note that this is the maximum size of SMB requests that +Samba will accept, but not the maximum size that the *client* will accept. +The client maximum receive size is sent to Samba by the client and Samba +honours this limit. +

+It defaults to 65536 bytes (the maximum), but it is possible that some +clients may perform better with a smaller transmit unit. Trying values +of less than 2048 is likely to cause severe problems. +

+In most cases the default is the best option. +

Log level

+If you set the log level (also known as debug level) higher than 2 +then you may suffer a large drop in performance. This is because the +server flushes the log file after each operation, which can be very +expensive. +

Read raw

+The read raw operation is designed to be an optimised, low-latency +file read operation. A server may choose to not support it, +however. and Samba makes support for read raw optional, with it +being enabled by default. +

+In some cases clients don't handle read raw very well and actually +get lower performance using it than they get using the conventional +read operations. +

+So you might like to try read raw = no and see what happens on your +network. It might lower, raise or not affect your performance. Only +testing can really tell. +

Write raw

+The write raw operation is designed to be an optimised, low-latency +file write operation. A server may choose to not support it, +however. and Samba makes support for write raw optional, with it +being enabled by default. +

+Some machines may find write raw slower than normal write, in which +case you may wish to change this option. +

Slow Logins

+Slow logins are almost always due to the password checking time. Using +the lowest practical password level will improve things. +

Client tuning

+Often a speed problem can be traced to the client. The client (for +example Windows for Workgroups) can often be tuned for better TCP +performance. Check the sections on the various clients in +Samba and Other Clients. +

Samba performance problem due changing kernel

+Hi everyone. I am running Gentoo on my server and samba 2.2.8a. Recently +I changed kernel version from linux-2.4.19-gentoo-r10 to +linux-2.4.20-wolk4.0s. And now I have performance issue with samba. Ok +many of you will probably say that move to vanilla sources...well I tried +it too and it didn't work. I have 100mb LAN and two computers (linux + +Windows2000). Linux server shares directory with DivX files, client +(windows2000) plays them via LAN. Before when I was running 2.4.19 kernel +everything was fine, but now movies freezes and stops...I tried moving +files between server and Windows and it's terribly slow. +

+Grab mii-tool and check the duplex settings on the NIC. +My guess is that it is a link layer issue, not an application +layer problem. Also run ifconfig and verify that the framing +error, collisions, etc... look normal for ethernet. +

Corrupt tdb Files

+Well today it happened, Our first major problem using samba. +Our samba PDC server has been hosting 3 TB of data to our 500+ users +[Windows NT/XP] for the last 3 years using samba, no problem. +But today all shares went SLOW; very slow. Also the main smbd kept +spawning new processes so we had 1600+ running smbd's (normally we avg. 250). +It crashed the SUN E3500 cluster twice. After a lot of searching I +decided to rm /var/locks/*.tdb. Happy again. +

+Q1) Is there any method of keeping the *.tdb files in top condition or +how to early detect corruption? +

+A1) Yes, run tdbbackup each time after stopping nmbd and before starting nmbd. +

+Q2) What I also would like to mention is that the service latency seems +a lot lower then before the locks cleanup, any ideas on keeping it top notch? +

+A2) Yes! Same answer as for Q1! +

Prev	Up	Next
Chapter 38. Samba and other CIFS clients	Home	Chapter 40. DNS and DHCP Configuration Guide