I would really like to see expire gone

[Russ Allbery]

bill davidsen <davidsen at tmr.com> writes:

> If you mean that it takes that time using sleepycat but faster disk,
> then clearly the db itself isn't the bottleneck (ie. CPU usage). Clearly
> any database is going to depend on disk speed to some extent, sure as
> hell dbz does.

No, the problem is that Sleepcat will go to disk *way* more than our
current history implementation does.  You'll get some of that time back if
you turn off fsync (at the cost of reliability, since our current history
implementation does fsync occasionally), but not all of it.  Our current
history implementation is specifically designed to minimize disk access by
holding horking huge tables in memory, and does mostly work.

> And "duplicate entry" warnings are not a surprize during expire, so I
> have to think that dbz doesn't do a perfect job every time.

In all of the time that I've been running INN, I've never gotten one of
these.  I really wish I knew what was causing them for other people.

> Eliminating expire with a database doesn't have to mean sleepycat, just
> a database which allows removal of entries.

Note that you can implement that right now over top of our current history
database, and can do so even easier if we switch the history text file to
a binary format.

> Can someone comment on the performance of db for overview? I would think
> that's at least as intensive as history, since info needs to be in
> multiple places for cross posting. I haven't tried it in ages.

INN reads history a lot more than it reads overview on a transit server.
But yeah, ovdb seems to be okay for overview, although not great; the
impression that I've gotten is that it's a bit faster than tradindexed but
not as fast as buffindexed.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.