Help Me Beat NT--Red Hat Performance Help Needed

[Jan Kratochvil]

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