802 copies of dccm running

Gary Mills mills@cc.umanitoba.ca
Sun Dec 31 01:06:07 UTC 2006


On Mon, Dec 18, 2006 at 02:56:44PM -0700, Vernon Schryver wrote:
> > From: Gary Mills 
> 
> > Reverting to the old configuration brought it back to normal.  I'm
> > using dcc-1.3.31.  Might this work better in a later version?
> 
> The next version, 1.3.46, will be more agressive in shutting down
> unneeded helper processes.  It will also have -Bset:maxjobs=X to override
> the default limit on the number of helper processes.  The default is
> the same as the -j value.
> 
> I think the current version, 1.3.45, has some fixes related to helpers
> waiting too long for DNS answers.

Okay, I did some upgrades: from bind-8 to bind-9 and from dcc-1.3.31
to dcc-1.3.45.  `named' and `rbldnsd' are running on the same server
as DCC, sendmail, and Cyrus IMAP.  When I tested DCC's DNS blacklist
today, a very quiet day for e-mail, I noticed that the number of `dccm'
processes increased steadily with no sign of leveling off.

I have a script that summarizes `ps' output by process name, showing
total CPU percentage and number of processes for each.  Here's how it
looked about 1/2 hour after starting the test:

 10:51am  up 55 day(s), 1 hr(s),  5 users,  load average: 0.34, 0.46, 0.50
%CPU    NUM     COMM
5.4     186     imapd
1.7     1       fsflush
1.4     1       /opt/bind9/sbin/named
1.2     97      /usr/lib/sendmail
0.7     37      pop3d
0.7     19      /usr/local/dcc/libexec/dccm
0.2     2       /usr/local/dcc/libexec/dccd
0.2     2       /opt/local/mysql/libexec/mysqld
0.2     1       saslauthd

Here it is about three hours after the start:

  1:28pm  up 55 day(s),  3:37,  5 users,  load average: 1.98, 1.77, 1.52
%CPU    NUM     COMM
2.4     313     /usr/local/dcc/libexec/dccm
2.2     234     imapd
2       96      /usr/lib/sendmail
2       1       /opt/bind9/sbin/named
1       1       fsflush
0.9     31      lmtpd
0.5     36      pop3d
0.2     2       /opt/local/mysql/libexec/mysqld
0.1     7       /bin/sh

Notice that the number of `dccm' processes now greatly exceeds the
number of `sendmail' processes.  Most of those correspond to incoming
SMTP connections.  I also watched the number of threads used by the
main `dccm' process.  It was generally 50 or less.  `named' used seven
threads throughout.

I stopped the test at this point because it would surely run away in
time, or when the system got busy.  Why are all those `dccm' processes
even needed?

-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-



More information about the DCC mailing list

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