May 16, 2013
Samba, like any other program can use a little speed boost. You want to get the most out of your machines and optimizing your applications can extend their life by doing the job longer.
Samba needs to be tuned to your network because every enviorment offers its own unique set of challenges. Here is a collection of hints and tricks from our professional experiences and from the Samba group.
The socket options configuration options are really host system tuning options, but they're set on a per-connection basis, and can be reset by Samba on the sockets it employs by adding socket options = option to the [global] section of your smb.conf file. This single line can gain you a 200% throughput increase over default settings.
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
TCP_NODELAY tells the server to send as many packets as necessary to keep delay low. This will account for a 30 percent speedup by itself. In Samba 2.0 socket options = TCP_NODELAY became the default value.
IPTOS_LOWDELAY is another option trading off throughput for lower delay, but which affects routers and other systems, not the server. All the IPTOS options are new; they're not supported by all operating systems and routers though. If they are supported, set IPTOS_LOWDELAY whenever you set TCP_NODELAY. This option gives us a minor speed up around 20%.
SO_SNDBUF and SO_RCVBUF The send and receive buffers can often be the reset to a value higher than that of the operating system. This yields a marginal increase of speed until it reaches a point of diminishing returns. For a modern OpenBSD box serving shares to Windows xp/Vista or Linux machines a SO_SNDBUF and SO_RCVBUF of 65536 increased throughput by as much as 20% by itself.
SO_KEEPALIVE initiates a periodic check every four(4) hours to see if the client is still there. This option eventually arranges to close dead connections, returning unused memory and process-table entries to the operating system. Using this option is conjunction with "deadtime = 15" to close idle connection as fast as your working environment will allow.
These are important performance configuration options; they enable Samba to use large reads and writes to the network, of up to 64KB in a single SMB request. They also require the largest SMB packet structures, SMBreadraw and SMBwriteraw, from which the options take their names. In the past, some clients failed if you tried to use read raw. No clients suffer from this problem now. Read and write raw default to yes, and should be left on unless you find you have one of the ancient buggy clients.
Opportunistic locks, or oplocks, allow clients to cache files locally, improving performance on the order of 30 percent. This option is now enabled by default. For read-only files, the fake oplocks provides the same functionality without actually doing any caching. If you have files that cannot be cached, oplocks can be turned off. Database files should never be cached, nor should any files that are updated both on the server and the client and whose changes must be immediately visible. For these files, the veto oplock files option allows you to specify a list of individual files or a pattern containing wild cards to avoid caching. oplocks can be turned off on a share-by-share basis if you have large groups of files you don't want cached on clients.
Samba produces a lot of debugging messages at level 3 and above, and writing them to disk or syslog is a slow operation. Much of the disk I/O would be wasted on debugging messages. Reduce the logging level to 2 or under.
The following Samba options will affect performance if they are not set correctly.
hide files provide a pattern to identify files hidden by the Windows client hide files will result in any file matching the pattern being passed to the client with the DOS hidden attribute set. It requires a pattern match per file when listing directories, and slows the server noticeably.
lpq cache time is used if your lpq (printer queue contents) command takes a long time to complete, you should increase lpq cache time to a value higher than the actual time required for lpq to execute, so as to keep Samba from starting a new query when one's already running. The default is 10 seconds, which is reasonable.
strict locking sets the strict locking option and causes Samba to check for locks on every access, not just when asked to by the client. The option is primarily a bug-avoidance feature, and can prevent ill-behaved DOS and Windows applications from corrupting shared files. However, it is slow and should typically be avoided.
strict sync sets strict sync and will cause Samba to write each packet to disk and wait for the write to complete whenever the client sets the sync bit in a packet. Windows 98 Explorer sets the bit in all packets transmitted, so if you turn this on, anyone with Windows 98 will think Samba servers are horribly slow.
sync always us used to "sync always" and causes Samba to flush every write to disk. This is good if your server crashes constantly, but the performance costs are immense. SMB servers normally use oplocks and automatic reconnection to avoid the ill effects of crashes, so setting this option is not normally necessary.
wide links acts by turning off wide links prevents Samba from following symbolic links in one file share to files that are not in the share. It is turned on by default, since following links in Unix is not a security problem. Turning it off requires extra processing on every file open. If you do turn off wide links, be sure to turn on getwd cache to cache some of the required data. There is also a follow symlinks option that can be turned off to prevent following any symbolic links at all. However, this option does not pose a performance problem.
getwd cache option caches the path to the current directory, avoiding long tree-walks to discover it. It's a nice performance improvement on a printer server or if you've turned off wide links.
Can you tell me how to setup Samba?
Yes. Check out our Samba config "how to" ( smb.conf )
How can I watch the memory and disk I/O of the box?
You can use the binary "vmstat". It will show you the memory and disk access so you can better tune your system