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- _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
