Samba logs and locks in tmpfs filesystem (Solaris)?

[David Lee]

Solaris 2.8;  E450 (2 CPU, 3GB)
Samba 2.0.7, 2.2.1a, 2.2(CVS): several hundred simultaneous connections

With the gradual return of staff and students for a new university year,
and an increasing number of concurrent connections (several hundred) on
our main fileserver, we have hit some load problems.  When the load
average exceeded 2 (on a 2*CPU machine) we often saw it rise rapidly, so
that the machine was almost unusable, until we restarted Samba.  An
avalanche effect. 

We had been at 2.2.1a .  Jeremy Allison and Gerry Carter were very helpful
to us and, by agreement, we tried the CVS version of 2.2 .  This fixed a
major problem: runaway "fcntl" processes had been a major trigger for this
behaviour.  But the underlying latency for avalanche still remained. 

Sadly, the pressures of service meant we were unable to debug it "live" 
(although we have speculated on a possible timeout-related cause, and I
hope to try to emulate and debug the problem on a much smaller test server
during the next few weeks).

So we backtracked to the more efficient code in 2.0.x.  This eased matters
greatly.  But now even more folk are here, applying more load:  we are up
to 700+ simultaneous connections (and envisage pushing towards 1,000).
We are still seeing this avalanche effect, even under 2.0.x.

Part of our speculation about 2.2.x code was contention for the tdb
databases.  Under 2.0.x, of course, it is not "tdb", but there is an
equivalent file "STATUS..LCK" for connections, for which there could still
be contention.  We seem to get of the order of one connection request per
second, sustained, on top of the load emanating from within the
connections themselves.) 

It crossed my mind that all this "tdb" (or "STATUS..LCK") activity, and,
indeed, even the logging activity, doesn't actually have to be done on a
real disk-based filesystem.  It could actually be done in a "tmpfs"
filesystem (the Solaris name for a pseudo-filesystem based in memory/swap,
typically used for "/tmp" itself).

Can anyone see any drawbacks?  I have had it running for a few hours now
on our main fileserver, and it seems to have eased things.  (The only
thing that I can see that we would lose is survival of log files across a
reboot, but by a suitable "log file" I could adjust that...)

So: Any thoughts on using tmpfs for such things?


-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :