1<?xml version="1.0" encoding="iso-8859-1"?> 2<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> 3<chapter id="speed"> 4 5<chapterinfo> 6 <author> 7 <firstname>Paul</firstname><surname>Cochrane</surname> 8 <affiliation> 9 <orgname>Dundee Limb Fitting Centre</orgname> 10 <address><email>paulc@dth.scot.nhs.uk</email></address> 11 </affiliation> 12 </author> 13 &author.jelmer; 14 &author.jht; 15</chapterinfo> 16 17<title>Samba Performance Tuning</title> 18 19<sect1> 20<title>Comparisons</title> 21 22<para> 23The Samba server uses TCP to talk to the client, so if you are 24trying to see if it performs well, you should really compare it to 25programs that use the same protocol. The most readily available 26programs for file transfer that use TCP are ftp or another TCP-based 27SMB server. 28</para> 29 30<para> 31If you want to test against something like an NT or Windows for Workgroups server, then 32you will have to disable all but TCP on either the client or 33server. Otherwise, you may well be using a totally different protocol 34(such as NetBEUI) and comparisons may not be valid. 35</para> 36 37<para> 38Generally, you should find that Samba performs similarly to ftp at raw 39transfer speed. It should perform quite a bit faster than NFS, 40although this depends on your system. 41</para> 42 43<para> 44Several people have done comparisons between Samba and Novell, NFS, or 45Windows NT. In some cases Samba performed the best, in others the worst. I 46suspect the biggest factor is not Samba versus some other system, but the 47hardware and drivers used on the various systems. Given similar 48hardware, Samba should certainly be competitive in speed with other 49systems. 50</para> 51 52</sect1> 53 54<sect1> 55<title>Socket Options</title> 56 57<para> 58There are a number of socket options that can greatly affect the 59performance of a TCP-based server like Samba. 60</para> 61 62<para> 63The socket options that Samba uses are settable both on the command 64line with the <option>-O</option> option and in the &smb.conf; file. 65</para> 66 67<para> 68The <smbconfoption name="socket options"/> section of the &smb.conf; manual page describes how 69to set these and gives recommendations. 70</para> 71 72<para> 73Getting the socket options correct can make a big difference to your 74performance, but getting them wrong can degrade it by just as 75much. The correct settings are very dependent on your local network. 76</para> 77 78<para> 79The socket option TCP_NODELAY is the one that seems to make the biggest single difference 80for most networks. Many people report that adding 81<smbconfoption name="socket options">TCP_NODELAY</smbconfoption> 82doubles the read performance of a Samba drive. The best explanation I have seen for 83this is that the Microsoft TCP/IP stack is slow in sending TCP ACKs. 84</para> 85 86<para> 87There have been reports that setting <parameter>socket options = SO_RCVBUF=8192</parameter> in smb.conf 88can seriously degrade Samba performance on the loopback adaptor (IP Address 127.0.0.1). It is strongly 89recommended that before specifying any settings for <parameter>socket options</parameter>, the effect 90first be quantitatively measured on the server being configured. 91</para> 92 93</sect1> 94 95<sect1> 96<title>Read Size</title> 97 98<para> 99The option <smbconfoption name="read size"/> affects the overlap of disk 100reads/writes with network reads/writes. If the amount of data being 101transferred in several of the SMB commands (currently SMBwrite, SMBwriteX, and 102SMBreadbraw) is larger than this value, then the server begins writing 103the data before it has received the whole packet from the network, or 104in the case of SMBreadbraw, it begins writing to the network before 105all the data has been read from disk. 106</para> 107 108<para> 109This overlapping works best when the speeds of disk and network access 110are similar, having little effect when the speed of one is much 111greater than the other. 112</para> 113 114<para> 115The default value is 16384, but little experimentation has been 116done as yet to determine the optimal value, and it is likely that the best 117value will vary greatly between systems anyway. A value over 65536 is 118pointless and will cause you to allocate memory unnecessarily. 119</para> 120 121</sect1> 122 123<sect1> 124<title>Max Xmit</title> 125 126<para> 127 At startup the client and server negotiate a <parameter>maximum transmit</parameter> size, 128which limits the size of nearly all SMB commands. You can set the 129maximum size that Samba will negotiate using the <smbconfoption name="max xmit"/> option 130in &smb.conf;. Note that this is the maximum size of SMB requests that 131Samba will accept, but not the maximum size that the client will accept. 132The client maximum receive size is sent to Samba by the client, and Samba 133honors this limit. 134</para> 135 136<para> 137It defaults to 65536 bytes (the maximum), but it is possible that some 138clients may perform better with a smaller transmit unit. Trying values 139of less than 2048 is likely to cause severe problems. 140In most cases the default is the best option. 141</para> 142 143</sect1> 144 145<sect1> 146<title>Log Level</title> 147 148<para> 149If you set the log level (also known as <smbconfoption name="debug level"/>) higher than 2, 150then you may suffer a large drop in performance. This is because the 151server flushes the log file after each operation, which can be quite 152expensive. 153</para> 154</sect1> 155 156<sect1> 157<title>Read Raw</title> 158 159<para> 160The <smbconfoption name="read raw"/> operation is designed to be an optimized, low-latency 161file read operation. A server may choose to not support it, 162however, and Samba makes support for <smbconfoption name="read raw"/> optional, with it 163being enabled by default. 164</para> 165 166<para> 167In some cases clients do not handle <smbconfoption name="read raw"/> very well and actually 168get lower performance using it than they get using the conventional 169read operations, so you might like to try <smbconfoption name="read raw">no</smbconfoption> and see what happens on your 170network. It might lower, raise, or not affect your performance. Only 171testing can really tell. 172</para> 173 174</sect1> 175 176<sect1> 177<title>Write Raw</title> 178 179<para> 180The <smbconfoption name="write raw"/> operation is designed to be an optimized, low-latency 181file write operation. A server may choose to not support it, however, and Samba makes support for 182<smbconfoption name="write raw"/> optional, with it being enabled by default. 183</para> 184 185<para> 186Some machines may find <smbconfoption name="write raw"/> slower than normal write, in which 187case you may wish to change this option. 188</para> 189 190</sect1> 191 192<sect1> 193<title>Slow Logins</title> 194 195<para> 196Slow logins are almost always due to the password checking time. Using 197the lowest practical <smbconfoption name="password level"/> will improve things. 198</para> 199 200</sect1> 201 202<sect1> 203<title>Client Tuning</title> 204 205<para> 206Often a speed problem can be traced to the client. The client (for 207example Windows for Workgroups) can often be tuned for better TCP 208performance. Check the sections on the various clients in 209<link linkend="Other-Clients">Samba and Other CIFS Clients</link>. 210</para> 211 212</sect1> 213 214<sect1> 215<title>Samba Performance Problem Due to Changing Linux Kernel</title> 216 217<para> 218A user wrote the following to the mailing list: 219</para> 220 221<blockquote> 222<para> 223<indexterm><primary>Gentoo</primary></indexterm> 224<indexterm><primary>slow network</primary></indexterm> 225I am running Gentoo on my server and Samba 2.2.8a. Recently I changed kernel versions from 226<filename>linux-2.4.19-gentoo-r10</filename> to <filename>linux-2.4.20-wolk4.0s</filename>. Now I have a 227performance issue with Samba. Many of you will probably say, <quote>Move to vanilla sources!</quote> Well, I 228tried that and it didn't work. I have a 100MB LAN and two computers (Linux and Windows 2000). The Linux server 229shares directories with DivX files, the client (Windows 2000) plays them via LAN. Before, when I was running 230the 2.4.19 kernel, everything was fine, but now movies freeze and stop. I tried moving files between the 231server and Windows, and it is terribly slow. 232</para> 233</blockquote> 234 235<para> 236The answer he was given is: 237</para> 238 239<blockquote> 240<para> 241<indexterm><primary>ifconfig</primary></indexterm> 242<indexterm><primary>framing error</primary></indexterm> 243<indexterm><primary>collisions</primary></indexterm> 244Grab the mii-tool and check the duplex settings on the NIC. My guess is that it is a link layer issue, not an 245application layer problem. Also run ifconfig and verify that the framing error, collisions, and so on, look 246normal for ethernet. 247</para> 248</blockquote> 249 250</sect1> 251 252<sect1> 253<title>Corrupt tdb Files</title> 254 255<para> 256<indexterm><primary>PDC</primary></indexterm> 257<indexterm><primary>mbd kept spawning</primary></indexterm> 258<indexterm><primary>/var/locks/*.tdb</primary></indexterm> 259Our Samba PDC server has been hosting three TB of data to our 500+ users [Windows NT/XP] for the last three 260years using Samba without a problem. Today all shares went very slow. Also, the main smbd kept spawning new 261processes, so we had 1600+ running SMDB's (normally we average 250). It crashed the SUN E3500 cluster twice. 262After a lot of searching, I decided to <command>rm /var/locks/*.tdb</command>. Happy again. 263</para> 264 265<para> 266<emphasis>Question:</emphasis> Is there any method of keeping the *.tdb files in top condition, or 267how can I detect early corruption? 268</para> 269 270<para> 271<indexterm><primary>tdbbackup</primary></indexterm> 272<indexterm><primary>nmbd</primary></indexterm> 273<emphasis>Answer:</emphasis> Yes, run <command>tdbbackup</command> each time after stopping nmbd and before starting nmbd. 274</para> 275 276<para> 277<emphasis>Question:</emphasis> What I also would like to mention is that the service latency seems 278a lot lower than before the locks cleanup. Any ideas on keeping it top notch? 279</para> 280 281<para> 282<emphasis>Answer:</emphasis> Yes. Same answer as for previous question! 283</para> 284 285</sect1> 286 287<sect1> 288<title>Samba Performance is Very Slow</title> 289 290<para> 291<indexterm><primary>slow performance</primary></indexterm> 292A site reported experiencing very baffling symptoms with MYOB Premier opening and 293accessing its data files. Some operations on the file would take between 40 and 29445 seconds. 295</para> 296 297<para> 298<indexterm><primary>printer monitor</primary></indexterm> 299<indexterm><primary>pauses</primary></indexterm> 300It turned out that the printer monitor program running on the Windows 301clients was causing the problems. From the logs, we saw activity coming 302through with pauses of about 1 second. 303</para> 304 305<para> 306<indexterm><primary>networks access</primary></indexterm> 307<indexterm><primary>printing now</primary></indexterm> 308Stopping the monitor software resulted in the networks access at normal 309(quick) speed. Restarting the program caused the speed to slow down 310again. The printer was a Canon LBP-810 and the relevant task was 311something like CAPON (not sure on spelling). The monitor software 312displayed a "printing now" dialog on the client during printing. 313</para> 314 315<para> 316We discovered this by starting with a clean install of Windows and 317trying the application at every step of the installation of other software 318process (we had to do this many times). 319</para> 320 321<para> 322Moral of the story: Check everything (other software included)! 323</para> 324 325</sect1> 326 327</chapter> 328