DCC build options for performance and sizing

Gary Mills mills@cc.umanitoba.ca
Wed Jun 9 14:29:30 UTC 2010

On Wed, Jun 09, 2010 at 01:33:21PM +0000, Vernon Schryver wrote:
> > From: Gary Mills <mills@cc.umanitoba.ca>
> > The upgrade from dcc-1.3.122 (32 bit) to dcc-1.3.125 (64 bit) was
> > flawless.  However, we now have a problem with writes from dccd
> > saturating the disk.  The I/O bandwidth is often 100% utilized.
> > Other processes that need to read from the disk are stalling.
> >
> > This is Solaris 10 5/09.  Neither `-F' nor `-f' are specified in
> > dcc_conf.  Can I add `-f' someplace to get memory mapped I/O?  Does
> > this have to be specified for dbclean separately?  Where's the best
> > place?
> If the system has enough RAM to contain the hash table of dcc_db.hash
> and the recent part of dcc_db, then the best tactic is the work-around
> for Solaris's lack of mmap(MAP_NOSYNC).  That -around is to move
> dcc_db.hash (but of course not dcc_db) to a memory mapped file system.
> /tmp is often a RAM file system on Solaris systems, so adding -H/tmp
> to DBCLEAN_ARGS in dcc_conf should be effective.

Yes, I read about that.  I was reluctant to change so many things at
the same time.  It's not a good idea for system processes to create
files in /tmp because that's a publically-writable directory.
/var/run is a better choice.  The startup script would have to create
/var/run/dcc, for example, and make it owned by the DCC user.  I assume
it doesn't already do that.

The servers do have sufficient memory.  I'll do some testing to see if
`-H/var/run/dcc' solves the problem.

-Gary Mills-        -Unix Group-        -Computer and Network Services-

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.