1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Samba performance issues</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="SAMBA Project Documentation"
HREF="samba-howto-collection.html"><LINK
REL="UP"
TITLE="Appendixes"
HREF="appendixes.html"><LINK
REL="PREVIOUS"
TITLE="SWAT - The Samba Web Admininistration Tool"
HREF="swat.html"><LINK
REL="NEXT"
TITLE="The samba checklist"
HREF="diagnosis.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>SAMBA Project Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="swat.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="diagnosis.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="SPEED"
></A
>Chapter 32. Samba performance issues</H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>32.1. <A
HREF="speed.html#AEN4666"
>Comparisons</A
></DT
><DT
>32.2. <A
HREF="speed.html#AEN4672"
>Socket options</A
></DT
><DT
>32.3. <A
HREF="speed.html#AEN4679"
>Read size</A
></DT
><DT
>32.4. <A
HREF="speed.html#AEN4684"
>Max xmit</A
></DT
><DT
>32.5. <A
HREF="speed.html#AEN4689"
>Log level</A
></DT
><DT
>32.6. <A
HREF="speed.html#AEN4692"
>Read raw</A
></DT
><DT
>32.7. <A
HREF="speed.html#AEN4697"
>Write raw</A
></DT
><DT
>32.8. <A
HREF="speed.html#AEN4701"
>Slow Clients</A
></DT
><DT
>32.9. <A
HREF="speed.html#AEN4705"
>Slow Logins</A
></DT
><DT
>32.10. <A
HREF="speed.html#AEN4708"
>Client tuning</A
></DT
></DL
></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN4666"
>32.1. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4672"
>32.2. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4679"
>32.3. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4684"
>32.4. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4689"
>32.5. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4692"
>32.6. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4697"
>32.7. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4701"
>32.8. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4705"
>32.9. 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"
><H1
CLASS="SECT1"
><A
NAME="AEN4708"
>32.10. 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
><PRE
CLASS="PROGRAMLISTING"
>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</PRE
></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
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="swat.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="samba-howto-collection.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="diagnosis.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>SWAT - The Samba Web Admininistration Tool</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="appendixes.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The samba checklist</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|
