Re: squid2.3stable2 on freebsd3.2

From: Chris Dillon <cdillon@dont-contact.us>
Date: Tue, 18 Apr 2000 18:29:59 -0500 (CDT)

On Tue, 18 Apr 2000, Alejandro Ramirez wrote:

> From: "Chris Dillon" <cdillon@wolves.k12.mo.us>
> > On Tue, 18 Apr 2000, Alejandro Ramirez wrote:
> > > Yes, you have to disable memory pools in your squid.conf file
> "memory_pools
> > > off", enable truncate instead of unlinkd "--enable-truncate", do not
> enable
> > > the time hack "--enable-time-hack".
> >
> > Is there any particular reason you're turning off memory pools and
> > using truncate() instead of unlink()? I've not actually done any
> > benchmarks with using these options under FreeBSD, but I'd be
> > interested if anyone has.
>
> Quote from http://www.squid-cache.org/Doc/FAQ/FAQ-9.html#paging
>
> The meaning of ``swapping'' varies. On FreeBSD for example, swapping out is
> implemented as unlocking upages, kernel stack, PTD etc for aggressive
> pageout with the process. The only thing left of the process in memory is
> the 'struct proc'. The FreeBSD paging system is highly adaptive and can
> resort to paging in a way that is equivalent to the traditional swapping
> style operation (ie: entire process). FreeBSD also tries stealing pages from
> active processes in order to make space for disk cache. I suspect this is
> why setting 'memory_pools off' on the non-NOVM squids on FreeBSD is reported
> to work better - the VM/buffer system could be competing with squid to cache
> the same pages. It's a pity that squid cannot use mmap() to do file IO on
> the 4K chunks in it's memory pool (I can see that this is not a simple thing
> to do though, but that won't stop me wishing. :-).
> by John Line (webadm@info.cam.ac.uk)

Ok, this makes sense. :-) It might, in fact, make even more sense for
FreeBSD 4.x because of the improved VM system.

> Quote from /squid-2.3.STABLE2/configure file:
>
> --enable-truncate This uses truncate() instead of unlink() when
> removing cache files. Truncate gives a little
> performance improvement, but may cause problems
> when used with async I/O. Truncate uses more
> filesystem inodes than unlink.."
>
> And also a test made by Duane Wessels (wessels@ircache.net)
>
> http://www.squid-cache.org/Benchmarking/std1/2.2.stable3-unlink/

I'm not sure that this rather small performance improvement will be
realized when Softupdates is involved, but that would involve another
benchmark to find out. :-)

> I dont have a benchmark, but they have certanly increased the speed respose
> of my system, right now it handles 9,377 req/min (peak reported), in a 10Mb
> BW & 7,000 Cable modem surfers enviroment, it outperforms a lot better than
> 4 Cisco Cache Engine 550 together (Proved).
>
> > > For FreeBSD, enable SoftUpdates, mount the filesystem with the noatime
> > > option, rebuild your kernel without needed drivers, and use the
> following
> > > options in your kernel config file too:
> >
> > Softupdates are definately an advantage, as well as noatime.
> >
> > > makeoptions COPTFLAGS="-O2 -pipe" #Optimizing the kernel
> for
> > > the best performance
> >
> > Using -02 on a kernel is not a good idea. There are documented
> > problems with gcc generating bad code at these optimization levels.
> > Stick with no optimization, or just -O if you absolutely feel you need
> > some.
>
> FreeBSD 3.X doesnt come with an standard gcc in the base system, it has
> become the standard for FreeBSD 4.X, so the optimization bug its not present
> in the 3.X branch :o)

FreeBSD has been using gcc for quite a while. What FreeBSD 4 acquired
what was once known as EGCS and later merged with GCC. It currently
has GCC 2.95.2. 3.x has GCC 2.7.2.3. 2.2.x has GCC 2.7.2.1.
Various optimization problems have been around for quite a while in
GCC, and only seem to be worse in certain situations with the newer
GCC. :-(

-- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net
   FreeBSD: The fastest and most stable server OS on the planet.
   For Intel x86 and Alpha architectures. ( http://www.freebsd.org )
Received on Tue Apr 18 2000 - 17:33:25 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:52:59 MST