[comp.unix.ultrix] Xcfb growing and growing and grow....

meltsner@crd.ge.com (Kenneth J Meltsner) (01/23/91)

In article <2383@aerodec.anu.edu.au>, tridge@aerodec.anu.edu.au (Andrew Tridgell) writes:

|>Does anyone know why Xcfb would grow? Whenever anyone is logged on to
|>the console of our DS3100 I've noticed that Xcfb grows - and doesn't
|>shrink when they exit. It grew to 21M (in the SZ column of ps aux) at
|>one stage so I kept getting an out of core message and had to reboot!
|>After one day (and 2 console sessions) it has reached 7.6M and I don't
|>relish having to reboot every few days.
|>
|>We are running Ultrix 4, have 16M of memory and a 600M disk (if that's
|>relevant). Recently we have started using the mwm motif window manager -
|>could that be doing it?

Well, we're running Ultrix/RISC 3.1 on DS5000, have 32 meg of memory
and a 600 M disk, run straight DECWindows, and we've got the same
problem.  We're up to 16M as we speak -- but we also have a huge
amount of swap space so we can do LISP programming.  Does this get
fixed in 4.1?

--
===============================================================================
Ken Meltsner                        | meltsner@crd.ge.com (518) 387-6391
GE Research and Development Center  | Fax:  (518) 387-7495
P.O. Box 8, Room K1/MB207	    | Nothing I say should be attributed
Schenectady, NY 12301               | to my employer, and probably vice-versa
=================Dep't of Materials Science, ACME Looniversity=================

tridge@aerodec.anu.edu.au (Andrew Tridgell) (01/23/91)

Does anyone know why Xcfb would grow? Whenever anyone is logged on to
the console of our DS3100 I've noticed that Xcfb grows - and doesn't
shrink when they exit. It grew to 21M (in the SZ column of ps aux) at
one stage so I kept getting an out of core message and had to reboot!
After one day (and 2 console sessions) it has reached 7.6M and I don't
relish having to reboot every few days.

We are running Ultrix 4, have 16M of memory and a 600M disk (if that's
relevant). Recently we have started using the mwm motif window manager -
could that be doing it?

Thanks in advance for any help.

---
Andrew Tridgell
tridge@aerodec.anu.edu.au

mjr@hussar.dco.dec.com (Marcus J. Ranum) (01/24/91)

tridge@aerodec.anu.edu.au (Andrew Tridgell) writes:
>Does anyone know why Xcfb would grow? Whenever anyone is logged on to
>the console of our DS3100 I've noticed that Xcfb grows - and doesn't
>shrink when they exit.
>
>We are running Ultrix 4

	There is a "memory leak" in the 4.0 and 4.1 servers (RISC/VAX)
that apparently stems from save-unders and some interaction with the
memory allocator. This will be fixed in 4.2.

	A work-around is to start the server without save-unders, as
"Xcfb -su" in /etc/ttys. Running without save-unders isn't a performance hit
unless you're doing complex pictures.

mjr.
-- 
Bumper Sticker:  "Unix wizards do it with small, efficient, modular tools"
				(C)Marcus Ranum, 1991

daniels@bigred.enet.dec.com (01/24/91)

In article <15990@crdgw1.crd.ge.com>, meltsner@crd.ge.com (Kenneth J Meltsner) writes...
>Well, we're running Ultrix/RISC 3.1 on DS5000, have 32 meg of memory
>and a 600 M disk, run straight DECWindows, and we've got the same
>problem.  We're up to 16M as we speak -- but we also have a huge
>amount of swap space so we can do LISP programming.  Does this get
>fixed in 4.1?

This is not the official word, but as I understand it, there is a patch
available for V4.1.  That is, the problem is not fixed in V4.1, but is
fixed in a patch for that release.  I suggest that you contact your Digital
representative and ask them to find the patch.  If they have trouble, you
can give them my mail address (Daniels @ bigred @ vaxmail, if they use
ALL-IN-1), and I will try to put them in touch with the right people.

Again, I want to stress that I am not 100% positive the patch is in fact
available, but that I recall being told of a patch to Xcfb which I believe
addresses this problem.  If I learn that I am mistaken, I will post the
"official" status when I get it.  You should contact your local rep and
ask them to look into it.

- Brad

sac@decuk.uvo.dec.com (Stephen A Carpenter) (01/25/91)

Try starting Xcfb with the -su flag.

bni@modulex.dk (Bent Nielsen) (01/25/91)

sac@decuk.uvo.dec.com (Stephen A Carpenter) writes:
>Try starting Xcfb with the -su flag.

Is the -su flag a unsupported option???

Because I can't find it in my manual!!!.

--
Bent Nielsen		<bni@modulex.dk>
A/S MODULEX		Phone:    +45 44 53 30 11
Lyskaer 15		Telefax:  +45 44 53 30 74
DK-2730 Herlev
Denmark

p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (01/25/91)

In article <15990@crdgw1.crd.ge.com> meltsner@crd.ge.com writes:
>problem.  We're up to 16M as we speak -- but we also have a huge
>amount of swap space so we can do LISP programming.  Does this get
>fixed in 4.1?

Don't know about 4.1 but I've written a program that allows ordinary
users to kill the Xserver (usually on logout).

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."

iglesias@draco.acs.uci.edu (Mike Iglesias) (01/26/91)

In article <709@modulex.dk> bni@modulex.dk (Bent Nielsen) writes:
>Is the -su flag a unsupported option???
>Because I can't find it in my manual!!!.

It's in the Ultrix 4.1 release notes, page 4-3.


Mike Iglesias
University of California, Irvine
Internet:    iglesias@draco.acs.uci.edu
BITNET:      iglesias@uci
uucp:        ...!ucbvax!ucivax!iglesias

gringort@wsl.dec.com (Joel Gringorten) (01/26/91)

I'm suprised that nobody's pointed this out yet, but...

All X Servers have a tendancy to grow.  They allocate storage for a variety
of reasons resulting from client requests.  When this allocated storage is
free'd, the process doesn't grow any smaller.  So the server process size can 
only grow larger and not smaller.  There are some versions of Unix that can
do a negative sbrk, but this only works if you happen to have contiguous 
address space at the end of your process.  Fragmentation of the allocated 
storage space makes this less likely.  

The virtual address size (SIZE) of the server isn't particularly interesting 
anyway. What's interesting is the resident set size (RSS) which tells you how
much memory you're really hogging.  

Many X Servers, including DEC's, have memory leaks which will cause them to
hog more memory than they should.  DEC has been religous about tracking down
memory leaks in their servers over time.  This is to say that the more recent
the release, the fewer memory leaks a server is likely to have.  The next 
release of Ultrix will contain a server based on MIT X11R4, which uses much
less memory than previous releases due to reorganizing internal data structures.
But even it will have a tendancy to grow in virtual address space in time.  It's
just the nature of the beast.  

-joel