From f0e282ebf3e459c559bfc08f3e21fdebb2515621 Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Thu, 16 Jan 2003 02:20:27 +0000 Subject: * merge fixes for SGML syntax errors (does no one ever regenerate the docs?) * regenerate the docs * add some files from SAMBA_3_0 (This used to be commit 1af74785f334bd84b2d62e7fc2975f9477386acb) --- docs/htmldocs/speed.html | 281 +++-------------------------------------------- 1 file changed, 18 insertions(+), 263 deletions(-) (limited to 'docs/htmldocs/speed.html') diff --git a/docs/htmldocs/speed.html b/docs/htmldocs/speed.html index 85562e3e89..1a05706f92 100644 --- a/docs/htmldocs/speed.html +++ b/docs/htmldocs/speed.html @@ -5,7 +5,8 @@ >Samba performance issues

Chapter 23. Samba performance issues

Chapter 22. Samba performance issues

23.1. Comparisons

22.1. 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 @@ -111,98 +108,7 @@ CLASS="SECT1" >

23.2. Oplocks

23.2.1. Overview

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.

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 :

oplocks = False

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.

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.

23.2.2. Level2 Oplocks

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 :

level2 oplocks = true

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.

23.2.3. Old 'fake oplocks' option - deprecated

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.

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.

23.3. Socket options

22.2. Socket options

There are a number of socket options that can greatly affect the performance of a TCP based server like Samba.

23.4. Read size

22.3. Read size

The option "read size" affects the overlap of disk reads/writes with network reads/writes. If the amount of data being transferred in @@ -254,9 +158,7 @@ CLASS="SECT1" >

23.5. Max xmit

22.4. 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 @@ -277,56 +179,7 @@ CLASS="SECT1" >

23.6. Locking

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.

The performance hit will probably be greater on NFS mounted -filesystems, but could be quite high even on local disks.

23.7. Share modes

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".

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.

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.

23.8. Log level

22.5. Log level

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 @@ -338,23 +191,7 @@ CLASS="SECT1" >

23.9. Wide lines

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.

23.10. Read raw

22.6. Read raw

The "read raw" operation is designed to be an optimised, low-latency file read operation. A server may choose to not support it, @@ -374,9 +211,7 @@ CLASS="SECT1" >

23.11. Write raw

22.7. Write raw

The "write raw" operation is designed to be an optimised, low-latency file write operation. A server may choose to not support it, @@ -391,56 +226,7 @@ CLASS="SECT1" >

23.12. Read prediction

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.

This is disabled by default. You can enable it by using "read -prediction = yes".

Note that read prediction is only used on files that were opened read -only.

Read prediction should particularly help for those silly clients (such -as "Write" under NT) which do lots of very small reads on a file.

Samba will not read ahead more data than the amount specified in the -"read size" option. It always reads ahead on 1k block boundaries.

23.13. Memory mapping

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.

To enable you you have to recompile Samba with the -DUSE_MMAP option -on the FLAGS line of the Makefile.

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".

23.14. Slow Clients

22.8. Slow Clients

One person has reported that setting the protocol to COREPLUS rather than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).

23.15. Slow Logins

22.9. Slow Logins

Slow logins are almost always due to the password checking time. Using the lowest practical "password level" will improve things a lot. You @@ -468,9 +252,7 @@ CLASS="SECT1" >

23.16. Client tuning

22.10. 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 @@ -545,11 +327,13 @@ turned out I was better off without any!!!!!

FIXME -The figures are: Put Get +>

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
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 
@@ -567,35 +351,6 @@ 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.

23.17. My Results

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.

I get 490k/s on reading a 8Mb file with copy. -I get 441k/s writing the same file to the samba server.

Of course, there's a lot more to benchmarks than 2 raw throughput -figures, but it gives you a ballpark figure.

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 ...