On Wed, Dec 03, 2003 at 04:11:48PM -0600, Smart,Dan wrote: > So if I set the Journal to a really big number, like 10MB, then the > once-per-day opportunistic sync rule should kick in and sync once per day. > > So a sync takes as much or more memory than an expiration run?
Yeah, fun question: The sync takes a bunch of memory because it caches
the highest atime value for each token before applying the change to
the DB. In testing, I found (not too surprisingly) that the common
tokens account for a large number of entries in the journal, and there
was a significant speed increase to cache the values and then apply
instead of applying each value in sequence. The cost, of course, is
the memory usage. But since the usage should max out to roughly the
size of the journal file, it's not too bad. But there's the reason to
not let the journal get too big.
The expiry should, theoretically, not take a lot of memory since it
really only needs to have 1 token in memory at a time while it copies
between database files. An expiry forces a journal sync though, so an
expiry run will always take at least as much as a journal sync.
I hope that helps. :)
As for the one-a-day thing ... Yeah, you can set a large value,
then it'll either do it when the size is large enough or once a day.
Hrm. I just noticed a bug in either the documentation or the code,
depending on which way you look at it. Setting the max size to 0 disables
auto-sync, not do the one a day thing. Have to go fix that. :|
--
Randomly Generated Tagline:
We might be able to do something similar with lex_formbrack, but I
chickened out. Bock, bock.
-- Larry Wall in <[EMAIL PROTECTED]>
pgp00000.pgp
Description: PGP signature
