Re: [squid-users] Re: Squid 1.2 formats and other Q's.

From: Chris Tilbury <Chris.Tilbury@dont-contact.us>
Date: Mon, 14 Sep 1998 10:41:29 +0100

On Sun, Sep 13, 1998 at 09:18:18PM +0200, Henrik Nordstrom wrote:

> Umar Goldeli wrote:
>
> > Also, does anyone recommend using software RAID0 on Linux
> > (Squid 1.2) for a 40Gb cache? Or just use the separate cache_dirs
> > on separate physical drives and that'll be adequate?
>
> To early to tell. Currently one RAID0 may be faster due to less memory
> use, but Squid may be smarter as things evolve and then multiple
> cache_dirs should be faster.

Of course, one very important thing to remember here is that squid, like
other proxy caches, is _very_ disk-write intensive. This is the main area in
which Web caches differ from Web Servers.

Many performance gurus recommend using a RAID0 stripe with suitable
interleave to gain optimal disk read performance from a cluster of disks.
However, this doesn't help the write situation that much.

What _will_ help this is some mechanism for generating better ordering of
write requests to the disks. Usually, this involves using NVRAM (if you have
lots of money and an expensive disk subsystem or high end Sun server) or
some kind of transaction log, on a dedicated disk.

This is the approach we're taking here, with a 12Gb cache (small by your
standards, Umar!), made up of 6x2Gb striped disks with a log on another
dedicated disk (2Gb, but the log is a fraction of the total disk).

> Another thing you should consider is fault tolerance. If you use
> multiple cache_dirs then you can quickly replace (or reove) one drive
> when it fails, without loosing the cache contents on the other drives.

This is, of course, something that isn't addressed by either a transaction
log or a stripe. You'd need to make a logged, mirrored, stripe. This is
going to be quite expensive in terms of hardware.

A transaction log will help if the machine crashes, though, since the O/S
probably won't need to perform a full check on the sanity of the logged
filesystems (since it can, in essence, replay the log to get them into a
sane state). This will get you back up and running much more quickly if you
have a very large filesystem.

Cheers,

Chris

-- 
Chris Tilbury, UNIX Systems Administrator, IT Services, University of Warwick
EMAIL: cudch+s@csv.warwick.ac.uk PHONE: +44 1203 523365(V)/+44 1203 523267(F)
                            URL: http://www.warwick.ac.uk/staff/Chris.Tilbury
Received on Mon Sep 14 1998 - 02:43:07 MDT

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