Path: utzoo!utgpu!water!watmath!clyde!ho95e!wcs
From: wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>)
Newsgroups: news.software.b
Subject: Re: news software speedup
Message-ID: <2090@ho95e.ATT.COM>
Date: 30 Mar 88 03:44:18 GMT
References: <649@bms-at.UUCP> <10150@ncc.UUCP> <4246@hoptoad.uucp> <10128@steinmetz.steinmetz.ge.com> <4265@hoptoad.uucp>
Reply-To: wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 33

In article <4265@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
:it takes hoptoad more than an hour to run a single expire each night,

	ho95e (an ancient 3B20, with 1MB ulimit) expires in 10 minutes.
This is for expire -e6 -E10 -n !comp ; on even-numbered nights
I expire everything with -e10, which probably takes twice as long?.
I'm running 2.11.8, with no -dbm (sigh; why isn't it SysV? It was in V7)
so I'm using the big-history-file method.  (A 3B20 is a 1-MIPS bit-sliced
machine, built when we were The Phone Company and 4MB was very big.)

: [..].  I *think* the problem is in the dbm code.  Note that expire
:spends most of its time handling entries for already-expired messages,
:since typically the message-ID-retention is set to e.g. 28 days while
:the expire threshold is at 14 or 10 or 8.

Is it really necessary to retain message-IDs past about 14 days?  The
news.lists postings indicate 99% of everything reaches uunet in 5 days;
surely there aren't too many 15-day-long loops any more?  Probably better
to keep the expire time down and tolerate the <.1% duplication load.
(Admittedly, one reason there aren't many delay loops is that the
backbone machines probably keep a lot of history.)  For ho95e, the
retention limit is forced on us by ulimit; we get history file overflows
if we keep records longer than 11 days, and VOLUME is up.

In article <4246@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
: [various true things about SysV ulimit braindamage]
: [maybe if everyone bitches at their vendors simultaneously they'll fix it]
	Naaah...  At least SVR3 gives you configurable amounts of braindamage.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our parsers and debuggers and lexical analyzers and various 
# implements of destruction and went off to clean up the tty driver...