| Intro | Install | Configure | Troubleshoot | Optimize | PDC | Security |
David Lechnyr <david@lechnyr.com>
Mon, 19 May 2003 09:25:08 -0700
The price one pays for pursuing any profession, or calling, is an intimate knowledge of its ugly side. -- James Baldwin
Opportunistic locking essentially means that the client is allowed to download and cache the file on their hard drive while making changes; if a second client wants to access the file, the first client receives a break and must sync the file back to the server. This can give significant performance gains in some cases; in others, some programs insist on syncing back the contents of the entire file for a single change.
Level1 Oplocks (aka just plain "oplocks") is another term for opportunistic locking.
Level2 Oplocks is a fancy way of saying that you are providing opportunistic locking for a file that will be treated as "read-only". Typically this is used on files that are read-only or on files that the client has no intention to write to (at least, not initially).
Kernel Oplocks are essentially a method that allows the Linux kernel to co-exist with Samba's oplocked files, although this is simplifying things a bit. SGI IRIX and Linux are the only two UNIXes that are oplock aware at the moment.
Unless your system supports kernel oplocks, you should disable oplocks if you are accessing the same files from both Unix/Linux and SMB clients. Regardless, oplocks should always be disabled if you are sharing a database file (e.g., Microsoft Access) between multiple clients, as any break the first client receives will result in the entire file needing to be sync'd (not just the single record), which will result in a noticable performance delay and, more likely, problems accessing the database in the first place. Notably, Microsoft Outlook's personal folders (*.pst) react very badly to oplocks. If in doubt, disable oplocks and tune your system from that point.
If client-side caching is desirable and reliable on your network, you will benefit from turning on oplocks. If your network is slow and/or unreliable, or you are sharing your files among other file sharing mechanisms (e.g., NFS) or across a WAN, or multiple people will be accessing the same files frequently, you probably will not benefit from the overhead of your client sending oplock breaks and will instead want to disable oplocks for the share.
Another factor to consider is the perceived performance of file access. If oplocks provide no measurable speed benefit on your network, it might not be worth the hassle of dealing with them.
You can disable oplocks on a per-share basis with the following:
oplocks = False
level2oplocks = False
Alternately, you could disable oplocks on a per-file basis within the share:
veto oplock files = /*.mdb/*.MDB/
If you're having problems with oplocks as evidenced by Samba's log entries, you may want to play it safe and disable oplocks and level2oplocks.
Socket options allow you to control the networking layer of your connection with your SMB clients, which
you can tune to optimal performance for your local network. Each local network is different, so there is no "hard and
fast" rule for this, so you'll have to do some experimenting. Reading up on socket options in general might not be a
bad idea as well (try man setsockopt).
A good way to determine what's best for you is to create both a single 100MB dummy file and 100 multiple 1MB dummy files and test the time involved in sending/receiving both the large file and small files to/from the server (not at the same time, of course). You'll want to make sure to stop and restart Samba each time, to prevent caching. By charting out different response times for SO_RCVBUF and SO_SNDBUF you can find the optimal value for your specific network. To create a single 100MB dummy test file and 100 multiple 1MB dummy files, you could simply use:
#!/bin/sh
# Create a single 100MB test file
dd if=/dev/zero of=testfile count=10240 bs=10240
# Create 100 multiple 1MB dummy files
count=1
until [ "$count" -gt 100 ]
do
let "count += 1"
dd if=/dev/zero of=testfile${count} count=1024 bs=1024
done
It is not necessary to make SO_RCVBUF an exact multiple of MTU or MSS to avoid performance degradation due to packet fragmentation, as is commonly claimed. This is just another urban myth ;-) With that said, you'll find the best performance gain by modifying the value for SO_RCVBUF to your particular network setting. For the curious, MTU is the size of the entire packet. MSS is the size of the payload. The header of a TCP packet is normally 40 bytes if there aren't any TCP options expanding the header.
Regardless, a good general starting point for you to try is:
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192After you've gathered your data, you'll want to chart it to find the optimal values for your specific setting.
It's worth noting that if you're filtering inbound traffic with a packet filter (such as iptables), you'll cause yourself quite a bit of a headache if you've been playing with Samba's socket options. Specifically, ICMP type 3 code 4 (Fragmentation Needed) should not be blocked. Otherwise, your server/client will be unable to negotiate a valid MTU window size. A good rule of thumb is to avoid blocking ICMP traffic while tuning your Samba server.
Log Level is a useful parameter for debugging, but when it is set higher than 2 you'll no doubt suffer a large penalty in performance. This is mainly due to the amount of information being logged, along with the sync command sent after each log file operation.
Wide Links tends to cause a performance penalty when turned off.
Read Raw and Write Raw tend to help or hinder depending on the client. Experimentation with these options will possibly prove enlightening.
Regardless of the tuning options you use, it's worth noting that one of the best means to measure and optimize Samba is to implement testing over a period of weeks or months to isolate trends. This reflects the real usage of the network and is almost impossible to beat in the information it reflects. Discovering the maximum amount of work that a server can perform is invaluable in combination with actual test results to help in determining what tuning options are actually beneficial to a system.
Copyright © 2003 David Lechnyr <david@lechnyr.com>
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free
Software Foundation. A copy of the license is available at http://www.gnu.org/licenses/fdl.txt.
| Intro | Install | Configure | Troubleshoot | Optimize | PDC | Security |