Path: gmdzi!unido!mcsun!uunet!munnari.oz.au!csc.anu.edu.au!aerodec.anu.edu.au!csc From: tri...@aerodec.anu.edu.au (Andrew Tridgell) Newsgroups: comp.unix.ultrix Subject: Xcfb growing and growing and grow.... Message-ID: <2383@aerodec.anu.edu.au> Date: 23 Jan 91 14:20:28 GMT Organization: Australian National University, Canberra, ACT, Australia Lines: 16 Nntp-Posting-Host: phyds0.anu.edu.au 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 tri...@aerodec.anu.edu.au
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com! decwrl!pa.dec.com!wsl.dec.com!gringort From: gring...@wsl.dec.com (Joel Gringorten) Newsgroups: comp.unix.ultrix Subject: Re: Xcfb growing and growing and grow.... Message-ID: <1991Jan25.170335@wsl.dec.com> Date: 26 Jan 91 01:03:35 GMT References: <2383@aerodec.anu.edu.au> <15990@crdgw1.crd.ge.com> <1474@mpirbn.mpifr-bonn.mpg.de> Sender: n...@pa.dec.com (News) Reply-To: gring...@wsl.dec.com (Joel Gringorten) Organization: DEC Western Software Lab Lines: 24 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
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!julius.cs.uiuc.edu!usc!elroy.jpl.nasa.gov! decwrl!deccrl!news.crl.dec.com!quabbin.crl.dec.com!jg From: j...@quabbin.crl.dec.com (Jim Gettys) Newsgroups: comp.unix.ultrix Subject: Re: Xcfb growing and growing and grow.... Message-ID: <1991Jan26.050906.21922@crl.dec.com> Date: 26 Jan 91 05:09:06 GMT References: <15990@crdgw1.crd.ge.com> <1474@mpirbn.mpifr-bonn.mpg.de> <1991Jan25.170335@wsl.dec.com> Sender: n...@crl.dec.com (USENET News System) Organization: DEC Cambridge Research Lab Lines: 53 In article <1991Jan25.170...@wsl.dec.com> gring...@wsl.dec.com (Joel Gringorten) writes: >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's last statement here isn't really correct (though the previous ones are fine). A "bug free" X server will generally undo fragmentation of the memory it has allocated at server reset (typically when a user logs out), so the virtual address space of an X server will normally tend toward a steady-state maximum, set by the appication mix you generally run. The server tries very hard on server reset to make sure any allocated memory gts freed (there is acutally an exception to this statement, but to first order, it is correct); malloc/free then will merge the freed memroy back into contiguous blocks. So while your virtual address space used by the X server should increase for a while, there should come a point at which it stops growing (presuming a steady state of application's demands); if it doesn't, there is likely a memory leak somewhere. I've certainly used X servers for months on end in the past (without restarting the server), and seen this behavior (and I've been watching X servers for longer than most people :-)). And sorry for the memory leak in our current server... - Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory -- Digital Equipment Corporation Cambridge Research Laboratory