From fa8e760882ea389f8c94d6dfdc7386b0295974d1 Mon Sep 17 00:00:00 2001 From: Andrew Bartlett Date: Tue, 21 May 2013 17:49:55 +1000 Subject: docs: Remove out of date and unmaintained Speed page from the HOWTO Reviewed-by: Jeremy Allison --- docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml | 327 -------------------------------- docs-xml/Samba3-HOWTO/index.xml | 2 - 2 files changed, 329 deletions(-) delete mode 100644 docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml (limited to 'docs-xml') diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml deleted file mode 100644 index 18a15ae092..0000000000 --- a/docs-xml/Samba3-HOWTO/TOSHARG-Speed.xml +++ /dev/null @@ -1,327 +0,0 @@ - - - - - - - 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, 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. - - - -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 and 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 affect 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: - - -
- -Gentoo -slow network -I am running Gentoo on my server and Samba 2.2.8a. Recently I changed kernel versions from -linux-2.4.19-gentoo-r10 to linux-2.4.20-wolk4.0s. 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: - - -
- -ifconfig -framing error -collisions -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 - - -PDC -mbd kept spawning -/var/locks/*.tdb -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 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? - - - -tdbbackup -nmbd -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 - - -slow performance -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. - - - -printer monitor -pauses -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. - - - -networks access -printing now -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. - - - -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). - - - -Moral of the story: Check everything (other software included)! - - - - - diff --git a/docs-xml/Samba3-HOWTO/index.xml b/docs-xml/Samba3-HOWTO/index.xml index b2af47af6e..e496ce40b5 100644 --- a/docs-xml/Samba3-HOWTO/index.xml +++ b/docs-xml/Samba3-HOWTO/index.xml @@ -202,8 +202,6 @@ The chapters in this part each cover specific Samba features. - - -- cgit