diff options
Diffstat (limited to 'docs/docbook/projdoc/Speed.xml')
| -rw-r--r-- | docs/docbook/projdoc/Speed.xml | 273 |
1 files changed, 0 insertions, 273 deletions
diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml deleted file mode 100644 index 987915acd2..0000000000 --- a/docs/docbook/projdoc/Speed.xml +++ /dev/null @@ -1,273 +0,0 @@ -<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. Thus 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, or in the &smb.conf; file. -</para> - -<para> -The <smbconfoption><name>socket options</name></smbconfoption> 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 -<?latex \linebreak ?><smbconfoption><name>socket options</name><value>TCP_NODELAY</value></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> - -</sect1> - -<sect1> -<title>Read Size</title> - -<para> -The option <smbconfoption><name>read size</name></smbconfoption> 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</name></smbconfoption> 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</name></smbconfoption>) 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</name></smbconfoption> 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</name></smbconfoption> optional, with it -being enabled by default. -</para> - -<para> -In some cases clients do not handle <smbconfoption><name>read raw</name></smbconfoption> very well and actually -get lower performance using it than they get using the conventional -read operations. -</para> - -<para> -So you might like to try <smbconfoption><name>read raw</name><value>no</value></smbconfoption> and see what happens on your -network. It might lower, raise or not effect your performance. Only -testing can really tell. -</para> - -</sect1> - -<sect1> -<title>Write Raw</title> - -<para> -The <smbconfoption><name>write raw</name></smbconfoption> 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</name></smbconfoption> optional, with it being enabled by default. -</para> - -<para> -Some machines may find <smbconfoption><name>write raw</name></smbconfoption> 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</name></smbconfoption> 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"/>. -</para> - -</sect1> - -<sect1> -<title>Samba Performance Problem Due to Changing Linux Kernel</title> - -<para> -A user wrote the following to the mailing list: -</para> - -<para> -I am running Gentoo on my server and Samba 2.2.8a. Recently -I changed kernel version from <filename>linux-2.4.19-gentoo-r10</filename> to -<filename>linux-2.4.20-wolk4.0s</filename>. And 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> - -<para> -The answer he was given is: -</para> - -<para> -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> - -</sect1> - -<sect1> -<title>Corrupt tdb Files</title> - -<para> -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 smbd's (normally we avg. 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> -<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> - -</chapter> |