Date: Tue, 3 Oct 2006 22:14:01 -0400 From: Martin Cracauer <cracauer@cons.org> To: Jan Zacharias <jan@graphics.cs.uni-sb.de> Cc: Performance/tuning <freebsd-performance@freebsd.org> Subject: Re: Samba Performance problem Message-ID: <20061004021401.GA69704@cons.org> In-Reply-To: <op.tgnbxpqguaqwyp@bofh.cs.uni-sb.de> References: <3131aa530609290721o267d55bakff4e801ef4000675@mail.gmail.com> <op.tgnbxpqguaqwyp@bofh.cs.uni-sb.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Jan Zacharias wrote on Fri, Sep 29, 2006 at 05:28:27PM +0200:
> Hi Olivier,
>
> generally the Samba performance on *BSD just sucks,
> I wrote to this list with the same problem some weeks ago,
> no one was able to tune smbd so that it would outperform
> as well as under linux.
I haven't seen previous discussions about this, but in general you
have a problem on FreeBSD when processes takes up some good amount of
CPU but there is currently performance monitoring being does for
network traffic, outbound traffic in particular.
When you compare FreeBSD's and Linux' behaviour while CPU eating
processes and network traffic compete for the machine, you see that
FreeBSD has the network traffic slow down a whole lot, while Linux
cuts resources off the CPU consuming processes (this is contrary to
what people normally assume, which is that FreeBSD is the ninja macho
networker's tool and Linux is more for "desktop" performance, it's
the other way round).
While there are different situations where one or the other can be
better, the situation of serving out SMB via Samba maximizes a
situation where FreeBSD looks bad. The Samba processes take up quite
a bit of CPU and apparently that goes directly to the latency or
throughput of the output. If suspect that packets are written into
the network buffers and then new CPU demands from the Samba process
clobber the timely delivery. Linux does the opposite, once the
packets are available for delivery it rushes out the packages as soon
as it can and the CPU demanding process is left starving while doing
so (in this Samba case that is what you want, in other cases it might
ruin your computation performance).
If my assumption is correct, then ktracing or profiling won't do much
to understand the situation. A complex analysis on the client side
about latency and throughput after specific SMB calls from the server
would have to be done both on FreeBSD and Linux to find out where the
differences are, exactly. It's probably more promising to directly
mess with the scheduler and randomly mess with it while observing what
happens to your client's performance.
==> However, you should try the ULE scheduler, instead of the 4BSD
scheduler. If you do, please report your findings back.
Also make sure that you don't use a giant-locked driver somewhere in
the chain to the filessystem and that WITNESS and friends are off. Is
this a SMP machine?
Martin
BTW, the situation is entirely different from the mysql situation
where we damage performance by using "the wrong" thread library by
default. Samba is not threaded and mysql performance is only to a
minor part network-bound.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061004021401.GA69704>