This should really be in the FAQ. 

I've answered it for a few people previously.


The problem seems to be due to the vagaries of the file system

you might be using, and the fact that squid seems to count the 

total cached objects size, rather than the total space used 

by the file system.


I've found this method more successful. 

Set squid.conf for low and high -

 

cache_swap_low   99

cache_swap_high 100


Then start your cache drives at 80% of what you would expect,

and then adjust them up until you end up with an df 'available'

figure that you're happy with. I've ended up with 60 meg free on

each of my three drives. I don't think you should go much lower,

as sometimes large objects will eat into that space, on a 

temporary basis.


To speed things up, don't forget to mount your drives with 

/bin/mount -o noatime /dev/sda1 /usr/local/squid/cache1  

or similar.


If using e2fs, you can also claw some space back with 

-m reserved-blocks-percentage

Specify the percentage of reserved blocks for the super-user.  

This value defaults to 5%.


No doubt there are better explanations than that. 

But I've found that method works best for me. 


cache_dir /usr/local/squid/cache1 1800 16 256

cache_dir /usr/local/squid/cache2 1800 16 256

cache_dir /usr/local/squid/cache3 4560 16 256


[reyntech@proxy etc]$ df

Filesystem         1024-blocks  Used Available Capacity Mounted on

/dev/hda2             169819  128385    32664     80%   /

/dev/sda1            2028862 1868388    55588     97%  
/usr/local/squid/cache1

/dev/sdb1            2028862 1858912    65064     97%  
/usr/local/squid/cache2

/dev/hdc1            4838664 4730422    58148     99%  
/usr/local/squid/cache3


Cache Manager menu 


Store Directory Statistics:

Store Entries          : 618300

Maximum Swap Size      :  8355840 KB

Current Store Swap Size:  8278459 KB

Current Capacity       : 99% used, 1% free


Store Directory #0: /usr/local/squid/cache1

First level subdirectories: 16

Second level subdirectories: 256

Maximum Size: 1843200 KB

Current Size: 1827082 KB

Percent Used: 99.13%

Filemap bits in use: 138907 of 307200 (45%)

Flags: SELECTED


Store Directory #1: /usr/local/squid/cache2

First level subdirectories: 16

Second level subdirectories: 256

Maximum Size: 1843200 KB

Current Size: 1817679 KB

Percent Used: 98.62%

Filemap bits in use: 136758 of 307200 (45%)

Flags: SELECTED


Store Directory #2: /usr/local/squid/cache3

First level subdirectories: 16

Second level subdirectories: 256

Maximum Size: 4669440 KB

Current Size: 4633698 KB

Percent Used: 99.23%

Filemap bits in use: 342598 of 778240 (44%)

Flags:


At 12:15 15/03/99 +1000, you wrote: 

>>>>

<excerpt><smaller>Hello there,

</smaller>  

<smaller>We are an ISP and have been running a SQUID proxy server for
quite a while now... and recently built a new Proxy server with the specs
below:

</smaller>  

  

<smaller>Intel PII 350

320M SDRAM

Quantum 18.2Gb SCSI Drive

Linux 2.2.1

SQUID 2 [PATCH 2]

</smaller>  

  

<smaller>But the other night the proxy reached 95%, and was supposed to
start heading towards the "low-water-mark" of 90%, but this was not to
be... as it kept on going to 100%, and squid ceased to function.

</smaller>  

<smaller>My configuration is pretty much standard... except that I have a
cache of 17Gb set aside.

</smaller>  

<smaller>This base configuration has worked fine in previous servers that
we have had... and it correctly reduced itself when it hit "the limit"...
so could someone please shed some light on the matter.

</smaller>  

  

  

<smaller>Regards,

</smaller>  

  

  

<smaller>Peter Nott

RockNet ISP

</smaller>  

  

<smaller>I have had squid 

</smaller>

</excerpt><<<<<<<<






.----------------------------------------------.------------------------.

| Mark Reynolds <<mark@rts.com.au>              | Phone  08 9474 1211    |

| Network Manager, Reynolds Technology Pty Ltd | Fax    08 9474 4772    |

| 8 Preston Street Como 6152 Western Australia | Pager  08 9480 5884    |

| PO Box 120 Como 6952 Western Australia       | http://www.rts.com.au/ |

`----------------------------------------------^------------------------'


"January 1, 2000 falls on a Saturday, and Monday is a public holiday. This

means that we will have lots of time to fix the problem over the weekend!"