valdi@rhi.hi.is (Thorvaldur Sigurdsson) (10/06/89)
Reykjavik, Okt. 6, 1989
We are developing a Vessel Tracking System that is to be run 24 hours
a day. The ships are polled every 5 minutes. The performance of the programs,
e.g. menuselecting, redrawing a map on an expose event, drops dramatically
when the workstation has been left untouched for some hours. Can anyone explain
this effect ? I was wondering whether this was due to the structure of the UNIX OS,
that is to say whether the program or the X server has been swapped more or less
to the hard disks. The VTS programs are the only ones running on the
workstation besides the OS. Would it make a difference to make the procedure
nice -10 ? Is this a result of a drop in performance on behalf of the X-Server
(server - client protocol) or something else ? I have been concidering the usage
of the plock command (see man plock) as in:
#include <sys/lock.h>
main()
{
plock(PROCLOCK);
}
x11start
One would have to run this little program here above that does this before one
starts the X-Server or what ? We have a HP9000/360 with 8MB RAM, HP-UX 6.5 and
HPX11R1 (A.01) Revision 9.1.
________________________________________________________________________
Thorvaldur Egill Sigurdsson | Internet: valdi@kerfi.hi.is
Engineering Research Institute | ...mcvax!hafro!krafla!kerfi.hi.is!valdi
University of ICELAND | Phone: 354-1-694699
Hjardarhagi 2-6
107 Reykjavik, ICELAND
------------------------------------------------------------------------asente@decwrl.dec.com (Paul Asente) (10/07/89)
Two possibilities come to mind: 1) Your server has a memory leak and is growing extremely large. I had this problem with a development server for a while (it grew 2K bytes every time I switched focus) and the symptom was exactly as you describe. 2) Your server is getting auto-niced by the OS after it accumulates too much runtime. This would most likely take effect more quickly than you describe. If it is the problem, running the server niced with a higher priority should solve it. My experience is that in general running with a niced server, even niced slighly, gives superior performance. -paul asente asente@decwrl.dec.com decwrl!asente
klee@gilroy.pa.dec.com (Ken Lee) (10/07/89)
Paul's suggestions are valid, and happen with many X applications. Another is getting paged out (as opposed to getting a lower priority) by the OS. Inactive clients will get paged out, so must be read off disk before they can respond to user input. Conversely, active clients tend to take over physical memory (as inactive clients get page out) and get considerably faster after a few minutes. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
madd@bu-cs.BU.EDU (Jim Frost) (10/13/89)
In article <1184@krafla.rhi.hi.is> valdi@rhi.hi.is (Thorvaldur Sigurdsson) writes: |The performance of the programs, |e.g. menuselecting, redrawing a map on an expose event, drops dramatically |when the workstation has been left untouched for some hours. Can anyone explain |this effect ? [...] |(server - client protocol) or something else ? I have been concidering the usage |of the plock command [...] |We have a HP9000/360 with 8MB RAM, HP-UX 6.5 and |HPX11R1 (A.01) Revision 9.1. If HP-UX is System-V derived (I believe it is), then it's probably the result of the SysV virtual memory management. While I'm not sure why it happens, running large programs under sysV for long periods of time (more than a few hours) shows significant performance lossage. I would tack it up to inactive page swapping except that it doesn't improve with use. I'd blame it on priority drops but its behavior doesn't seem right for that either. I've seen this behavior under 386 versions of UNIX, on the SGI's, and on AT&T equipment using commercial, GNU, and proprietary software (the last had *no* memory leakages). There were significant hardware and software differences to lead me to believe that the memory manager itself is deficient. This behavior does not seem to happen on similar hardware under SunOS or other BSD-derived operating systems. Your plock() suggestion is a good idea to try if you can spare the memory, but you might not be able to with only 8mb. Good luck, jim frost software tool & die madd@std.com
cpcahil@virtech.UUCP (Conor P. Cahill) (10/13/89)
In article <40200@bu-cs.BU.EDU>, madd@bu-cs.BU.EDU (Jim Frost) writes: > In article <1184@krafla.rhi.hi.is> valdi@rhi.hi.is (Thorvaldur Sigurdsson) writes: > If HP-UX is System-V derived (I believe it is), then it's probably the > result of the SysV virtual memory management. While I'm not sure why > it happens, running large programs under sysV for long periods of time > (more than a few hours) shows significant performance lossage. I > would tack it up to inactive page swapping except that it doesn't > improve with use. I'd blame it on priority drops but its behavior > doesn't seem right for that either. > > I've seen this behavior under 386 versions of UNIX, on the SGI's, and > on AT&T equipment using commercial, GNU, and proprietary software (the Not saying you are wrong, but I haven't seen this problem manifest itself on my machine. I am running SysV/386 Rel 3.2 with X11R3 and leave my x server, along with my standard 5 xterms, xclock, xload, etc running for weeks at a time without any noticable performance degradation. ps -ef output after three days shows the following: (date: Thu Oct 12 23:09:30 EDT 1989) cpcahil 191 188 0 Oct 9 vt03 71:04 X :0 cpcahil 198 188 0 Oct 9 ? 0:01 xterm -geometry... cpcahil 214 167 0 Oct 9 console 2:17 xterm -n xterm... cpcahil 215 167 0 Oct 9 console 3:34 xterm -n xterm... cpcahil 216 167 0 Oct 9 console 2:22 xterm -n xterm... cpcahil 217 167 0 Oct 9 console 0:55 xbiff -update 3... cpcahil 218 167 0 Oct 9 console 1:40 xclock -update... cpcahil 219 167 0 Oct 9 console 10:31 xload -update 2... -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+