summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc/Speed.xml
diff options
context:
space:
mode:
authorGerald Carter <jerry@samba.org>2003-07-16 05:34:56 +0000
committerGerald Carter <jerry@samba.org>2003-07-16 05:34:56 +0000
commit4a090ba06a54f5da179ac02bb307cc03d08831bf (patch)
treeed652ef36be7f16682c358816334f969a22f1c27 /docs/docbook/projdoc/Speed.xml
parent95fe82670032a3a43571b46d7bbf2c26bc8cdcd9 (diff)
downloadsamba-4a090ba06a54f5da179ac02bb307cc03d08831bf.tar.gz
samba-4a090ba06a54f5da179ac02bb307cc03d08831bf.tar.bz2
samba-4a090ba06a54f5da179ac02bb307cc03d08831bf.zip
trying to get HEAD building again. If you want the code
prior to this merge, checkout HEAD_PRE_3_0_0_BETA_3_MERGE (This used to be commit adb98e7b7cd0f025b52c570e4034eebf4047b1ad)
Diffstat (limited to 'docs/docbook/projdoc/Speed.xml')
-rw-r--r--docs/docbook/projdoc/Speed.xml98
1 files changed, 73 insertions, 25 deletions
diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml
index e2ede62ac7..659cd6e31b 100644
--- a/docs/docbook/projdoc/Speed.xml
+++ b/docs/docbook/projdoc/Speed.xml
@@ -9,9 +9,10 @@
</affiliation>
</author>
&author.jelmer;
+ &author.jht;
</chapterinfo>
-<title>Samba performance issues</title>
+<title>Samba Performance Tuning</title>
<sect1>
<title>Comparisons</title>
@@ -28,7 +29,7 @@ SMB server.
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.
+(such as NetBEUI) and comparisons may not be valid.
</para>
<para>
@@ -58,11 +59,11 @@ performance of a TCP based server like Samba.
<para>
The socket options that Samba uses are settable both on the command
-line with the -O option, or in the smb.conf file.
+line with the <option>-O</option> option, or in the &smb.conf; file.
</para>
<para>
-The <command>socket options</command> section of the &smb.conf; manual page describes how
+The <parameter>socket options</parameter> section of the &smb.conf; manual page describes how
to set these and gives recommendations.
</para>
@@ -75,7 +76,7 @@ much. The correct settings are very dependent on your local network.
<para>
The socket option TCP_NODELAY is the one that seems to make the
biggest single difference for most networks. Many people report that
-adding <command>socket options = TCP_NODELAY</command> doubles the read
+adding <parameter>socket options = TCP_NODELAY</parameter> 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.
</para>
@@ -86,7 +87,7 @@ that the Microsoft TCP/IP stack is slow in sending tcp ACKs.
<title>Read size</title>
<para>
-The option <command>read size</command> affects the overlap of disk
+The option <parameter>read size</parameter> 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
@@ -114,9 +115,9 @@ pointless and will cause you to allocate memory unnecessarily.
<title>Max xmit</title>
<para>
-At startup the client and server negotiate a <command>maximum transmit</command> size,
+At startup the client and server negotiate a <parameter>maximum transmit</parameter> size,
which limits the size of nearly all SMB commands. You can set the
-maximum size that Samba will negotiate using the <command>max xmit = </command> option
+maximum size that Samba will negotiate using the <parameter>max xmit = </parameter> 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
@@ -139,7 +140,7 @@ In most cases the default is the best option.
<title>Log level</title>
<para>
-If you set the log level (also known as <command>debug level</command>) higher than 2
+If you set the log level (also known as <parameter>debug level</parameter>) 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.
@@ -150,20 +151,20 @@ expensive.
<title>Read raw</title>
<para>
-The <command>read raw</command> operation is designed to be an optimised, low-latency
+The <parameter>read raw</parameter> 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 <command>read raw</command> optional, with it
+however. and Samba makes support for <parameter>read raw</parameter> optional, with it
being enabled by default.
</para>
<para>
-In some cases clients don't handle <command>read raw</command> very well and actually
+In some cases clients don't handle <parameter>read raw</parameter> very well and actually
get lower performance using it than they get using the conventional
read operations.
</para>
<para>
-So you might like to try <command>read raw = no</command> and see what happens on your
+So you might like to try <parameter>read raw = no</parameter> and see what happens on your
network. It might lower, raise or not affect your performance. Only
testing can really tell.
</para>
@@ -174,14 +175,14 @@ testing can really tell.
<title>Write raw</title>
<para>
-The <command>write raw</command> operation is designed to be an optimised, low-latency
+The <parameter>write raw</parameter> 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 <command>write raw</command> optional, with it
+however. and Samba makes support for <parameter>write raw</parameter> optional, with it
being enabled by default.
</para>
<para>
-Some machines may find <command>write raw</command> slower than normal write, in which
+Some machines may find <parameter>write raw</parameter> slower than normal write, in which
case you may wish to change this option.
</para>
@@ -192,31 +193,78 @@ case you may wish to change this option.
<para>
Slow logins are almost always due to the password checking time. Using
-the lowest practical <command>password level</command> will improve things.
+the lowest practical <parameter>password level</parameter> will improve things.
</para>
</sect1>
<sect1>
-<title>LDAP</title>
+<title>Client tuning</title>
<para>
-LDAP can be vastly improved by using the
-<ulink url="smb.conf.5.html#LDAPTRUSTIDS">ldap trust ids</ulink> parameter.
+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
+<link linkend="Other-Clients">Samba and Other Clients</link>.
</para>
</sect1>
+<sect1>
+<title>Samba performance problem due changing kernel</title>
+
+<para>
+Hi everyone. 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 performance issue with samba. Ok
+many of you will probably say that move to vanilla sources...well I tried
+it too and it didn't work. I have 100mb LAN and two computers (linux +
+Windows2000). Linux server shares directory with DivX files, client
+(windows2000) plays them via LAN. Before when I was running 2.4.19 kernel
+everything was fine, but now movies freezes and stops...I tried moving
+files between server and Windows and it's terribly slow.
+</para>
+
+<para>
+Grab 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, etc... look normal for ethernet.
+</para>
+
+</sect1>
<sect1>
-<title>Client tuning</title>
+<title>Corrupt tdb Files</title>
<para>
-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
-<link linkend="Other-Clients">Samba and Other Clients</link>.
+Well today it happened, Our first major problem using samba.
+Our samba PDC server has been hosting 3 TB of data to our 500+ users
+[Windows NT/XP] for the last 3 years using samba, no problem.
+But today all shares went SLOW; 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 <command>rm /var/locks/*.tdb</command>. Happy again.
+</para>
+
+<para>
+Q1) Is there any method of keeping the *.tdb files in top condition or
+how to early detect corruption?
+</para>
+
+<para>
+A1) Yes, run <command>tdbbackup</command> each time after stopping nmbd and before starting nmbd.
+</para>
+
+<para>
+Q2) What I also would like to mention is that the service latency seems
+a lot lower then before the locks cleanup, any ideas on keeping it top notch?
+</para>
+
+<para>
+A2) Yes! Same answer as for Q1!
</para>
</sect1>
+
</chapter>