Xref: utzoo news.software.b:6603 comp.sys.hp:7343 Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!sdd.hp.com!usc!samsung!uunet!cellar!toad From: toad@cellar.UUCP (Tony Shepps) Newsgroups: news.software.b,comp.sys.hp Subject: Re: Incredibly slow C News unbatch Message-ID: <49aLV1w163w@cellar.UUCP> Date: 11 Jan 91 03:23:02 GMT References: Sender: root@cellar.UUCP (Superuser) Organization: The Cellar BBS +1 215 336 9503 Lines: 32 toad@cellar.UUCP (Tony Shepps) writes: > > The standard reason for this is that you have an extremely old C News > > and you are using our old dbm emulation, which was a performance disaster. > > Get a modern copy of the software, with dbz. > OK, what could be the reason if you HAVE a dbz version? We're seeing about > two articles a minute... > > We did try compiling dbz without the O option, as suggested in the problems > file. We're running SCO Unix on a 386, and there is nothing else running on > the machine. Oops. Problem solved. I did so many things that I'm not sure what eventually cleared up the problem, but I think it was a combination of compiling the very latest version, NOT using the O option to compile dbz, and deleting any old relocatables that had anything to do with dbz before running doit.bin. The problem showed itself in a most irritating way. Everything worked, but SLOWLY! And due to my questionable approaches to fixing the problem, somehow I managed to fix relaynews but not fix mkhistory or expire. As a result, mkhistory created a 60 Meg history.pag file based on one day's worth of full feed (!), and expire took six hours to run while deleting the equivalent of one day's feed of about 20 low volume groups. After that, you can imagine how wonderful it was to see half a day's feed processed in a matter of minutes. Phew, it's beautiful! --------------------------------------------------------------------------- - The Cellar BBS, a responsible, kind, and caring public-access Unix site - Ignore address above; send mail through cellar!toad@uunet.uu.net