On Wed, Jun 09, 2010 at 01:33:21PM +0000, Vernon Schryver wrote: > > From: Gary Mills <[email protected]> > > > 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.
Yes, I read about that. I was reluctant to change so many things at the same time. It's not a good idea for system processes to create files in /tmp because that's a publically-writable directory. /var/run is a better choice. The startup script would have to create /var/run/dcc, for example, and make it owned by the DCC user. I assume it doesn't already do that. The servers do have sufficient memory. I'll do some testing to see if `-H/var/run/dcc' solves the problem. -- -Gary Mills- -Unix Group- -Computer and Network Services- _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
