samba - Apr 1998 - Help Me Beat NT--Red Hat Performance Help Needed

I have tried all I can think of to resolve a samba performance
problem. Below is a description of the problem. The Red Hat
server is actually a higher performance machine than the NT
machine, though they are close in capabilities:
> When I first installed 5.0 I notices slow samba performance.  By slow I
> mean around 80K/second doing a normal copy to the server from a Windows
> 95 machine. Really slow. We have a workgroup attached through a 100 Mb/s
> 3Com hub with the combination 10base-T/Fast connection NICs.
>
> Here is what is confusing. If I send from this a Windows 95 or NT
> machine to an NT server on the same network, I get about 2000K/second,
> 25 times faster than going to the linux server. If I ftp from/to the
> same machines I get about 600K/second. Not what we want to get, but lots
> better than 80K/second. This makes it look like the server is not
> configured correctly.
>
> However, if I use smbclient from another linux box to this same server,
> I get about 1200K/second. Getting closer to my target. If I ftp between
> the same linux machines, I get around 2000K/second, our target goal.
>
> Since I am doing the transfers from different Windows and NT machines
> with the same results, it makes it look like it is the server's
problem.
> However, when the linux machines are doing the transfers, all is
> acceptable, so it makes the server look like it is configured correctly.
> I am out of ideas.
>
> I have tried many different things with samba. I messed with the
> smb.conf file a lot as the software was installed right out of the box.
> I am now in a state where I have compiled and installed version
> 1.9.18p3. I have compiled it and tested performance with roughly the
> same results with almost all combinations of options. Last attempt, I
> went back to the suggested options:
>
> FLAGSM = -DLINUX -DNETGROUP -DALLOW_CHANGE_PASSWORD -DFAST_SHARE_MODES
> -DNO_ASMSIGNALH -DGLIBC2 LIBSM = -lnsl -lcrypt
>
> I have tried it with and without glibc. I also tried it with the glibc
> errata rpm installed, saw no difference, but begin having some nfs
> related problems, so I just reinstalled the entire OS to make sure I was
> ok, went through these rounds of tests again with no material
> difference.
>
> I have tried MANY smb.conf options, with no material change. Currently,
> I have the following options in the smb.conf file:
>
> oplocks = true
> locking = no
> strict locking = no
> max xmit = 8192
> read raw = no
> socket options = TCP_NODELAY
>
> I have tried basically with all combinations of the above. My last attempt
was adding the "max xmit" and "read raw" stuff, which did
nothing.
>
> I did not install your smbfs*.rpm general errata as it looks like it only
dealt with authentication, plus I am now running a new version and thought I
shouldn't.
>
> Don't think it will make much difference, but just FYI, the new samba
software is installed in /usr/local/samba and I changed /etc/rc.d/init.d/smb
by removing the "daemon" startup lines for smbd and nmbd and inserted
in
their place:
>
> /usr/local/samba/bin/smbd -D
> /usr/local/samba/bin/nmbd -D
>
> I have tried higher debug logging levels and did not see anything that
stood out, though I have not done much of that.
>
> Basically I am out of ideas and I am trying to prevent NT server from
beating out linux. I won't be able to resist the forces here much longer, so
I need to resolve this.
>
> Another FYI, we are also running the asun netatalk for AppleTalk services
and getting 800-1000K/second performance from Macintosh clients to this same
server.
>
> I have seen on mailing lists that people are running the 2.0.33 kernel,
which we are still on 2.0.31. I'd appreciate a pointer to a place to
describe how to install a new kernel.
>
> Also, we have 256MB of RAM in this server. Does linux use it? I have read
a number of places that beyond 64MB either it slows the system down or it
does not use RAM above 64MB. Is there any truth to this?
>
> I've told you all I can.
_________________________________
Frank Morton (fmorton@base2inc.com)
Voice: (317) 876-3355
FAX: (317) 876-3398
Home: (317) 574-0815

Hi
> I have tried all I can think of to resolve a samba performance
> problem. Below is a description of the problem. The Red Hat
> server is actually a higher performance machine than the NT
> machine, though they are close in capabilities:
  This is a problem - shouldn't happen...

[snip-snip]
> > FLAGSM = -DLINUX -DNETGROUP -DALLOW_CHANGE_PASSWORD -DFAST_SHARE_MODES
> > -DNO_ASMSIGNALH -DGLIBC2 LIBSM = -lnsl -lcrypt
  I would also add -DUSE_MMAP, it should have slightly better performace
(reducing one kernel space->user space copy). But I haven't yet
benchmarked
any impact of this option.
> > oplocks = true
> > locking = no
> > strict locking = no
> > max xmit = 8192
> > read raw = no
> > socket options = TCP_NODELAY
  Are you sure that no log entries about "unknown socket options" are
not present? Its a common compilation problem under Linuxes...
  Looks OK. I had once be forced to use "max xmit=1200" (or smth about
it -
just to be equal with various other headers the local ethernet frame size)
but it was probably caused by totally broken DOS MSclient.
  "read raw=no" is a nono for performance but it should have only a
very
small percentual impact.
> > I have seen on mailing lists that people are running the 2.0.33
kernel,
> which we are still on 2.0.31. I'd appreciate a pointer to a place to
> describe how to install a new kernel.
  If you really want to beat it all, try 2.1.92 (or higher). 2.1.x is really
worth trying it (but remember always that it's the DEVELOPMENT kernel!).
If you have any problems regarding new kernel install, contact me pers.
off the list, please.
> > Also, we have 256MB of RAM in this server. Does linux use it? I have
read
> a number of places that beyond 64MB either it slows the system down or it
> does not use RAM above 64MB. Is there any truth to this?
  2.0.x is not yet capable of >64MB detection. In 2.1.(big x) all the
workarounds and exceptions are considered to be functioning/stable. Try
option "mem=256M" on the kernel command line anyway.
  But the larger memory (>32MB) sizes make a problem to disk buffering
Linux subsystem. If you have large "buffer" memory allocated, you
should try increasing the HASH_PAGES in "/usr/src/linux/fs/buffer.c"
(watch out for similiar define nearby which is the same in log2 - not
contained in newer kernel releases). More info would be provided
by profile described lower.
> > I've told you all I can.
  Unfortunately not - please try to include tcpdump output (preferably
with SMB support to review SMB communication but also some longer
dump without SMB resolving to see TCP acks/data flow).
  Also please enable kernel profiling and use "readprofile" to provide
kernel CPU consumption statistics. If severe kernel load will appear,
provide me your kernel image (zImage), symbols (System.map) and
the profile file itself (/proc/profile in 2.0.x). Furhermore "top"
dumps
during SMB transfer would be nice to see kernel/user level load balance and
process CPU usage.
  See "/proc/net/dev" to see failed packets/link errors on ethernet.

  And last but not least - have you TCP/IP the only protocol in Win*?
There is reported that several protocols used on the same machine
(even unbinded!) are a problem for M$ - slowdown will occur.

				Good luck,
					Jan "Lace" Kratochvil