dbclean memory utilization

Vernon Schryver vjs@calcite.rhyolite.com
Thu Feb 18 18:30:41 UTC 2010

> From: Ross West 

> (I've attached a .png file that shows what I'm talking about - the
> system has 4gig, running freebsd 7.2/amd64, dedicated to dcc .116 with
> default settings)

I suspect `mailman` trimmed the .png file.

> We've noticed that while cron-dccd runs the dbclean process nightly,
> that it'll utilize a large amount of memory while rebuilding/cleaning
> the dccd database. The dccd process uses (on our system) roughly 2.5g
> of memory normally, and the dbclean process can take an additional 1
> to 2gig at points.
> Normally not an issue, but we've caught the system once or twice
> (usually a week after a large influx of hashes that need to be
> cleaned) touching swap, which in turn causes a huge change in system
> dynamics - dbclean's execution time goes from like a minute to an
> hour+ due to the swap churn.
> Of course the real answer to this is "more physical memory" :) , but
> I'm looking at other possible temporary fixes in the meantime. So a
> couple of questions that cropped up:
> - Would the removal of the swap memory cause dbclean any hardship?

I do not understand "removal of the swap memory."  Removing or shrinking
the disk partition or file use as backing store for RAM seems irrelevant.

If "swap memory" refers to a "memory-mapped" or "swap file system" such
as /dev/shm on Linux, /tmp on Solaris, or a tmpfs filesystem on some
BSD flavors, then perhaps it would help.  A system thrashes when it lacks RAM
for the sum of the working sets of running programs.
Devoting a lot of RAM to a filesystem might reduce the RAM available
to programs.
For years I've noticed that Linux is particularly vulnerable to thrashing
with the DCC database.

For years I ran the DCC server with ID 101 on 32-bit FreeBSD 6 and 7
with 4 GBytes of RAM less the cursed, nearly 500MByte wasted for the
PCI I/O window.   Dbclean never needed hours, despite running other
things including the master HTTP server for www.rhyolite.com.  So
something else must be involved, such as a large tmpfs file system,
perhaps for /tmp.

The opposite tactic of using more swap file system space might 
be better if Linux or Solaris instead of FreeBSD were involved.
Version 1.3.120 lets the /var/dcc/dcc_db.hash file be in a memory-mapped
file system.   See the CHANGES file at http://www.dcc-servers.net/dcc/CHANGES
and the dbclean man page at

> - Would temporarily shutting down dccd while dbclean does it thing and
> then restarting it cause any weird issues due to the db being
> reloaded? (There's a second server that takes the clients' load at the
> time, so I'm not worried about that)

I doubt that would help, because before start work, dbclean tells
dccd to unload its mapped pages and mostly shut down.
See the memory footprints of dccd and dbclean, perhaps with something like
`top -s1`.  The 'm' command to `top` on FreeBSD is handy for seeing
which processes are causing a lot of I/O, including paging.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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