Re: solaris 7 & squid

 
> > > > the cache filesystems are mounted with the "noatime" option. /etc/vfstab
> > > > entries for cache filesystems look like so:
> > > > /dev/md/dsk/d3 /dev/md/rdsk/d3 /var/cache1 ufs 2 yes
> > noatime
> > >
> > > I think you will find slightly better performance if you also enable
> > > logging on your UFS filesystems, but I have not studied Solaris 7 UFS
> > > logging in detail.. Comments on Solaris 7 logging UFS welcome.
> >
> > this isn't something i've looked at. squid is performing extremely well
> > & i'm not inclined to "fix it" 8-)
>
> UFS logging is (refer to docs.sun.com, if in doubt) speeding only the boot
> process, especially after a dirty shutdown. Since I have heard of bad
> experiences using the meta devices with squid (and/or innd), you may want
> to determine, if you are not better off with squid doing the load
> balancing on the pure (cXtYdZsW) disk partitions...
>
> There is also a logging facility in the meta disk drivers. I haven't
> looked on the performance of that, but you are aware that the MD logging
> should go to a disk of its own and nothing else should be on it - even, if
> you are only using 100 MB of a 4 GB disk, see Cockroft.

we're not using md logging. the md devices used for the cache partitions
are just configured as one-way mirrors for consistency in configs. so
the md devices are fairly benign & effectively work as straight UFS partitions.
the disks we're using are 4G fast-wide scsi & live in a sparc storage array. the
storage array has 16M of memory cache which is great for improving write perf.
 
> > > > in /etc/nscd.conf:
> > > > suggested-size hosts 1001
> > > > this figure was found after numerous looks at the output of 'nscd -g'.
> > > > nscd hit rate is generally around 99%.
> > >
> > > Unless they have changed nscd to a multithreaded implementation in
> > > Solaris 7, it will be a performance killer for DNS lookups.
> >
> > nscd is threaded in solaris 7.
>
> I have heard rumours that it is still using one single (eye of the
> needle) lock for name resolution, so all threads funnel through one
> lock.

hmm. i did some tests running squid with both nscd on & off.
squid reports lower DNS query times with nscd host caching turned on. this may
be a quirk of our site as squid handles a lot of requests to a few
internal sites. i have no idea if these figures are "normal" btw.

anyway with nscd host caching turned on:
Median Service Times (seconds) 5 min 60 min:
        DNS Lookups: 0.04854 0.04313
& with nscd host caching disabled:
        DNS Lookups: 0.17048 0.06657
        
& presumably a single lock would only be needed for writes not for reads?
if 99% of all host lookups are found in nscd host cache then running nscd would
be a win if the nscd door interface is quicker than interfaces used by
other host resolution mechanisms?
 
> Since you are running a bind, you may want to look into the bind
> documentation: There should nscd interaction be mentioned in there. Due to
> past experiences, when installing servers I *always* disable at least the
> host lookup part of nscd (usually I disable it completely). Currently, you
> are ending up caching host names in three different places, bind, nscd and
> squid.

yep, i've found nscd impacts perf. for older versions of solaris & i normally
disable it/turn it off also. i've not seen the same problems with 2.7 as yet.
& running three caches doesn't seem to be a problem with our config.

cheers,
pauline
Received on Mon Dec 13 1999 - 17:49:25 MST