From d4b35b895cdf157e49609b59ec89ab648dafb524 Mon Sep 17 00:00:00 2001 From: John Terpstra Date: Wed, 13 Apr 2005 04:04:36 +0000 Subject: More updates. (This used to be commit 20f8bde1d0a2b2e42efedcdac21778fe34c0ab79) --- docs/Samba-HOWTO-Collection/TOSHARG-Speed.xml | 317 ++++++++++++++++++++++++++ 1 file changed, 317 insertions(+) create mode 100644 docs/Samba-HOWTO-Collection/TOSHARG-Speed.xml (limited to 'docs/Samba-HOWTO-Collection/TOSHARG-Speed.xml') diff --git a/docs/Samba-HOWTO-Collection/TOSHARG-Speed.xml b/docs/Samba-HOWTO-Collection/TOSHARG-Speed.xml new file mode 100644 index 0000000000..1e74a22396 --- /dev/null +++ b/docs/Samba-HOWTO-Collection/TOSHARG-Speed.xml @@ -0,0 +1,317 @@ + + + + + + + PaulCochrane + + Dundee Limb Fitting Centre +
paulc@dth.scot.nhs.uk
+ + + &author.jelmer; + &author.jht; + + +Samba Performance Tuning + + +Comparisons + + +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. + + + +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. + + + +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. + + + +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. + + + + + +Socket Options + + +There are a number of socket options that can greatly affect the +performance of a TCP-based server like Samba. + + + +The socket options that Samba uses are settable both on the command +line with the option, or in the &smb.conf; file. + + + +The section of the &smb.conf; manual page describes how +to set these and gives recommendations. + + + +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. + + + +The socket option TCP_NODELAY is the one that seems to make the biggest single difference +for most networks. Many people report that adding +TCP_NODELAY +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. + + + +There have been reports that setting socket options = SO_RCVBUF=8192 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 socket options the effect +first be quantitatively measured on the server being configured. + + + + + +Read Size + + +The option 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. + + + +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. + + + +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. + + + + + +Max Xmit + + + At startup the client and server negotiate a maximum transmit size, +which limits the size of nearly all SMB commands. You can set the +maximum size that Samba will negotiate using the 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. + + + +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. + + + + + +Log Level + + +If you set the log level (also known as ) 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. + + + + +Read Raw + + +The 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 optional, with it +being enabled by default. + + + +In some cases clients do not handle very well and actually +get lower performance using it than they get using the conventional +read operations. + + + +So you might like to try no and see what happens on your +network. It might lower, raise or not effect your performance. Only +testing can really tell. + + + + + +Write Raw + + +The 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 + optional, with it being enabled by default. + + + +Some machines may find slower than normal write, in which +case you may wish to change this option. + + + + + +Slow Logins + + +Slow logins are almost always due to the password checking time. Using +the lowest practical will improve things. + + + + + +Client Tuning + + +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 +Samba and Other CIFS Clients. + + + + + +Samba Performance Problem Due to Changing Linux Kernel + + +A user wrote the following to the mailing list: + + + +I am running Gentoo on my server and Samba 2.2.8a. Recently +I changed kernel version from linux-2.4.19-gentoo-r10 to +linux-2.4.20-wolk4.0s. And now I have a performance issue with Samba. +Many of you will probably say, Move to vanilla sources! +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. + + + +The answer he was given is: + + + +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. + + + + + +Corrupt tdb Files + + +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 rm /var/locks/*.tdb. Happy again. + + + +Question: Is there any method of keeping the *.tdb files in top condition or +how can I detect early corruption? + + + +Answer: Yes, run tdbbackup each time after stopping nmbd and before starting nmbd. + + + +Question: 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? + + + +Answer: Yes. Same answer as for previous question! + + + + + +Samba Performance is Very Slow + + +A site reported experiencing very baffling symptoms with MYOB Premier opening and +accessing it's data-files. Some operations on the file would take between 40 and +45 seconds. + + + +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. + + + +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 cannon lbp810 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. + + + +We discovered this by starting with a clean install of windows and +trying the app at every step of the installation of other software +process (had to do this many times). + + + +Moral of the story, check everything (other software included)! + + + + + -- cgit