appb.pdf
(
256 KB
)
Pobierz
,appb.27799 Page 312 Friday, November 19, 1999 3:30 PM
Samba Performance
Tuning
Appendix B
This appendix discusses various ways of performance tuning and system sizing
with Samba.
Performance tuning
is the art of finding bottlenecks and adjusting to
eliminate them.
Sizing
is the practice of eliminating bottlenecks by spending
money to avoid having them in the first place. Normally, you won’t have to worry
about either with Samba. On a completely untuned server, Samba will happily
support a small community of users. However, on a properly tuned server, Samba
will support at least twice as many users. This chapter is devoted to outlining vari-
ous performance-tuning and sizing techniques that you can use if you want to
stretch your Samba server to the limit.
A Simple Benchmark
How do you know if you’re getting reasonable performance? A simple benchmark
is to compare Samba with FTP. Table B-1 shows the throughput, in kilobytes per
second, of a pair of servers: a medium-size Sun SPARC Ultra and a small Linux
Pentium server. Numbers are reported in kilobytes per second (KB/s).
Table B-1. Sample Benchmark Benchmarks
Command
FTP
Untuned Samba
Tuned Samba
Sparc get
1014.5
645.3
866.7
Sparc put
379.8
386.1
329.5
Pentium get
973.27
N/A
725
Pentium put
1014.5
N/A
1100
If you run the same tests on your server, you probably won’t see the same num-
bers. However, you
should
see similar ratios of Samba to FTP, probably in the
range of 68 to 80 percent. It’s not a good idea to base
all
of Samba’s throughput
312
,appb.27799 Page 313 Friday, November 19, 1999 3:30 PM
Samba Tuning
313
against FTP. The golden rule to remember is this: if Samba is much slower than
FTP, it’s time to tune it.
You might think that an equivalent test would be to compare Samba to NFS. In
reality, however, it’s much less useful to compare their speeds. Depending entirely
on whose version of NFS you have and how well it’s tuned, Samba can be slower
or faster than NFS. We usually find that Samba is faster, but watch out; NFS uses a
different algorithm from Samba, so tuning options that are optimal for NFS may be
detrimental for Samba. If you run Samba on a well-tuned NFS server, Samba may
perform rather badly.
A more popular benchmark is Ziff-Davis’
NetBench,
a simulation of many users on
client machines running word processors and accessing data on the SMB server.
It’s not a prefect measure (each NetBench client does about ten times the work of
a normal user on our site), but it is a fair comparison of similar servers. In tests
performed by Jeremy Allison in November 1998, Samba 2.0 on a SGI multiproces-
sor outperformed NT Server 4.0 (Patch Level 2) on an equivalent high-end Com-
paq. This was confirmed and strengthened by a Sm@rt Reseller test of NT and
Linux on identical hardware in February 1999.
In April 1999, the Mindcraft test lab released a report about a test showing that
Samba on a four-processor Linux machine was significantly slower than native file
serving on the same machine running Windows NT. While the original report was
slammed by the Open Source community because it was commissioned by
Microsoft and tuned the systems to favor Windows NT, a subsequent test was
fairer and generally admitted to reveal some areas where Linux needed to improve
its performance, especially on multiprocessors. Little was said about Samba itself.
Samba is known to scale well on multiprocessors, and exceeds 440MB/s on a four-
processor SGI O200, beating Mindcraft’s 310MB/s.
Relative performance will probably change as NT and PC hardware get faster, of
course, but Samba is improving as well. For example, Samba 1.9.18 was faster only
with more than 35 clients. Samba 2.0, however, is faster regardless of the number
of clients. In short, Samba is very competitive with the best networking software in
the industry, and is only getting better.
As we went to press, Andrew Tridgell released the alpha-test version suite of
benchmarking programs for Samba and SMB networks. Expect even more work on
performance from the Samba team in the future.
Samba Tuning
That being said, let’s discuss how you can take an already fast networking pack-
age and make it even faster.
,appb.27799 Page 314 Friday, November 19, 1999 3:30 PM
314
Appendix B: Samba Performance Tuning
Benchmarking
Benchmarking is an arcane and somewhat black art, but the level of expertise
needed for simple performance tuning is fairly low. Since the Samba server’s goal
in life is to transfer files, we will examine only throughput, not response time to
particular events, under the benchmarking microscope. After all, it’s relatively easy
to measure file transfer speed, and Samba doesn’t suffer too badly from response-
time problems that would require more sophisticated techniques.
Our basic strategy for this work will be:
• Find a reasonably-sized file to copy and a program that reports on copy
speeds, such as
smbclient
.
• Find a quiet (or typical) time to do the test.
• Pre-run each test a few times to preload buffers.
• Run tests several times and watch for unusual results.
• Record each run in detail.
• Compare the average of the valid runs to expected values.
After establishing a baseline using this method, we can adjust a single parameter
and do the measurements all over again. An empty table for your tests is provided
at the end of this chapter.
Things to Tweak
There are literally thousands of Samba setting combinations that you can use in
search of that perfect server. Those of us with lives outside of system administra-
tion, however, can narrow down the number of options to those listed in this sec-
tion, which are the most likely to affect overall throughput. They are presented
roughly in order of impact.
Log level
This is an obvious one. Increasing the logging level (
log level
or
debug level
configuration options) is a good way to debug a problem, unless you happen to
be searching for a performance problem! As mentioned in Chapter 4,
Disk Shares
,
Samba produces a ton of debugging messages at level 3 and above, and writing
them to disk or syslog is a slow operation. In our
smbclient/ftp
tests, raising the
log level from 0 to 3 cut the untuned
get speed
from 645.3 to 622.2KB/s, or
roughly 5 percent. Higher log levels were even worse.
Socket options
The next thing to look at are the
socket options
configuration options. These
are really host system tuning options, but they’re set on a per-connection basis,
,appb.27799 Page 315 Friday, November 19, 1999 3:30 PM
Samba Tuning
315
and can be reset by Samba on the sockets it employs by adding
socket options
= option
to the
[global]
section of your
smb.conf
file. Not all of these options
are supported by all vendors; check your vendor’s manual pages on
setsockopt
(1)
or
socket
(5) for details.
The main options are:
TCP_NODELAY
Have the server send as many packets as necessary to keep delay low. This is
used on telnet connections to give good response time, and is used—some-
what counter-intuitively—to get good speed even when doing small requests
or when acknowledgments are delayed (as seems to occur with Microsoft
TCP/IP). This is worth a 30–50 percent speedup by itself. Incidentally, in
Samba 2.0.4,
socket options = TCP_NODELAY
became the default value for
that option.
IPTOS_LOWDELAY
This is another option that trades off throughput for lower delay, but which
affects routers and other systems, not the server. All the IPTOS options are
new; they’re not supported by all operating systems and routers. If they are
supported, set
IPTOS_LOWDELAY
whenever you set
TCP_NODELAY
.
SO_SNDBUF and SO_RCVBUF
The send and receive buffers can often be the reset to a value higher than that
of the operating system. This yields a marginal increase of speed (until it
reaches a point of diminishing returns).
SO_KEEPALIVE
This initiates a periodic (four-hour) check to see if the client has disappeared.
Expired connections are addressed somewhat better with Samba’s
keepalive
and
dead time
options. All three eventually arrange to close dead connec-
tions, returning unused memory and process-table entries to the operating
system.
There are several other socket options you might look at, (e.g.,
SO_SNDLOWAT
),
but they vary in availability from vendor to vendor. You probably want to look at
TCP/IP Illustrated
if you’re interested in exploring more of these options for per-
formance tuning with Samba.
read raw and write raw
These are important performance configuration options; they enable Samba to use
large reads and writes to the network, of up to 64KB in a single SMB request. They
also require the largest SMB packet structures,
SMBreadraw
and
SMBwriteraw
,
from which the options take their names. Note that this is not the same as a Unix
raw read
. This Unix term usually refers to reading disks without using the files sys-
tem, quite a different sense from the one described here for Samba.
,appb.27799 Page 316 Friday, November 19, 1999 3:30 PM
316
Appendix B: Samba Performance Tuning
In the past, some client programs failed if you tried to use
read raw
. As far as we
know, no client suffers from this problem any more. Read and write raw default to
yes
, and should be left on unless you find you have one of the buggy clients.
Opportunistic locking
Opportunistic locks, or
oplocks
, allow clients to cache files locally, improving per-
formance on the order of 30 percent. This option is now enabled by default. For
read-only files, the
fake oplocks
provides the same functionality without actu-
ally doing any caching. If you have files that cannot be cached,
oplocks
can be
turned off.
Database files should never be cached, nor should any files that are updated both
on the server and the client and whose changes must be immediately visible. For
these files, the
veto oplock files
option allows you to specify a list of individ-
ual files or a pattern containing wildcards to avoid caching.
oplocks
can be turned
off on a share-by-share basis if you have large groups of files you don’t want
cached on clients. See Chapter 5,
Browsing and Advanced Disk Shares
, for more
information on opportunistic locks.
IP packet size (MTU)
Networks generally set a limit to the size of an individual transmission or packet
This is called the Maximum Segment Size, or if the packet header size is included,
the Maximum Transport Unit (MTU). This MTU is not set by Samba, but Samba
needs to use a
max xmit
(write size) bigger than the MTU, or throughput will be
reduced. This is discussed in further detail in the following note. The MTU is nor-
mally preset to 1500 bytes on an Ethernet and 4098 bytes on FDDI. In general,
having it too low cuts throughput, and having it too high causes a sudden perfor-
mance dropoff due to fragmentation and retransmissions.
If you are communicating over a router, some systems will assume
the router is a serial link (e.g., a T1) and set the MTU to more or less
536 bytes. Windows 95 makes this mistake, which causes nearby cli-
ents to perform well, but clients on the other side of the router to be
noticeably slower. If the client makes the opposite error and uses a
large MTU on a link which demands a small one, the packets will be
broken up into fragments. This slows transfers slightly, and any net-
working errors will cause multiple fragments to be retransmitted,
which slows Samba significantly. Fortunately, you can modify the
Windows MTU size to prevent either error. To understand this in
more detail, see “The Windows 95 Networking Frequently Asked
Questions (FAQ)” at
http://www.stanford.edu/~llurch/win95netbugs/
faq.html
, which explains how to override the Windows MTU and
Window Size.
Plik z chomika:
musli_com
Inne pliki z tego folderu:
sambapdf.zip
(4941 KB)
ch03.pdf
(3390 KB)
ch09.pdf
(1871 KB)
appb.pdf
(256 KB)
ch04.pdf
(810 KB)
Inne foldery tego chomika:
Zgłoś jeśli
naruszono regulamin