5 <firstname>Paul</firstname><surname>Cochrane</surname>
7 <orgname>Dundee Limb Fitting Centre</orgname>
8 <address><email>paulc@dth.scot.nhs.uk</email></address>
14 <title>Samba performance issues</title>
17 <title>Comparisons</title>
20 The Samba server uses TCP to talk to the client. Thus if you are
21 trying to see if it performs well you should really compare it to
22 programs that use the same protocol. The most readily available
23 programs for file transfer that use TCP are ftp or another TCP based
28 If you want to test against something like a NT or WfWg server then
29 you will have to disable all but TCP on either the client or
30 server. Otherwise you may well be using a totally different protocol
31 (such as Netbeui) and comparisons may not be valid.
35 Generally you should find that Samba performs similarly to ftp at raw
36 transfer speed. It should perform quite a bit faster than NFS,
37 although this very much depends on your system.
41 Several people have done comparisons between Samba and Novell, NFS or
42 WinNT. In some cases Samba performed the best, in others the worst. I
43 suspect the biggest factor is not Samba vs some other system but the
44 hardware and drivers used on the various systems. Given similar
45 hardware Samba should certainly be competitive in speed with other
52 <title>Socket options</title>
55 There are a number of socket options that can greatly affect the
56 performance of a TCP based server like Samba.
60 The socket options that Samba uses are settable both on the command
61 line with the -O option, or in the smb.conf file.
65 The <command>socket options</command> section of the &smb.conf; manual page describes how
66 to set these and gives recommendations.
70 Getting the socket options right can make a big difference to your
71 performance, but getting them wrong can degrade it by just as
72 much. The correct settings are very dependent on your local network.
76 The socket option TCP_NODELAY is the one that seems to make the
77 biggest single difference for most networks. Many people report that
78 adding <command>socket options = TCP_NODELAY</command> doubles the read
79 performance of a Samba drive. The best explanation I have seen for this is
80 that the Microsoft TCP/IP stack is slow in sending tcp ACKs.
86 <title>Read size</title>
89 The option <command>read size</command> affects the overlap of disk
90 reads/writes with network reads/writes. If the amount of data being
91 transferred in several of the SMB commands (currently SMBwrite, SMBwriteX and
92 SMBreadbraw) is larger than this value then the server begins writing
93 the data before it has received the whole packet from the network, or
94 in the case of SMBreadbraw, it begins writing to the network before
95 all the data has been read from disk.
99 This overlapping works best when the speeds of disk and network access
100 are similar, having very little effect when the speed of one is much
101 greater than the other.
105 The default value is 16384, but very little experimentation has been
106 done yet to determine the optimal value, and it is likely that the best
107 value will vary greatly between systems anyway. A value over 65536 is
108 pointless and will cause you to allocate memory unnecessarily.
114 <title>Max xmit</title>
117 At startup the client and server negotiate a <command>maximum transmit</command> size,
118 which limits the size of nearly all SMB commands. You can set the
119 maximum size that Samba will negotiate using the <command>max xmit = </command> option
120 in &smb.conf;. Note that this is the maximum size of SMB requests that
121 Samba will accept, but not the maximum size that the *client* will accept.
122 The client maximum receive size is sent to Samba by the client and Samba
127 It defaults to 65536 bytes (the maximum), but it is possible that some
128 clients may perform better with a smaller transmit unit. Trying values
129 of less than 2048 is likely to cause severe problems.
133 In most cases the default is the best option.
139 <title>Log level</title>
142 If you set the log level (also known as <command>debug level</command>) higher than 2
143 then you may suffer a large drop in performance. This is because the
144 server flushes the log file after each operation, which can be very
150 <title>Read raw</title>
153 The <command>read raw</command> operation is designed to be an optimised, low-latency
154 file read operation. A server may choose to not support it,
155 however. and Samba makes support for <command>read raw</command> optional, with it
156 being enabled by default.
160 In some cases clients don't handle <command>read raw</command> very well and actually
161 get lower performance using it than they get using the conventional
166 So you might like to try <command>read raw = no</command> and see what happens on your
167 network. It might lower, raise or not affect your performance. Only
168 testing can really tell.
174 <title>Write raw</title>
177 The <command>write raw</command> operation is designed to be an optimised, low-latency
178 file write operation. A server may choose to not support it,
179 however. and Samba makes support for <command>write raw</command> optional, with it
180 being enabled by default.
184 Some machines may find <command>write raw</command> slower than normal write, in which
185 case you may wish to change this option.
191 <title>Slow Logins</title>
194 Slow logins are almost always due to the password checking time. Using
195 the lowest practical <command>password level</command> will improve things.
203 LDAP can be vastly improved by using the
204 <ulink url="smb.conf.5.html#LDAPTRUSTIDS">ldap trust ids</ulink> parameter.
211 <title>Client tuning</title>
214 Often a speed problem can be traced to the client. The client (for
215 example Windows for Workgroups) can often be tuned for better TCP
216 performance. Check the sections on the various clients in
217 <link linkend="Other-Clients">Samba and Other Clients</link>.
git.samba.org / samba.git / blob