DCC build options for performance and sizing

Vernon Schryver vjs@calcite.rhyolite.com
Thu Jun 10 01:46:18 UTC 2010

> From: Gary Mills <mills@cc.umanitoba.ca>

> > The servers do have sufficient memory.  I'll do some testing to see if
> > `-H/var/run/dcc' solves the problem.
> Well, that was dramatic.  On one of my production DCC servers, the I/O
> bandwidth dropped from 50% utilized to zero.  For your amusement,

Their lack of mmap(MAP_NOSYNC) make Linux and Solaris much slower
DCC servers than FreeBSD or NetBSD.  The default hyperactive Solaris
mmap() page flushing that required `dccd -F` makes Solaris even
worse than Linux.  A RAM file system for dcc_db.hash mostly fixes
both Linux and Solaris for dccd.

Judging from their graphs on the server status web page, I suspect only
one of the two umanitoba.ca servers is running a 64-bit dccd, and that
the larger pointers let dccd take advantage of the more than 4 GByte
of RAM on the system.  That forced the dccd buffer page or chunk size
to be twice as large or even larger.  The active hash table entries for
the same number of flooded or local transactions are spread among twice
as many bytes.  Either or both effects caused twice as many bytes to
be flushed to the dcc_db.hash file.

The graphs for server names in bold on the server status page are
visible to other operators.  Follow the link in the first column.
Operators who didn't see the same note in the DCC-servers mailing list
and who are willing to let other operators see the graphs of their
servers can contact me.  Also contact me if your user name and password
for the server status web page have been lost.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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