Path: utzoo!attcan!uunet!portal!cup.portal.com!Dave_H_Close From: Dave_H_Close@cup.portal.com Newsgroups: comp.unix.xenix Subject: Xenix 2.1.3 slowdown on 286 clone Message-ID: <5378@cup.portal.com> Date: 13 May 88 03:49:43 GMT Organization: The Portal System (TM) Lines: 126 XPortal-User-Id: 1.1001.4097 The following is a summary of replies received in response to my article. =============================================================================== =============================================================================== Original article: <5114@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@andrew.cmu.edu Bitnet: Jay.Libove@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@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@cup.portal.com or sun!cup.portal.com!compata telex: 6295-5830