pete@mimsy.umd.edu (Pete Cottrell) (10/25/90)
I'm sure this has been discussed before, but I wasn't interested then so didn't retain it. The question is: can I use the dbz routines to make my Bnews expire run faster? Does it require a certain patch level? Is it is easy or hard to do? Any horror stories? Ok, so that's more than one question. If you mail to me, I will summarize the answers, unless of course you reply to everyone in this group since this really *hasn't* been discussed before or since you think it is time to bring it all up again (there's a double-entendre in there somewhere...). -- Spoken: Pete Cottrell UUCP: uunet!mimsy!pete INTERNET: pete@cs.umd.edu Phone: 301-405-2749 USPS: U of Maryland, CS Dept., College Park, Md 20742
henry@zoo.toronto.edu (Henry Spencer) (10/25/90)
In article <27155@mimsy.umd.edu> pete@mimsy.umd.edu (Pete Cottrell) writes: >... The question is: can I use the dbz routines >to make my Bnews expire run faster? Does it require a certain patch level? The original dbz was built for B News, so it can be done. The current dbz (the one shipped with C News) is *intended* to also work with B News, but has not been tested that way. You want to use the current one if you can, because it is considerably faster and deals much more gracefully with things like table overflow. Note that conversion to dbz is all-or-nothing. It is *not* file-format compatible with dbm or the various dbm substitutes, so you must recompile everything in the news system and rebuild your history database to use it. -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
gary@dgcad.sv.dg.com (Gary Bridgewater) (10/25/90)
In article <27155@mimsy.umd.edu> pete@mimsy.umd.edu (Pete Cottrell) writes: > > I'm sure this has been discussed before, but I wasn't interested >then so didn't retain it. The question is: can I use the dbz routines >to make my Bnews expire run faster? Does it require a certain patch level? >Is it is easy or hard to do? Any horror stories? Yes you can. I run it on patch level 17. It does go much faster - especially if you have enough menory to use INCORE for expire (memory use ~= size of history file + code). If you use INCORE then you must wade through expire.c and find the places where it exits and issue a dbmclose to flush the dbm data back out. You need to understand how the INDEX_SIZE value works - if it is too small the hash table overflows and duplicates occur a lot (this is the *horror* part). It is a function of your history file size, e.g. I use 3000017 for a 40 day history (about 12 Mbytes). (Actually it is a function of the number of entries in the history file but who has time to count them). Your history.pag file will appear to be 4x this (4 bytes per entry) but won't really take that much space if your system does sparse file allocation. There is no point in building inews with the INCORE value set so I keep a libdbzi.a and a libdbz.a. I don't think there is much point in using INCORE without sufficient memory to keep it all there either although paging may be cheaper than doing the i/o in the program (WAG). The preceeding is based on the dbz before the one recently announced for C-News which was advertised to handle INCORE on the fly among other features. P.s. If you run nntp it must be built with the same dbz. And, of course, when you switch - and anytime you change INDEX_SIZE you must rebuild (inews -r) the history database. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.