Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!rutgers!rochester!cornell!uw-beaver!uw-june!uw-entropy!dataio!pilchuck!ssc!fyl
From: fyl@ssc.UUCP (Phil Hughes)
Newsgroups: comp.unix.microport
Subject: Re: Info needed: UNIX for 286/386 machines (really malloc)
Message-ID: <1038@ssc.UUCP>
Date: 23 Feb 88 06:15:50 GMT
References: <4213@sigi.Colorado.EDU> <863@athos.rutgers.edu> <141@bdt.UUCP>
Organization: Slugland, USA
Lines: 23
Summary: Solution: don't run so many unbatches

In article <141@bdt.UUCP>, david@bdt.UUCP (David Beckemeyer) writes:
> I have 2MB of memory on a 286 AT system running Microport; Sometimes it
> runs out of swap space and the system crashes (I have 3 MB of swap space).
> This occurs most often when the system is receiving incoming news,
> when UUCP fires up several rnews/compress jobs, each chewing on large
> news batch files.
> 
>                                     It usually only happen when there
> are four or more rnews/compress jobs running all at the same time.

I see a simple solution to your problem: don't run so many unbatches.
On a 286 system, you are not going to do anything more than thrash
if you have more that one running.  The system slows down, you eat
up all your swap space and nothing good happens.

I was having this problem on a 286 XENIX system.  Even with 4MB of
RAM the news throughput was less than one unbatch.  The problem with
XENIX (and maybe the reason you are running more than one unbatch also)
is that the uuxqt lock times out after about 1 hour.  The solution
is to add a
	touch -c /usr/spool/uucp/LCK.XQT
that is run every half hour by cron.  All is well here.
-- 
Phil    uunet!pilchuck!ssc!fyl