RE: [squid-users] Cache_dir size considerations

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 17 Mar 2010 22:21:35 +0000

On Wed, 17 Mar 2010 15:43:28 +0000, "GIGO ." <gigoz_at_msn.com> wrote:
> Well i want to make sure that my settings are optimized and want to
learn
> more about the cache_dir settings.....let me come in details
>
>
> I have installed squid3stable24 on Ubuntu 8.04 on IBM 3650 X series
server
> with two hard disks on which physical RAID1 is implemented. I am to use
the
> Squid Server for 1000 users out of which 250 are power usrs rest of them
> are normal users for which there are many
> restrictions(youtube,facebook,msnmessgenger,yahoomessenger,mp3mpg
etc...).

My experience with RAID1 is that it nearly halves Squid throughput speeds.
Your mileage may vary, others have certainly seen better results than I
with RAID.
But nothing beats a JBOD setup using fast disks with Squid for
performance.

>
> I have done my settings specifically to ensure that windows updates are
> cached and my maximum_object_size is 256 mb. Also i am looking forward
to
> cache Youtube content(for which i have no updated script and settings so
> far the one on internet is with storeurl directive which is
> depricated).......
>

Not deprecated, just not ported. It was added to 2.7 as an sponsored
experiment. And the author never got it into 3.x releases. When somebody
has the time or money to do so it will happen.

>
> Now my cache directory size is 50 gb with 16 L1 and 256 L2. I think
better
> would be
>
> Cache_dir_size aufs 50 GB 48(L1) 768(L2)
>
>
> as far as L1 & L2 settings i am clear that there should be no more than
> around 100 file in L2 directories so one's settings should be adjusted
> accordingly. However i am confused that if setting your cache (50gb) of
too
> large a size will have anything to do with your performance. Secondly at

More disk cache size means; more RAM needed to index it, more time delays
when purging old content, etc.

The L1/L2 cache structure is fixed level, so no matter what numbers you
plug in there is always 3 IO lookups to open a file (L1 dir + L2 dir + file
open).
Increasing either L1/L2 merely spreads the files thinner over the
directory structure, and is a good thing for most FS in use today.

> the moment the cache directory is implemented on the same hard drive on
> which OS is installed. I know that cache should be better moved to a
spare
> hard drive. But what about the highavailability? Failure of a disk cud
> result in the failure of proxy?

Yes it could. Always a risk when dealing with hardware. I just had a box
go down 21st Feb because one of its RAID1 drives gave out and mirrored
corruption to the others. eck.

Having the cache on a second disk reduces the impact if one or other dies.
Cache disk *is* going to get thoroughly "thrashed" by Squid from an IO
view, expect it to fail earlier than the OS disk just from the type of
usage. Being able to replace that disk without the OS going down is a good
thing. Also note the scale of days/weeks out of years for this type of risk
is long-term.

>
> Another confusion which i have is that what about the
cahe_effective_user
> i hav set my user
>
> cache_effective_user proxy but i dont have much concepts about it. I
have
> read on SAN institute site a white paper published 2003 that squid
should
> not be run as nobody user but as a sandbox user with noshell. However i
am
> not sure what is it all about and whether this informaiton is still
valid
> after 7 years have been passed.
>
> Please also guide me that what are the risks involved with this setting
> which i have done for windows update:
>
> range_offset_limit -1
> maximum_object_size 256 MB
> quick_abort_min -1
>
>
> Further after giving squid too many longs list of blocked site say
> containg 100+ sites. I have noticed that its slowed down however i am
not
> sure that if it is the reason? please guide......

Usually using regex causes slowness. Followed by other ACL design
mistakes.
But without details of your list and how its configured we can't really do
more than guess.

Amos
Received on Wed Mar 17 2010 - 22:21:39 MDT

This archive was generated by hypermail 2.2.0 : Thu Mar 18 2010 - 12:00:04 MDT