Re: largest deployment?

From: Dancer <[email protected]>
Date: Wed, 22 Apr 1998 05:27:18 +1000

Bill Wichers wrote:
>
> Just a quick little question for you guys:
>
> How are you handling the logs? I'm curious if Squid's writing of the
> access.log, cache.log, and store.log becomes a bottleneck on large heavily
> used caches.

I don't doubt that they _can_, but they never have. Unbuffered logs are
what we use. The default, unmodified behaviour. Mind you, we have a ton
of memory available, and linux cheerfully buffers a lot of disk-ops with
it.

> My concern is that on a really fast cache (with a bunch of nice UW SCSI
> disks or maybe a RAID) that the logs will limit the cache's performance
> becuase the system disk won't be able to keep up with the cache disk
> array. I've asked questions like this before but never really got much of
> an answer...

That can happen, IMO (but not so far IME). Debate did rage through the
local halls at one point as to whether buffered or unbuffered logs were
the way to go. A constant trickle? Or a lump all at once? (Eh, I use-ta
have-a dot trobule, but I drink a big-a glass a warm-a salty water, an'
it go away, like-a dat!)

We promised ourselves that if we ever bottlenecked on log-i/o we'd try
doing it the other way.

D

>
> -Bill
>
> On 21 Apr 1998, Michael O'Reilly wrote:
>
> > Dancer <dancer@brisnet.org.au> writes:
> >
> > > 34GB/server, split across half a dozen drives, sharing by squid (no
> > > raid). No problems with the ext2 file-system so far. Bearing up nicely.
> > >
> > > D
> >
> > Ah, just edge you out. :) 38 gig, P-II 266, 512meg ram, running
> > squid1.2. Handing peak loads of 150 tcp/second, 60 min averages in the
> > 50 tcp/second.
> >
> > Michael.
> >

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ 
------END GEEK CODE BLOCK------
Received on Tue Apr 21 1998 - 12:45:21 MDT

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