Gary, On Wed, Jun 09, 2010 at 09:29:30AM -0500, Gary Mills wrote: > 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.
With 64bit Solaris-9, using /tmp has worked very well for me, and solved the disk I/O saturation problem. dccd is hovering around 6.6GB RAM, plus the 2GB for the tmpfs dcc_db.hash file. Mark -- Mark G. Thomas ([email protected]) Web: http://mgtinternet.com/ Tel: +1-215-512-0112 US: 877-512-0112 _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
