Re: Multiple storeio types?

On Friday 09 November 2001 07.51, Joe Cooper wrote:

> Quick query regarding the least load and UFS type. Is there a reason
> for choosing constant 999 for the loadav for that store type? I mean is
> it magic in some way that I'm not seeing? Could it just as easily be,
> say, 500? That's not a real fix, of course. A real fix doesn't look
> trivial (hence the reason it's returning a constant I guess ;-), as I
> don't see any way to gather the load that is sensible. But 500 might be
> more fair when used with other storedir types, and would behave the same
> as it currently does if all dirs are ufs type.

It needs to return something. As it cannot adjust with load I think a very
low priority was intentionally selected to make Squid prefer other stores
capable of load adjustments..

> Another query, that is somewhat related: Are the diskd and aufs loadav
> calculations 'compatible'? I guess it would take test data that
> probably doesn't exist yet to know since they both rely on somewhat
> arbitrary load indicators and both behave very differently based on
> those conditions.

Probably not entirely compatible. In fact both are most likely in need of
some tuning of the load algorithm to find the correct measurements and scales
on how to measure their load.

> If I find that least load is more efficient for my needs, I'm going to
> give a diskd storedir type a try on my RAM disk. Maybe lighter weight
> than 16 threads... Any thoughts on whether I'm misled in that assumption?

Should work.. the aufs store should also work. The amount of aufs threads can
be tuned to fit your needs.

But I think in all cases you need to spend some time on how you want to have
the load balanced. I guess there is a reason to why you are mixing a RAM disk
in the store with other types.

Regards
Henrik
Received on Fri Nov 09 2001 - 00:17:27 MST