buffindexed: expireover needs _very_ much memory

Katsuhiro Kondou kondou at nec.co.jp
Wed Oct 13 21:26:20 UTC 1999


In article <19991013181905.A26720 at CIS.FU-Berlin.DE>,
	Heiko Schlichting <inn-bugs at fu-berlin.de> wrote;

} system. Using par, it is shown that every ca. 30 seconds a mmap() call is
} done - always with the same offset:

That's very weird.  buffindexed may sit in forever loop.
Can you see how this come from core which can be created
by SIGABRT.

} The server is a slave server - does this break buffindexed overview? On a

That shoud not break.  I confess my testing server runs
as slave.

} slave server it is not garanteed that the articles come in the Xref order
} because innfeed reorders the queues. But I doubt that a slave server is
} so unusual that it should break buffindexed and during normal operation
} of the slave the wrong Xref order works without problems. Just expireover
} (and now makehistory) fails. If it is not the Xref order, what else could
} be the problem? Any ideas?

One problem I can imagine is that there is a too old article
in cycbuff and its article number and the latest article
number is too far.  Buffindexed prepares every room for
index of articles between them regardless of their existence.
This may happen for control.cancel or junk.  But even in
this case buffindexed never behaves like yours.
-- 
Katsuhiro Kondou


More information about the inn-bugs mailing list