Re: [squid-users] best practices for squid

sön 2007-01-21 klockan 21:11 +0100 skrev Marco Barbero:

> cache_dir:
> ----------
> - SquidBook says about 20MB for every user accessing the proxy

I don't have a number on that. The rule 10MB per GB of cache_dir + OS
requirements and cache_mem usually works out quite well.

> - A lot of people suggest to monitor total traffic for a week and use this
> value for cache_dir

More accurately a week's worth of cache_dir. The size cache_dir grows to
after a weeks operation. Beyond that there is very limited benefits from
growing the cache further and the remaining memory is perhaps better
used as cache_mem.

> - the book "How To Accelerate Your Internet" (bwmo.net) says that size
> higher than 18GB are not a good choice

It's nearly impossible to place an exact number. It depends on the
amount of traffic.

> - cache_dir placed on a dedicated disk must be 20% smaller than total size
> (squid.conf). Some people suggests 30-50% smaller....What about?

Most UNIX filesystems requires at least 20% free space at all times to
operate properly. If the filesystem is filled beyond that performance
starts to degrade due to fragmentation.

> And then...are these suggestions valid for dedicated partition too?

The filesystem fill limit is unchanged if it's a shared or dedicated
partition.

I always recommend dedicated partitions for the cache if you cannot have
dedicated disks. This because there is a lot of data moving in the cache
directory, and should there be a filesystem problem due to a power
failure or similar it's not a major disaster if the cache is lost.

If you can it's better to dedicate disks to the cache. This gives better
performance. The system disk can be used for logs and swap.

> - L1 value:
> cache_dir/416 (old post from Henrik)
> cache_dir/500 (other post read here)
> cache_dir/256 * 0.6 (a more recent post from Henrik)
> Opinions?

They are all about the same.

> -L2 value: 256
> Duan Wessel suggest to try 32/512 with great cache_dir sizes.
> ??

I suggest sticking to 256. But it's no big deal. If you increase L2 you
should also decrease L1. The cache structure can be defined by the
equation N = L1 * L2 * L2 * 2, where N is the number of cached objects.
A too small L2 degrades performance due to the directory blocks not
being fully utuilized. A too large L2 degrades performance due to
directory lookups being more expensive. And a very large L2 has negative
impacts on Squid cache maintenance even if you use a filesystem which
handles very large directories fine.

It all sums up to 256 being a quite reasonable balance for most OS:es.

> ufs/aufs
> -----------
> -ufs with less than 5req/sec (Duan Wessel)
> -aufs for >30req/sec (Henrik)
> ??

ufs won't realistically sustain more than about 30req/s and above that
you must use aufs.

but aufs adds a bit of overhead, and for very low load <5req/sec you may
be better suited using the trivial ufs implementation. This is less
significant in never versions (2.4 or later I think).

> cache_mem
> -------------
> - Squidbook says: never greater that 1/4 physical RAM.

Yes.

> - Henkrik says 16 MB is quite suitable for most installations (no more than
> 32MB)

Yes.

> - Duan Wessel says to set it low than increase if there is RAM unused.
> ??

Yes.

> What do you think about?

All true. And no conflict.

* Never set cache_mem larger than 1/4 of the physical ram
* Start with the default 16MB, or maybe 32MB.
* If you when the cache has been filled find you have a lot of ram
unused then maybe increase cache_dir further. But only if there is a lot
of ram free. The OS also requires a fair bit of memory for filesystem
and networking buffers.

Regards
Henrik