I still haven't found a proper patch, but the very first response I received
was dead on, even in on my limited info. A list of summarized responses
is included.
Use "ps aux" to see what process is growing. It turns out to be "xnews"
in our case. Even a slow typist can make xnews consume large amounts of
swap space **very** quickly in Frame.
I've tried the following "memory leak" related patches with no
improvement.
Patch-ID# 100444-12 OpenWindows V3.0 xnews Server Patch 3000-18
Patch-ID# 100444-19 Openwindows V3.0 Server Patch 3000-28
Patch-ID# 100452-12 XView/3.0 CTE Jumbo Patch
Patch-ID# 100512-02 OpenWindows V3: libXt CTE Jumbo Patch
Other suggestions and/or updates on the state of xnews patches are
most welcomed as the problem lingers on.
-Greg
===============================================================================
Gregory A. Parmer |INTERNET: gparmer@acenet.auburn.edu
Computing Applications Specialist |VOICE: (205) 844-9660
Alabama Cooperative Extension Service |FAX: (205) 844-3501
Auburn University, AL 36849-5646 |
===============================================================================
--
Special thanks to:
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
Piete.Brooks@cl.cam.ac.uk
birger@vest.sdata.no (Birger A. Wathne)
bernards@ECN.NL (Marcel Bernards)
jipping@phoebus.larc.nasa.gov (Mike Jipping)
kuhn@math.harvard.edu (Robert M. Kuhn)
baumann@proton.llumc.edu (Michael Baumann)
Mike Raffety <miker@sbcoc.com>
Peter Shipley <shipley@tfs.COM>
Perry_Hutchison.Portland@xerox.com
kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
blymn@awadi.com.AU (Brett Lymn)
-----
run ps -agux every 10 minutes or so, and see what process is growing
and consuming the swap space.
if it's openwindows/xnews, i think there's a patch for a memory
leak in it.....
-----
> As a user stays logged in to one of our SS1+ clients, the amount of
> swap space is steadily reduced until OpenWindows crashes.
* Find out which programs are using up the VM ....
> Automounter consumes a steady, increasing percentage of memory.
> Coinciding with this is the consumption of swap space as well."
* Use amd ....
-----
As you run with tmpfs, it could be that something fills up /tmp, thus using
all available memory.
-----
We have encountered the same thing by a user running OW2 and and a Sunview smalltalk
environment. Somehow there must be some memory leak with this combination of application.
Particulary the smalltalk interpreter consumes a huge amount of memory as it runs.
After 2 days nothing more can be done within smalltalk.
No solution found yet :-(
-----
I note you use TMPFS --> placing /tmp onto the swap partition.
As your swap space dwindles, check /tmp -- is it growing?
If so, this is probably your problem...
-----
You've probably considered this, but since you are using tmpfs, /tmp will
steadily occupy more nad more of the swap space. Do you know this is not
the cause?
-----
I would take a wild guess, and say that framemaker is not removing all of
its files from /tmp, which you have mounted as tmpfs - So it gets it's space
from swap. I am not sure but I think that tmpfs does not free its memory when
the FS shrinks - but I could be wrong.
-----
Core leak....
Also OpenLook is a fat pig you will be better off runing MIT X11R5 since
it uses less memory and runs at least twice as fast.
-----
Perhaps tmpfs? Try not using it for /tmp and see what happens.
-----
Sounds like you have a "memory leak" there are some bugs with some of
the OW3 libraries that cause memory leaks. Get the following patches
and see if they help:
100452-10 xv_destroy frame memory leak
100452-10 Memory leak in PANEL_CHOICE items
100452-10 Textsw leaks memory after textsw_reset()
100512-02 XtAddWorkProc Memory Leak
----------------------------- Original Message ------------------------
>
> As a user stays logged in to one of our SS1+ clients, the amount of
> swap space is steadily reduced until OpenWindows crashes. Memory
> intensive programs seem to exaggerate the problem, and it is occuring
> most frequently when running FrameMaker (OpenLook Version) with
> Newsprint 2.0.
>
> More info below:
>
> Configuration-->
> Server:
> Sun 4/690
> SunOS 4.1.2
> Relevant Patches
> 100444-03 OpenWin Server Patche
> 100451-02 OLIT/3.0 : CTE Jumbo Patch
>
> Clients:
> Sun 1, 1+
> 16MB RAM
> 104M drives
> Current partition table (original sd0):
> partition a - starting cyl 0, # blocks 21000 (100/0/0)
> partition b - starting cyl 100, # blocks 64050 (305/0/0)
> partition c - starting cyl 0, # blocks 204540 (974/0/0)
> partition d - starting cyl 0, # blocks 0 (0/0/0)
> partition e - starting cyl 0, # blocks 0 (0/0/0)
> partition f - starting cyl 0, # blocks 0 (0/0/0)
> partition g - starting cyl 405, # blocks 119490 (569/0/0)
> partition h - starting cyl 0, # blocks 0 (0/0/0)
>
> Filesystem kbytes used avail capacity Mounted on
> /dev/sd0a 9699 6953 1777 80% /
> /dev/sd0g 55696 45222 4905 90% /usr
> swap 26332 0 26332 0% /tmp
>
> SunOS 4.1.2
> OpenWindows v3.0
> NewsPrint 2.0
> FrameMaker v3.1A
> Relevant Patches
> 100505-01 Zero length dir can be left
> 100507-01 tmpfs fix
> 100516-01 increase HEAPBYTES to prevent..
>
> Tried the following patch on 2 of the machines with no luck:
> 100249-02 automount symbolic link timeout
> One of the bug descriptions sounded like our troubles
> "Bug 1044048
>
> Automounter consumes a steady, increasing percentage of memory.
> Coinciding with this is the consumption of swap space as well."
> But the patch didn't change the condition.
>
> ------
> Has anyone else experienced such a problem..and found a cure for it?
>
> thanks,
> Greg
>
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT