expireover vs. control.cancel (memory, innd non-responding, forcing expiration)

[Christian Balzer]

Hello,

and especially a warm "Hajimemashite" to Kondou-san over in Kansai who 
probably will be able to help with this. ^_-

I deployed a nice new news server (reader) using INN 2.3.2 (Debian package)
and everything seemed fine until at 5:30 (AM) yesterday my network monitor
meeped me out of my sleep. There was no response from innd on port 119
and ctlinnd just hung there if issued, too. expireover was running and
consuming insane amounts of memory (700MB and up), compared to the usual
25-30MB I observed before and after that. Yes, the "after that" means the
whole thing stabilized itself about 40 minutes later and innd resumed to
respond as if nothing had happened. No traces in any logs about what was
going on.

After reading a number of old articles in this ML (where are the archives post
June 2001???) it dawned on me what was happening. This server is running
CNFS (and buffindexed) and in the ecstasy over this self maintaining setup
I had completely forgotten one thing I learned on tradspool machines...

Always expire control.cancel as fast as possible.

It looks like I have about 4 million articles in there, which explains the
tummy aches of expireover (still should not lock up the whole thing like
that, IMHO). By now I created a small CNFS for control.cancel:

Buffer        Class              Size      Used   %Used Cycles  KB/sec     Days
CC101         CONT           292.0 MB   85.6 MB   29.3%     19  155.10     0.02
CC201         CONT           292.0 MB   54.5 MB   18.7%     19  152.81     0.02

Which obviously does the trick nicely.

However, now comes my big question. How do I force an expire of the old ones
in the other storage classes? Especially since my non-binary spool is rather
big and it will probably take weeks of morning expireover/innd seizures until
they vanish naturally.

I tried all obvious things, expire -N with an expire.ctl that gave 
control.cancel 1 day to live, but nothing produced the desired results.

Any ideas, anybody?

Dewa,

C. Balzer
-- 
Christian Balzer        Network Engineer        Engineering
chibi at gol.com   	Exodus Communications K.K.
Phone: +81 3 4354 0290  FAX: +81 3 ??    http://www.gol.com/