Xenix 2.1.3 slowdown on 286 clone

[Dave_H_Close at cup.portal.com]

The following is a summary of replies received in response to my article.

===============================================================================
===============================================================================

Original article: <5114 at cup.portal.com>

Several of my customers are running Xenix 2.1.3 on a 1 MB AT clone.  They
have complained that the system seems to begin running more slowly after it
has been up for several days.  Even to the point where response to a haltsys
requires ten minutes.  The problem can be easily cured by rebooting.

I would consider suggesting that they upgrade to 2.2 if I can be confident
that it will fix the problem.  Is this a known problem with 2.1.3?  Is it
fixed in 2.2?  Is it perhaps caused by some data structure accumulating,
eventually filling memory?

I know that an upgrade would require that they also purchase more memory,
at least 1 more MB.  They are running a MS-COBOL application from 3-5
concurrent terminals, so the problem could also be in COBOL.  It certainly
does have problems.  So what would you suggest?

===============================================================================

I ran SCO Xenix 2.1.3 for an extended period of time before upgrading
to 2.2.1 and never saw such a phenomenon, so I would guess that it is
your COBOL system. Does it have a driver built in? Does it leave something
running all the time that might have a core leak? If so, then every time
it gets swapped out, approximately 700K is being written to then read
back from the disk. Try this: The next time the system starts slowing
down, do a "ps -elf" and find processes that are taking lots of memory
and have been running for a long time, and ask the owning users to
exit them, then restart them. If that does the trick, then talk to
the people who supplied the software and ask them to fix the bugs...
if that does not help, then there is perhaps a bug in the xenix. But
I expect that you'll find a memory losing long running program to be
at fault.
Good luck!

Jay Libove
Arpa:   Jay.Libove at andrew.cmu.edu	Bitnet: Jay.Libove at drycas.bitnet
UUCP:   ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!Jay.Libove
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

===============================================================================

Dave,
	You have two problems.  One is the lack of main memory.  For my
customers I make sure that there is at leas 1/2 meg of memory for each
user, plus 1 meg for the system.

	The other problem is a little more difficult to fix.  I suspect
that you did not allocate enough swap space on the disk.  As a rule of
thumb the swap space should be at least 2 times the amount of memory
the computer has.  The reason the haltsys is taking so long is because
the swap space is getting extremely fragmented.

	The computer itself should be able to handle the load you
are putting on it.  You do not have to upgrade to 2.2, but it would be a
good idea.  2.2 solves some problems and is also a little faster (?).

	I mailed this to you because I didn't want to clutter up the
net.  Please summarize all the responces you get and post it.  I would
be interested in hearing about any other possibilities.

Jonathan Bayer
Intelligent Software Products, Inc.
19 Virginia Ave.
Rockville Centre, NY   11570
...uunet!ispi!jbayer

===============================================================================

From: sun!uunet.UU.NET!idsnh!ben

Some applications create many temporary files in /usr/tmp.
When the system reboots, these files are deleted through the action 
the system running the script in /etc/rc.  The application should
remove these temporary file as a matter of course, but there may be
some permission problems because of the way the application is invoked.

Next time look in the /usr/tmp directory and see who owns the files. 
Maybe you can track it from there.

===============================================================================

From: uunet!mcl!stacy (Stacy L. Millions)

I don't know about the particular problem that you are
describing, but for 3 to 5 simultanious users you need
more than 1MB of RAM, add at least 1 more Meg, I would
recomend 3 more if you are using something like cobol.

---
"IBM Personal System/2. It's like having 256,000 crayons in one box."
    For those of you who are still doing your business reports with crayons!

S. L. Millions                                            ..!uunet!mcl!stacy 

===============================================================================

I run as long as 20-30 days between boots on both 2.1.3 (286) and 2.2.1
(386) systems. I see no slowdowns. I think you have something else going
on.

-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

===============================================================================
===============================================================================

Thanks to all who replied.  It seems clear that the problem is not Xenix.
It may be MS-COBOL or it could be the swap space allocation (installation
default).  BTW, 1 MB does not generally seem to be a problem in this case.
I understand that 3-5 users running vi, cc, etc., would need much more.  But
these users are all running the same program, consisting of a shared COBOL
runtime interpreter and small pseudo-code files.  Of course, if there is
some sort of "core leak", then more memory might postpone the appearance of
the slowdown, but not necessarily eliminate it.  SCO recommended 1 MB as
enough for this application.

Dave Close, Compata, Arlington, Texas
email:  compata at cup.portal.com or sun!cup.portal.com!compata
telex:  6295-5830