diff options
Diffstat (limited to 'docs/htmldocs/Speed.html')
| -rw-r--r-- | docs/htmldocs/Speed.html | 550 |
1 files changed, 0 insertions, 550 deletions
diff --git a/docs/htmldocs/Speed.html b/docs/htmldocs/Speed.html deleted file mode 100644 index 47a8c885b6..0000000000 --- a/docs/htmldocs/Speed.html +++ /dev/null @@ -1,550 +0,0 @@ -<HTML -><HEAD -><TITLE ->Samba performance issues</TITLE -><META -NAME="GENERATOR" -CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD -><BODY -CLASS="ARTICLE" -BGCOLOR="#FFFFFF" -TEXT="#000000" -LINK="#0000FF" -VLINK="#840084" -ALINK="#0000FF" -><DIV -CLASS="ARTICLE" -><DIV -CLASS="TITLEPAGE" -><H1 -CLASS="TITLE" -><A -NAME="SPEED" ->Samba performance issues</A -></H1 -><HR></DIV -><DIV -CLASS="SECT1" -><H1 -CLASS="SECT1" -><A -NAME="AEN3" ->Comparisons</A -></H1 -><P ->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.</P -><P ->If you want to test against something like a NT or WfWg 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.</P -><P ->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 very much depends on your system.</P -><P ->Several people have done comparisons between Samba and Novell, NFS or -WinNT. In some cases Samba performed the best, in others the worst. I -suspect the biggest factor is not Samba vs 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.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN9" ->Oplocks</A -></H1 -><DIV -CLASS="SECT2" -><H2 -CLASS="SECT2" -><A -NAME="AEN11" ->Overview</A -></H2 -><P ->Oplocks are the way that SMB clients get permission from a server to -locally cache file operations. If a server grants an oplock -(opportunistic lock) then the client is free to assume that it is the -only one accessing the file and it will agressively cache file -data. With some oplock types the client may even cache file open/close -operations. This can give enormous performance benefits.</P -><P ->With the release of Samba 1.9.18 we now correctly support opportunistic -locks. This is turned on by default, and can be turned off on a share- -by-share basis by setting the parameter :</P -><P -><B -CLASS="COMMAND" ->oplocks = False</B -></P -><P ->We recommend that you leave oplocks on however, as current benchmark -tests with NetBench seem to give approximately a 30% improvement in -speed with them on. This is on average however, and the actual -improvement seen can be orders of magnitude greater, depending on -what the client redirector is doing.</P -><P ->Previous to Samba 1.9.18 there was a 'fake oplocks' option. This -option has been left in the code for backwards compatibility reasons -but it's use is now deprecated. A short summary of what the old -code did follows.</P -></DIV -><DIV -CLASS="SECT2" -><HR><H2 -CLASS="SECT2" -><A -NAME="AEN19" ->Level2 Oplocks</A -></H2 -><P ->With Samba 2.0.5 a new capability - level2 (read only) oplocks is -supported (although the option is off by default - see the smb.conf -man page for details). Turning on level2 oplocks (on a share-by-share basis) -by setting the parameter :</P -><P -><B -CLASS="COMMAND" ->level2 oplocks = true</B -></P -><P ->should speed concurrent access to files that are not commonly written -to, such as application serving shares (ie. shares that contain common -.EXE files - such as a Microsoft Office share) as it allows clients to -read-ahread cache copies of these files.</P -></DIV -><DIV -CLASS="SECT2" -><HR><H2 -CLASS="SECT2" -><A -NAME="AEN25" ->Old 'fake oplocks' option - deprecated</A -></H2 -><P ->Samba can also fake oplocks, by granting a oplock whenever a client -asks for one. This is controlled using the smb.conf option "fake -oplocks". If you set "fake oplocks = yes" then you are telling the -client that it may agressively cache the file data for all opens.</P -><P ->Enabling 'fake oplocks' on all read-only shares or shares that you know -will only be accessed from one client at a time you will see a big -performance improvement on many operations. If you enable this option -on shares where multiple clients may be accessing the files read-write -at the same time you can get data corruption.</P -></DIV -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN29" ->Socket options</A -></H1 -><P ->There are a number of socket options that can greatly affect the -performance of a TCP based server like Samba.</P -><P ->The socket options that Samba uses are settable both on the command -line with the -O option, or in the smb.conf file.</P -><P ->The "socket options" section of the smb.conf manual page describes how -to set these and gives recommendations.</P -><P ->Getting the socket options right 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.</P -><P ->The socket option TCP_NODELAY is the one that seems to make the -biggest single difference for most networks. Many people report that -adding "socket options = 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.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN36" ->Read size</A -></H1 -><P ->The option "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.</P -><P ->This overlapping works best when the speeds of disk and network access -are similar, having very little effect when the speed of one is much -greater than the other.</P -><P ->The default value is 16384, but very little experimentation has been -done 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.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN41" ->Max xmit</A -></H1 -><P ->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 "max xmit = " option -in smb.conf. Note that this is the maximum size of SMB request 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 -honours this limit.</P -><P ->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.</P -><P ->In most cases the default is the best option.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN46" ->Locking</A -></H1 -><P ->By default Samba does not implement strict locking on each read/write -call (although it did in previous versions). If you enable strict -locking (using "strict locking = yes") then you may find that you -suffer a severe performance hit on some systems.</P -><P ->The performance hit will probably be greater on NFS mounted -filesystems, but could be quite high even on local disks.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN50" ->Share modes</A -></H1 -><P ->Some people find that opening files is very slow. This is often -because of the "share modes" code needed to fully implement the dos -share modes stuff. You can disable this code using "share modes = -no". This will gain you a lot in opening and closing files but will -mean that (in some cases) the system won't force a second user of a -file to open the file read-only if the first has it open -read-write. For many applications that do their own locking this -doesn't matter, but for some it may. Most Windows applications -depend heavily on "share modes" working correctly and it is -recommended that the Samba share mode support be left at the -default of "on".</P -><P ->The share mode code in Samba has been re-written in the 1.9.17 -release following tests with the Ziff-Davis NetBench PC Benchmarking -tool. It is now believed that Samba 1.9.17 implements share modes -similarly to Windows NT.</P -><P ->NOTE: In the most recent versions of Samba there is an option to use -shared memory via mmap() to implement the share modes. This makes -things much faster. See the Makefile for how to enable this.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN55" ->Log level</A -></H1 -><P ->If you set the log level (also known as "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 very -expensive. </P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN58" ->Wide lines</A -></H1 -><P ->The "wide links" option is now enabled by default, but if you disable -it (for better security) then you may suffer a performance hit in -resolving filenames. The performance loss is lessened if you have -"getwd cache = yes", which is now the default.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN61" ->Read raw</A -></H1 -><P ->The "read raw" operation is designed to be an optimised, low-latency -file read operation. A server may choose to not support it, -however. and Samba makes support for "read raw" optional, with it -being enabled by default.</P -><P ->In some cases clients don't handle "read raw" very well and actually -get lower performance using it than they get using the conventional -read operations. </P -><P ->So you might like to try "read raw = no" and see what happens on your -network. It might lower, raise or not affect your performance. Only -testing can really tell.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN66" ->Write raw</A -></H1 -><P ->The "write raw" operation is designed to be an optimised, low-latency -file write operation. A server may choose to not support it, -however. and Samba makes support for "write raw" optional, with it -being enabled by default.</P -><P ->Some machines may find "write raw" slower than normal write, in which -case you may wish to change this option.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN70" ->Read prediction</A -></H1 -><P ->Samba can do read prediction on some of the SMB commands. Read -prediction means that Samba reads some extra data on the last file it -read while waiting for the next SMB command to arrive. It can then -respond more quickly when the next read request arrives.</P -><P ->This is disabled by default. You can enable it by using "read -prediction = yes".</P -><P ->Note that read prediction is only used on files that were opened read -only.</P -><P ->Read prediction should particularly help for those silly clients (such -as "Write" under NT) which do lots of very small reads on a file.</P -><P ->Samba will not read ahead more data than the amount specified in the -"read size" option. It always reads ahead on 1k block boundaries.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN77" ->Memory mapping</A -></H1 -><P ->Samba supports reading files via memory mapping them. One some -machines this can give a large boost to performance, on others it -makes not difference at all, and on some it may reduce performance.</P -><P ->To enable you you have to recompile Samba with the -DUSE_MMAP option -on the FLAGS line of the Makefile.</P -><P ->Note that memory mapping is only used on files opened read only, and -is not used by the "read raw" operation. Thus you may find memory -mapping is more effective if you disable "read raw" using "read raw = -no".</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN82" ->Slow Clients</A -></H1 -><P ->One person has reported that setting the protocol to COREPLUS rather -than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).</P -><P ->I suspect that his PC's (386sx16 based) were asking for more data than -they could chew. I suspect a similar speed could be had by setting -"read raw = no" and "max xmit = 2048", instead of changing the -protocol. Lowering the "read size" might also help.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN86" ->Slow Logins</A -></H1 -><P ->Slow logins are almost always due to the password checking time. Using -the lowest practical "password level" will improve things a lot. You -could also enable the "UFC crypt" option in the Makefile.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN89" ->Client tuning</A -></H1 -><P ->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.</P -><P ->See your client docs for details. In particular, I have heard rumours -that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a -large impact on performance.</P -><P ->Also note that some people have found that setting DefaultRcvWindow in -the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a -big improvement. I don't know why.</P -><P ->My own experience wth DefaultRcvWindow is that I get much better -performance with a large value (16384 or larger). Other people have -reported that anything over 3072 slows things down enourmously. One -person even reported a speed drop of a factor of 30 when he went from -3072 to 8192. I don't know why.</P -><P ->It probably depends a lot on your hardware, and the type of unix box -you have at the other end of the link.</P -><P ->Paul Cochrane has done some testing on client side tuning and come -to the following conclusions:</P -><P ->Install the W2setup.exe file from www.microsoft.com. This is an -update for the winsock stack and utilities which improve performance.</P -><P ->Configure the win95 TCPIP registry settings to give better -perfomance. I use a program called MTUSPEED.exe which I got off the -net. There are various other utilities of this type freely available. -The setting which give the best performance for me are:</P -><P -></P -><OL -TYPE="1" -><LI -><P ->MaxMTU Remove</P -></LI -><LI -><P ->RWIN Remove</P -></LI -><LI -><P ->MTUAutoDiscover Disable</P -></LI -><LI -><P ->MTUBlackHoleDetect Disable</P -></LI -><LI -><P ->Time To Live Enabled</P -></LI -><LI -><P ->Time To Live - HOPS 32</P -></LI -><LI -><P ->NDI Cache Size 0</P -></LI -></OL -><P ->I tried virtually all of the items mentioned in the document and -the only one which made a difference to me was the socket options. It -turned out I was better off without any!!!!!</P -><P ->In terms of overall speed of transfer, between various win95 clients -and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE -drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.</P -><P ->FIXME -The figures are: Put Get -P166 client 3Com card: 420-440kB/s 500-520kB/s -P100 client 3Com card: 390-410kB/s 490-510kB/s -DX4-75 client NE2000: 370-380kB/s 330-350kB/s</P -><P ->I based these test on transfer two files a 4.5MB text file and a 15MB -textfile. The results arn't bad considering the hardware Samba is -running on. It's a crap machine!!!!</P -><P ->The updates mentioned in 1 and 2 brought up the transfer rates from -just over 100kB/s in some clients.</P -><P ->A new client is a P333 connected via a 100MB/s card and hub. The -transfer rates from this were good: 450-500kB/s on put and 600+kB/s -on get.</P -><P ->Looking at standard FTP throughput, Samba is a bit slower (100kB/s -upwards). I suppose there is more going on in the samba protocol, but -if it could get up to the rate of FTP the perfomance would be quite -staggering.</P -></DIV -><DIV -CLASS="SECT1" -><HR><H1 -CLASS="SECT1" -><A -NAME="AEN121" ->My Results</A -></H1 -><P ->Some people want to see real numbers in a document like this, so here -they are. I have a 486sx33 client running WfWg 3.11 with the 3.11b -tcp/ip stack. It has a slow IDE drive and 20Mb of ram. It has a SMC -Elite-16 ISA bus ethernet card. The only WfWg tuning I've done is to -set DefaultRcvWindow in the [MSTCP] section of system.ini to 16384. My -server is a 486dx3-66 running Linux. It also has 20Mb of ram and a SMC -Elite-16 card. You can see my server config in the examples/tridge/ -subdirectory of the distribution.</P -><P ->I get 490k/s on reading a 8Mb file with copy. -I get 441k/s writing the same file to the samba server.</P -><P ->Of course, there's a lot more to benchmarks than 2 raw throughput -figures, but it gives you a ballpark figure.</P -><P ->I've also tested Win95 and WinNT, and found WinNT gave me the best -speed as a samba client. The fastest client of all (for me) is -smbclient running on another linux box. Maybe I'll add those results -here someday ...</P -></DIV -></DIV -></BODY -></HTML ->
\ No newline at end of file |