Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!gatech!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: news.software.b Subject: Re: dbz caveat Summary: Now does someone have a fix for the "it's here but not in history" problem with Cnews? Keywords: dbz runtime Message-ID: <1989Sep26.223014.13868@ddsw1.MCS.COM> Date: 26 Sep 89 22:30:14 GMT References: <1139@svx.SV.DG.COM> Reply-To: karl@ddsw1.MCS.COM (Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 31 In article <1139@svx.SV.DG.COM> gary@svx.SV.DG.COM (Gary Bridgewater) writes: >I switched to dbz in my B 2.11.17 and have noticed a pretty good performance >improvement for several weeks now. Suddenly, last Thursday my expire >times jumped from an hour or so to 4+ hours (I keep a 30 day history). ... >Finally, tonight, I decided I better rethink DBZ so I went into the code >and found > /* > Set this to the something several times larger than the maximum # of > lines in a history file. It should be a prime number. > */ > #define INDEX_SIZE 99991L > >My history file is sitting at 5Mb, an average history line is ~40 bytes -> >120,000 lines. OOOPS! I bumped INDEX_SIZE up to 1000003, did an expire -R >( 30 minutes ), and am now processing articles at a rate of 4-5/minute. Ok, how about this one? Dbz also appears to have a nasty habit of not noticing if you have a duplicate under some conditions. That is, articles which are still in the history file at times show up again if they are received twice! This didn't start happening until we changed to dbz from dbm. Is there a fix for it? We're running "C" News.... -- Karl Denninger (karl@ddsw1.MCS.COM,!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"