Re: Question

Hi,

What you have to remember is how the squid cache disks are used. There
are three places the space can go:

1) the cache itself. The size of the cache is governed by cache_swap_low
and cache_swap_high.

2) the swap files

3) temporary storage of cache objects. This is the one that bites me
occasionally. Even though the cache max object size is 4MB, if someone
loads a large file (eg CDROM image of 650MB) the cache disk fills cos I
only have about 250MB free on the cache file systems.

I used to get a lot of problems with the filesystem filling. Since I could
not change its size I finished up making cache_swap_low and
cache_swap_high a bit smaller. In doing so I had to make a decision with a
trade-off between

a) having a smaller cache (by virtue of reducing cache_swap_high) thus
leaving enough space for large downloads and

b) keeping the cache large enough to be effective without squid
complaining all the time about running out of space when someone
downloaded large files

I finished up leaving the cache size alone but reducing cache_swap_high to
90% although I think I did try 85% at one stage (the cache got too small
then).

Colin

On Tue, 2 May 2000, Stefano Di Giancarlo wrote:

> I try and better explain the situation:
> i have one 8 Gb disk dedicated to the cache;
> i have configured squid to use 6Gb (cache_dir ufs 6000 16 256)
> the cache squid exceeds 100% os disk utilization and stops with the following
> error:
>
> 2000/05/01 16:28:12| WARNING: Shrinking cache_dir #0 to 5549421 KB
> 2000/05/01 16:28:12| diskHandleWrite: FD 3: disk write error: (28) No space
> left on device
> 2000/05/01 16:28:12| storeDirWriteCleanLogs: Starting...
> 2000/05/01 16:28:12| WARNING: Closing open FD 5
> 2000/05/01 16:28:12| storeDirWriteCleanLogs: /cache/swap.state.clean: write:
> (28) No space left on device
> 2000/05/01 16:28:12| storeDirWriteCleanLogs: Current swap logfile not
> replaced.
> FATAL: Received Segment Violation...dying.
>
> I'd expect the squid not to use the 100% disk. Can you help me ???
>
Received on Tue May 02 2000 - 20:39:36 MDT