Re: Squid memory footprint (was: MemPools rewrite)

On Thu, Nov 02, 2000, Andres Kroonmaa wrote:
> On 2 Nov 2000, at 16:09, Adrian Chadd <adrian@creative.net.au> wrote:
>
> > On Thu, Nov 02, 2000, Andres Kroonmaa wrote:
> > >
> > > I wonder how can you eliminate StoreEntry? IMHO it contains crucial
> > > information that allows squid to skip disk accesses. Moving parts
> > > of this data into squidfs doesn't seem to change much in ram usage.
> > > Moving this crucial information onto disks implies enormous performance
> > > penalty, doesn't it?
> >
> > You are assuming the FS can't handle object reference / lock counts and
> > freshness information itself. :-)
>
> I think I'm assuming that the FS needs to keep freshness data, and
> key->diskobject translations in ram, along with overhead for maintaining
> replacement policys (refcount, locks).
> Sure we can reduce amount of pointers per each object in store db, but
> unless we accept disk access penalty, we need to keep lots stuff per
> object in ram.
> I'm simply assuming that we move most of this stuff from StoreEntry db
> into FS metadata.

Well, an example here is that you don't need to keep all the MD5
hashes in RAM if you're going to map an object's MD5 hash to a disk
position, like reiserfs_raw does (well, whatever hash it uses ..)

Another example is that for some storage systems, you don't need to
maintain a strict list for replacement policy. This removes the need
for the repl_policy stuff in memory.

I could go further .. :)

Adrian

-- 
Adrian Chadd			"God: Damn! I left pot everywhere!
<adrian@creative.net.au>	  Now I'll have to create Republicans!"
				    - Bill Hicks