+++ /dev/null
-<?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>
git.samba.org / amitay / samba.git / commitdiff