Newsgroups: news.software.b
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: expire oink
Message-ID: <1990Aug30.162009.2017@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <1990Aug19.202420.140@m2xenix.psg.com> <1990Aug21.154310.20719@zoo.toronto.edu> <1990Aug22.165739.6918@lethe.uucp> <49312@olivea.atc.olivetti.com>
Date: Thu, 30 Aug 90 16:20:09 GMT

In article <49312@olivea.atc.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes:
>... Expire runs very fast with the dbz INCORE option
>but it uses many megs of memory.  The original poster claimed it was
>using 11 meg...

11MB is just plain wrong unless you've got a colossal history file; the
size of the in-core table for utzoo (28 days of history) is about 800KB,
and other memory demands ought to be relatively minor.  If expire is
growing to multiple megabytes, there is a serious bug somewhere, either
in expire or in your system's memory allocator.  Given that expire used
to run quite happily on a 16-bit machine here, I suspect the latter.

>I would assume that dbz has a fairly random access to the incore
>memory.  That is going to be swap nightmare...

It's quite random, but for 800KB that should not be a disaster on a
system with a reasonable amount of memory.  If you're running dbz version
3 (the one distributed with C News), you can find out the exact size of
the table:  cat history.dir (it's a text file), take the second number
on the first line, multiply by sizeof(long) (normally 4).
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry