rusty@anasaz.UUCP (Rusty Carruth) (06/20/91)
I just brought up Cnews (last patch 7-Dec-1990) on a Pyramid 9000-series
computer (4 cpus, multi-gig of disk, OSx96MDN 5.0d-910325 Pyramid 9845,
for you sticklers :-).
I read all the hoopla about speedier news processing, and was greatly
looking forward to "high-speed news".
Alas, I must have done something wrong, as relaynews took a full
160 seconds
to process one 30k batch file.
Help! Has anyone else had problems with slow "unbatching" of news?
How did you fix it?
And, for the detail-oriented folks:
the pyramid is fed over ethernet from machine "anasaz", which is a
tower32 (egads! :-) running bnews (to be replaced with cnews as
soon as I figure why the pyramid now runs news slower than the tower32!).
setup:
run from crontab:
quarter-hourly: sendbatches anasaz
hourly: newsrun (on the half hour)
daily: expire
results:
incoming articles (over ethernet) seem to get put in in.coming just
fine (i.e. rnews seems to be doing its job just peachy)
articles get processed out of in.coming just fine, but very slowly.
outgoing articles also seem to go out just fine.
I did a profile of relaynews, and got the following stuff:
Name %time Seconds #calls ... (I'm entering by hand, so this is edited)
_fread 37.4 60.95
_memcpy 15.2 24.70 914983
_read 10.9 17.77 10243
_strncmp 7.7 12.62 1827237
_nextkey 7.4 12.12
mcount 7.2 11.68
_malloc 6.1 9.85 1824451
_free 3.9 6.40 1824429
_fetch 2.9 4.72
_open .3 .43 33
We did not have dbm, so I'm using the supplied replacement....
I'm obviously doing something really wrong here, since Cnews is "so fast it
will make your head spin".... Help!
Thanks in advance! (this article posted on the Bnews system ("anasaz"),
no particular reason for not using the Cnews one, actually)
Rusty
{ames!ncar!noao!asuvax,mcdphx}!anasaz!rusty anasaz!rusty\
73 de Rusty Carruth, N7IKQ (602) 870-3330 anasaz.UUCP!rusty>@asuvax
P.O. Box 27001, Tempe, AZ 85285 rusty%anasaz.UUCP/ \.eas.asu.eduhenry@zoo.toronto.edu (Henry Spencer) (06/25/91)
In article <4312@anasaz.UUCP> rusty@anasaz.UUCP (Rusty Carruth) writes: >I just brought up Cnews (last patch 7-Dec-1990) ... >Alas, I must have done something wrong, as relaynews took a full > 160 seconds >to process one 30k batch file. Okay, the basic problem here is that your C News is out of date. :-) This is almost certainly a known bug that was fixed in the March patches. The heart of the matter is that dbz keeps track of how much news you've got, so expire can re-size dbz's hash table suitably. The trouble is the startup transient when you're starting a news system from scratch. A bit of news comes in, then expire runs and says "oh, he's got hardly any news, give him a nice small hash table"... and then more comes pouring in, and the hash table is too small. Dbz copes, but massive table overflow is a big performance loss. The table size consistently lags behind the demand until your news spool starts to achieve a steady state, at which time the table gets sized properly and things speed up dramatically. The March patches introduced a simple fix for this: dbz refuses to shrink its table (which is initially fairly sizable) until it's got several data points to use when picking a new table size. A more clever algorithm would be nice, but this eliminates the worst of the problems. The fix is to either get a more current copy of C News or just be patient and wait for steady state. (That can take quite a bit of patience if you keep a lot of news on-line, mind you.) -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry