[comp.unix.ultrix] Size of the X server process growing uncontrollably!

muhanna@stock.cob.ohio-state.edu (Waleed A. Muhanna) (02/20/90)

Last week, I installed UWS2.2 on a VAXstation 3100.  I noticed that
the sizes of the server (Xqvsm) and various clients (e.g.,
dxsession, dxterm) are now about 1.5 times the sizes of their
counterparts in UWS2.0.   I understand the Xqvsm now has DPS support,
but why did the memory requirements for the various clients increase?
I didn't notice any increased functionality in those clients.

What concerns me the most, however, is the fact that the virtual
(memory) size of the X server process keeps growing, sometimes to
the point where I have to reboot to reclaim swap space.   I wonder
if others out there in netland have experienced this phenomenon.

This problem seemed to be present in UWS2.0, but it has gotten worse
since I switch to UWS2.2.

Any suggestions as to what is causing this problems would be greatly
appreciated.   Is there a way around it?  How can I curtail this
growth?

Thank you very much in advance!

seeking help,
--Waleed 

---------------------------------------------------------------------------
Waleed Muhanna    			        	College of Business 
muhanna@stock.cob.ohio-state.edu		  The Ohio State University
phone: (614) 292-3808			          	  1775 College Road
fax:   (614) 292-1651				        Columbus, OH  43210

bph@buengc.BU.EDU (Blair P. Houghton) (02/21/90)

In article <77334@tut.cis.ohio-state.edu> muhanna@stock.cob.ohio-state.edu (Waleed A. Muhanna) writes:
>What concerns me the most, however, is the fact that the virtual
>(memory) size of the X server process keeps growing, sometimes to
>the point where I have to reboot to reclaim swap space.

You don't have to reboot.  Just use a 'ps -aux' to get the
pid of the Xqdsg or Xqvsm process, then use 'kill -KILL pid'.

init will detect the missing login and fork off another Xq?s? for you.

>This problem seemed to be present in UWS2.0, but it has gotten worse
>since I switch to UWS2.2.

Yep.  There's something about UWS software that doesn't
understand that you gotta free(3) what you malloc(3).

>Any suggestions as to what is causing this problems would be greatly
>appreciated.   Is there a way around it?  How can I curtail this
>growth?

You can't, except by preventing users from using the system...

You can use a one-liner to find and kill your server:

  kill -KILL `ps -aux | grep Xq | grep -v grep | colrm 15 | colrm 1 9`

DON'T put this in the crontab(5)!  When you kill the server, you kill
the logins running under it, though not completely, but enough to make
some poor user's life miserable.  Kill the server only when there is
nobody using the display.

				--Blair
				  "But that's another story..."

grunwald@foobar.colorado.edu (Dirk Grunwald) (02/21/90)

GAD ZOOKS!

you're right - my UWS 2.2 server (Xmfb) is at 13Mb right now. That's
obscene.

Looks like it's back to R4 for me.

michaud@decvax.dec.com (Jeff Michaud) (02/21/90)

> 
>   kill -KILL `ps -aux | grep Xq | grep -v grep | colrm 15 | colrm 1 9`

	If you're on a DECstation, you don't want to use Xq, but probably just
	X (Xmfb and Xcfb are the names of the servers for mono and color respectively
	on the DECstation).

	(I also prefer using awk '{print $1}' instead of the colrm's, but
	that's just me :-)

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/

joel@decwrl.dec.com (Joel McCormack) (02/22/90)

My current X11 server has been running for a couple of days and is 2.9
megabytes.  You guys are doing something I'm not.

Please tell me how to cause a memory leak in the server, and I'll look
into it.  In particular, replies like ``Run dxyz with the following
.Xdefaults set, use the following commands, and exit.  Run it again. 
The server keeps getting bigger and bigger.'' are what I'm looking for. 
Replies like, ``Well, I've been running 86 different programs in the
last week, and the server is now 10 megabytes.'' aren't.

- Joel McCormack (decwrl!joel, joel@decwrl.dec.com)

bph@buengc.BU.EDU (Blair P. Houghton) (02/22/90)

In article <2849@bacchus.dec.com> joel@decwrl.dec.com (Joel McCormack) writes:
>My current X11 server has been running for a couple of days and is 2.9
>megabytes.  You guys are doing something I'm not.

You mean other than paying attention to our systems?

An Xqdsg or Xqvsm, when first started, goes about 800kB SIZE and
400kB RSS.

				--Blair
				  "Gad zooks, indeed."

bph@buengc.BU.EDU (Blair P. Houghton) (02/22/90)

In article <8518@shlump.nac.dec.com> michaud@decvax.dec.com (Jeff Michaud) writes:
>I wrote:
>>   kill -KILL `ps -aux | grep Xq | grep -v grep | colrm 15 | colrm 1 9`
>
>	If you're on a DECstation, you don't want to use Xq, but probably just
>	X (Xmfb and Xcfb are the names of the servers for mono and color respectively
>	on the DECstation).
>
>	(I also prefer using awk '{print $1}' instead of the colrm's, but
>	that's just me :-)

Ac-shully, you might want to use:  awk '{print $2}'.

And, don't change the one-liner use ps -l.  It doesn't list
the X servers by name, at least not if they were started or
restarted by hand.

				--Blair
				   "Pedantry for the Pedestrian
					    Since 1888."

michaud@decvax.dec.com (Jeff Michaud) (02/23/90)

> >>   kill -KILL `ps -aux | grep Xq | grep -v grep | colrm 15 | colrm 1 9`
> >
> >	If you're on a DECstation, you don't want to use Xq, but probably just
> >	X (Xmfb and Xcfb are the names of the servers for mono and color
respectively
> >	on the DECstation).
> >
> >	(I also prefer using awk '{print $1}' instead of the colrm's, but
> >	that's just me :-)
> Ac-shully, you might want to use:  awk '{print $2}'.

	Ac-shully I missed the "u" option you gave to ps.  Why bother
	having ps waste time doing getpwuid's, just use "ps ax" :-))).

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/
    
 
 
  
 
 
      
1

bph@buengc.BU.EDU (Blair P. Houghton) (02/24/90)

In article <8594@shlump.nac.dec.com> michaud@decvax.dec.com (Jeff Michaud) writes:
>> >>   kill -KILL `ps -aux | grep Xq | grep -v grep | colrm 15 | colrm 1 9`
>> >
>> >	(I also prefer using awk '{print $1}' instead of the colrm's, but

>> Ac-shully, you might want to use:  awk '{print $2}'.
>
>	Ac-shully I missed the "u" option you gave to ps.  Why bother
>	having ps waste time doing getpwuid's, just use "ps ax" :-))).

Ack.  Touche'.  My only excuse is "cruft."  You need the -u in order
to see that the X server has bloated, though not to kill it.  That
one-liner, of course, was built up from the command used to see
the problem.

				--Blair
				  "I go fix."

lutmann@geocub.greco-prog.fr (02/28/90)

In article <2849@bacchus.dec.com> joel@decwrl.dec.com (Joel McCormack) writes:
>My current X11 server has been running for a couple of days and is 2.9
>megabytes.  You guys are doing something I'm not.

Just 2.9 Mb ?! I really *CAN'T* believe it ! After only one day, my X server
is already more than 3 Mb (on a DS3100, Ultrix 3.0, 16 Mb RAM).

>Replies like, ``Well, I've been running 86 different programs in the
>last week, and the server is now 10 megabytes.'' aren't.

Ah ? Why not ?
If you want an example, just run 10 xtank, 10 xmoire, 10 xlife, 10 xgif... 
and other programs which require lots of graphic resources, and your X server
will be down !
Pixmap(s) and colormap(s) manipulations in big graphic applications require
both lots of memory and lots of graphic resources, especially the X server.
For instance, when we run GKS or PHIGS programs, the X server can grow up
to 12 Mb in memory (I say twelve!). That's enough, I presume ? Then, our
nice system swaps and swaps... :-(



                                        Johan 


.-----------------------------.    
|           Johan             |    ...!uunet!mcsun!inria!geocub!goofi!lutmann
| On goofi, at ENSERB, France |    ...!uunet!mcsun!inria!geocub!deimos!pat
`-----------------------------'