DCC build options for performance and sizing

Vernon Schryver vjs@calcite.rhyolite.com
Wed Jun 9 13:33:21 UTC 2010


> 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.

There is no need to shut down dccd.  Just add (or remove) -H/tmp
to dcc_conf and run dbclean, perhaps by running cron script,
/var/dcc/libexec/cron-dccd

The main side effect is to require running dbclean to rebuild the hash
table whenever the system is rebooted.

See -H in the dbclean man page,
the mention of `dbclean -H` among the CHANGES file notice for 1.3.120,
and http://www.google.com/search?q=mmap+MAP_NOSYNC


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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