On Mon, Mar 20, 2000, Duane Wessels wrote:
>
>
> On Tue, 21 Mar 2000, Bert Driehuis wrote:
>
> > My Squid proxies have too much disk space. The Squid process runs out
> > of memory well before the referenceAge kicks in. With disks so cheap
> > and memory so expensive, this is a situation that many administrators
> > find themselves in.
> >
> > I wrote the attached diff just to see if it is workable to scan the
> > object store at regular intervals to see if small objects can be ditched,
> > freeing up memory, while still allowing the referenceAge mechanism to
> > get rid of the bigger objects. In polygraph testing it seems to
> > work. Where the Squid process would run out of memory it now keeps on
> > running (I don't have byte hit rates yet).
> >
[snip]
> >
> > Ideas? Have I just reinvented a wheel? Has it been tried before and found
> > to be stupid? I must admit I haven't looked much at the current Squid; I
> > needed a solution I can roll out at pretty short notice and didn't want to
> > deviate too much from the rock solid 2.2.STABLE5-hno.20000103 I'm running
> > right now.
>
> I didn't look at the code yet, but my first reaction is that
> this belongs as a replacement policy. An extra scanning event
> may be expensive. Wouldn't it be better to have a single policy
> that favors large files over small ones, and combines the size
> with other parameters such as age, refcount?
>
Yes, it should be a replacement policy, and I haven't looked at the
code yet either.
Once I've finished up the fs tidyup, you will definitly want
this to be a replacement policy, as non-UFS filesystems (eg
COSS) will not like this. :-)
Adrian
Received on Tue Mar 21 2000 - 09:09:53 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:22 MST