Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbosgd!ulysses!allegra!mit-eddie!think!harvard!seismo!lll-crg!lll-lcc!dual!ptsfa!gilbbs!mc68020 From: mc68020@gilbbs.UUCP (Tom Keller) Newsgroups: net.news.adm,net.news.b Subject: Re: curious 2.10.3 efficiency situation Message-ID: <63@gilbbs.UUCP> Date: Mon, 10-Mar-86 02:59:51 EST Article-I.D.: gilbbs.63 Posted: Mon Mar 10 02:59:51 1986 Date-Received: Wed, 12-Mar-86 06:39:02 EST References: <5044@glacier.ARPA> <5104@glacier.ARPA> <10428@amdcad.UUCP> <5128@glacier.ARPA> Organization: Gil's Place, Santa Rosa CA Lines: 69 Xref: watmath net.news.adm:554 net.news.b:1314 Summary: another 2.10.3 user with efficiency problems(?) In article <5128@glacier.ARPA>, reid@glacier.ARPA (Brian Reid) writes: > > Grumble. Don't tell me that this didn't happen. It did. > > It is absolutely true that the time to process one news article increased > substantially while the torrent was arriving. Or, more precisely, the number > of articles per minute that the machine could process was decreasing. In > particular, the time to process one message became longer than the expected > interval between arrivals of messages, with the result that the queues were > increasing in length. The particular queue that was increasing in length was > the /usr/spool/uucp/X. queue. > > Although I spent my energy on trying to fix this problem rather than trying > to diagnose it, I did make a few measurements and form a few theories. > > I believe that the extra time to process articles was caused by some > combination of these two factors: > (1) The huge /usr/spool/uucp/X. directory (200+ entries at the beginning; > 900+ entries before I took drastic action. I believe that this > slowed uuxqt down considerably. > (2) The huge history file. At the moment my /usr/lib/news/history > file is 1.2 megabytes, and has 17000 messages in it. This is about > double what it usually runs. I believe that inews is running a bit > slower when the history file gets this big (it still has to search > to resolve hash conflicts). > > Unfortunately, I forgot to turn on system accounting before all of this, so > I don't have any hard data about how well it was working. > -- > Brian Reid decwrl!glacier!reid > Stanford reid@SU-Glacier.ARPA I also have problems with the UUXQT program bogging down. Now, I have to tell you that I am running a machine which is not in the same UNIVERSE with VAXen. My machine is a Tandy 6000. Part of the problem *I* am having is that when I have 12-20 processes all clamoring for disk I/O, a couple of modems clamoring for I/O, plus me bitching at my console about mollasses in January, my poor 'lil braindamaged Z-80A IOP goes virtually catatonic (though not in the canonical sense). It *DOES* bog down badly (as well you might imagine) I don't receive tons of traffic, and I only receive traffic during the off hours at night. Which means that my system is working *VERY* hard to keep up with what *DOES* come down the pike (I have over 110 newsgroups that me feed site does *NOT* feed me). I understand there is some way to ensure that only one istantiation of UUXQT is executed at any one time. Can someone elaborate on this for me? I am very new to all this (I've never had to consider such things in my 3 years of using XENIX. I have no gurus to point out the True Path to me). Any other suggestions for relieving my system of terminal indigestion? (please, do not crack wise about getting a more powerful system. I would dearly love to do so...but first I need a job to pay rent, etc., *THEN* maybe I can consider getting a new system...maybe) -- ==================================== Disclaimer: I hereby disclaim any and all responsibility for disclaimers. tom keller {ihnp4, dual}!ptsfa!gilbbs!mc68020 (* we may not be big, but we're small! *)