Re: squid2.3stable2 on freebsd3.2

> 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. :-(

I was confused about this, but I havent had any problem at all with this
optimization flags, along with taking out the line "options FAILSAFE", in
the kernel config file, and the server did worked faster.

BTW Also you can tune the FS (with tunefs -m) to always be optimized for
TIME instead of SPACE, to gain another little performace improvement.

Greetings...
Ales
Received on Tue Apr 18 2000 - 17:51:24 MDT