diff options
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml')
| -rw-r--r-- | docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml | 327 |
1 files changed, 327 insertions, 0 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml new file mode 100644 index 0000000000..18a15ae092 --- /dev/null +++ b/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml @@ -0,0 +1,327 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<chapter id="speed"> + +<chapterinfo> + <author> + <firstname>Paul</firstname><surname>Cochrane</surname> + <affiliation> + <orgname>Dundee Limb Fitting Centre</orgname> + <address><email>paulc@dth.scot.nhs.uk</email></address> + </affiliation> + </author> + &author.jelmer; + &author.jht; +</chapterinfo> + +<title>Samba Performance Tuning</title> + +<sect1> +<title>Comparisons</title> + +<para> +The Samba server uses TCP to talk to the client, so 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. +</para> + +<para> +If you want to test against something like an NT or Windows for Workgroups 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. +</para> + +<para> +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 depends on your system. +</para> + +<para> +Several people have done comparisons between Samba and Novell, NFS, or +Windows NT. In some cases Samba performed the best, in others the worst. I +suspect the biggest factor is not Samba versus 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. +</para> + +</sect1> + +<sect1> +<title>Socket Options</title> + +<para> +There are a number of socket options that can greatly affect the +performance of a TCP-based server like Samba. +</para> + +<para> +The socket options that Samba uses are settable both on the command +line with the <option>-O</option> option and in the &smb.conf; file. +</para> + +<para> +The <smbconfoption name="socket options"/> section of the &smb.conf; manual page describes how +to set these and gives recommendations. +</para> + +<para> +Getting the socket options correct 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. +</para> + +<para> +The socket option TCP_NODELAY is the one that seems to make the biggest single difference +for most networks. Many people report that adding +<smbconfoption name="socket options">TCP_NODELAY</smbconfoption> +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. +</para> + +<para> +There have been reports that setting <parameter>socket options = SO_RCVBUF=8192</parameter> in smb.conf +can seriously degrade Samba performance on the loopback adaptor (IP Address 127.0.0.1). It is strongly +recommended that before specifying any settings for <parameter>socket options</parameter>, the effect +first be quantitatively measured on the server being configured. +</para> + +</sect1> + +<sect1> +<title>Read Size</title> + +<para> +The option <smbconfoption name="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. +</para> + +<para> +This overlapping works best when the speeds of disk and network access +are similar, having little effect when the speed of one is much +greater than the other. +</para> + +<para> +The default value is 16384, but little experimentation has been +done as 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. +</para> + +</sect1> + +<sect1> +<title>Max Xmit</title> + +<para> + At startup the client and server negotiate a <parameter>maximum transmit</parameter> size, +which limits the size of nearly all SMB commands. You can set the +maximum size that Samba will negotiate using the <smbconfoption name="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 +honors this limit. +</para> + +<para> +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. +</para> + +</sect1> + +<sect1> +<title>Log Level</title> + +<para> +If you set the log level (also known as <smbconfoption name="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 quite +expensive. +</para> +</sect1> + +<sect1> +<title>Read Raw</title> + +<para> +The <smbconfoption name="read raw"/> operation is designed to be an optimized, low-latency +file read operation. A server may choose to not support it, +however, and Samba makes support for <smbconfoption name="read raw"/> optional, with it +being enabled by default. +</para> + +<para> +In some cases clients do not handle <smbconfoption name="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 <smbconfoption name="read raw">no</smbconfoption> and see what happens on your +network. It might lower, raise, or not affect your performance. Only +testing can really tell. +</para> + +</sect1> + +<sect1> +<title>Write Raw</title> + +<para> +The <smbconfoption name="write raw"/> operation is designed to be an optimized, low-latency +file write operation. A server may choose to not support it, however, and Samba makes support for +<smbconfoption name="write raw"/> optional, with it being enabled by default. +</para> + +<para> +Some machines may find <smbconfoption name="write raw"/> slower than normal write, in which +case you may wish to change this option. +</para> + +</sect1> + +<sect1> +<title>Slow Logins</title> + +<para> +Slow logins are almost always due to the password checking time. Using +the lowest practical <smbconfoption name="password level"/> will improve things. +</para> + +</sect1> + +<sect1> +<title>Client Tuning</title> + +<para> +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 +<link linkend="Other-Clients">Samba and Other CIFS Clients</link>. +</para> + +</sect1> + +<sect1> +<title>Samba Performance Problem Due to Changing Linux Kernel</title> + +<para> +A user wrote the following to the mailing list: +</para> + +<blockquote> +<para> +<indexterm><primary>Gentoo</primary></indexterm> +<indexterm><primary>slow network</primary></indexterm> +I am running Gentoo on my server and Samba 2.2.8a. Recently I changed kernel versions from +<filename>linux-2.4.19-gentoo-r10</filename> to <filename>linux-2.4.20-wolk4.0s</filename>. Now I have a +performance issue with Samba. Many of you will probably say, <quote>Move to vanilla sources!</quote> Well, I +tried that and it didn't work. I have a 100MB LAN and two computers (Linux and Windows 2000). The Linux server +shares directories with DivX files, the client (Windows 2000) plays them via LAN. Before, when I was running +the 2.4.19 kernel, everything was fine, but now movies freeze and stop. I tried moving files between the +server and Windows, and it is terribly slow. +</para> +</blockquote> + +<para> +The answer he was given is: +</para> + +<blockquote> +<para> +<indexterm><primary>ifconfig</primary></indexterm> +<indexterm><primary>framing error</primary></indexterm> +<indexterm><primary>collisions</primary></indexterm> +Grab the 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, and so on, look +normal for ethernet. +</para> +</blockquote> + +</sect1> + +<sect1> +<title>Corrupt tdb Files</title> + +<para> +<indexterm><primary>PDC</primary></indexterm> +<indexterm><primary>mbd kept spawning</primary></indexterm> +<indexterm><primary>/var/locks/*.tdb</primary></indexterm> +Our Samba PDC server has been hosting three TB of data to our 500+ users [Windows NT/XP] for the last three +years using Samba without a problem. Today all shares went very slow. Also, the main smbd kept spawning new +processes, so we had 1600+ running SMDB's (normally we average 250). It crashed the SUN E3500 cluster twice. +After a lot of searching, I decided to <command>rm /var/locks/*.tdb</command>. Happy again. +</para> + +<para> +<emphasis>Question:</emphasis> Is there any method of keeping the *.tdb files in top condition, or +how can I detect early corruption? +</para> + +<para> +<indexterm><primary>tdbbackup</primary></indexterm> +<indexterm><primary>nmbd</primary></indexterm> +<emphasis>Answer:</emphasis> Yes, run <command>tdbbackup</command> each time after stopping nmbd and before starting nmbd. +</para> + +<para> +<emphasis>Question:</emphasis> What I also would like to mention is that the service latency seems +a lot lower than before the locks cleanup. Any ideas on keeping it top notch? +</para> + +<para> +<emphasis>Answer:</emphasis> Yes. Same answer as for previous question! +</para> + +</sect1> + +<sect1> +<title>Samba Performance is Very Slow</title> + +<para> +<indexterm><primary>slow performance</primary></indexterm> +A site reported experiencing very baffling symptoms with MYOB Premier opening and +accessing its data files. Some operations on the file would take between 40 and +45 seconds. +</para> + +<para> +<indexterm><primary>printer monitor</primary></indexterm> +<indexterm><primary>pauses</primary></indexterm> +It turned out that the printer monitor program running on the Windows +clients was causing the problems. From the logs, we saw activity coming +through with pauses of about 1 second. +</para> + +<para> +<indexterm><primary>networks access</primary></indexterm> +<indexterm><primary>printing now</primary></indexterm> +Stopping the monitor software resulted in the networks access at normal +(quick) speed. Restarting the program caused the speed to slow down +again. The printer was a Canon LBP-810 and the relevant task was +something like CAPON (not sure on spelling). The monitor software +displayed a "printing now" dialog on the client during printing. +</para> + +<para> +We discovered this by starting with a clean install of Windows and +trying the application at every step of the installation of other software +process (we had to do this many times). +</para> + +<para> +Moral of the story: Check everything (other software included)! +</para> + +</sect1> + +</chapter> |