RE: [Fwd: Optimizing Squid performance]

> -----Original Message-----
> From: Athanasios Kouroussis [mailto:akouroussis@unifon.com.ar]
> Sent: Tuesday, 8 August 2000 8:10 AM
> To: Duane Wessels
> Cc: squid-users@ircache.net
> Subject: Re: [Fwd: Optimizing Squid performance]
>
>
> Thanks for the prompt reply:
>
> 1) Top or free report 3 of 512Mb of physical memory free.
> Only 40Mb of swap
> space used.
> 2) Why do not use raid if it controlled by hardware. I can
> understand not
> using software RAID or RAID 5 with a poor controller but the
> RAID controller
> of this box is a Smart-2 3200. Anyway, what do you
> recommend. How should I
> set up the partitions (size, fs, etc) for max perf. Any
> other, squid related
> parameters I should tweek?

RAID 5 incurs a read-write overhead regardless of software or hardware
implementation. It can be up to 1/4 the speed of a striped no-parity
configuration.

The reason is that for every stripe, a write anywhere to the stripe
requires:
A) read the stripe block BLOCK-A(up to 64K on most controllers) that
contains logical blocks that are being written to.
B)read the parity stripe block for that stripe. (same size as A)
C) remove the old BLOCK-A from the parity value
D) add the new BLOCK-A to the parity value
E) write the new BLOCK-A to disk
F) write the new parity block to disk.

As you can see a single write of 2K (say a small.gif) will require 2
head reads (1 each on two of the array disks) and 2 writes (back to the
same sector).

Whereas mirroring or striping no-parity require only two writes
(mirroring) or 1 write (no parity striping).

So we won't use RAID 5 for high-performance applications.

For cache data where you probably don't care about the data itself,
having multiple independant disks means that if a failure occurs, squid
can stop using that disk rather than you losing a full stripe, and you
don't need to pay the 100% overhead of mirroring.

Rob

> 3) May that is the reason.. I will check it and let you know.
>
> Thanks,
>
> Athanasios Kouroussis
> Unifon - T.C.P. S.A.
> akourousssis@unifon.com.ar
>
Received on Mon Aug 07 2000 - 18:44:59 MDT