pjs@euclid.jpl.nasa.gov (Peter Scott) (10/29/90)
For some reason, this was never a problem on a Sun 3/160 with 8MB RAM, and yet here I am on a Sun 4/40 with 12MB RAM running out of memory all over the place.* A major culprit - as far as I can tell, I'm still new at this system-debugging thing - turns out to be the R4 server, which I had found doubled in size on various occasions. A little work with ps -v in a window turned up the following: Server after startup (running xbiff, xpostit, xfish, xterm -C, xterm, xrn, xman, xperfmon: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 4725 co R 1:49 0 99 156 1784 2264 xx 7.4 20.9 Xsun After a while, I used an mwm root menu command I set up to spawn an xterm -e rlogin <somehost>, and now: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 4725 co R 2:03 0 99 189 4188 2680 xx 15.6 24.8 Xsun Wow. I killed the xterm window: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 4725 co R 2:56 1 99 241 4188 2536 xx 9.4 23.5 Xsun Now, I'm still learning to interpret these things, but it doesn't seem to me that it changed that much. The RSS field steadily declined over a period of minutes, and that trend didn't seem to be affected by my opening another xterm window, until I opened two at a time: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 4725 co D 3:52 0 99 408 4828 3572 xx 12.1 33.0 Xsun Ouch! And after killing both new xterms: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 4725 co S 4:01 0 99 430 4828 3496 xx 11.0 32.3 Xsun Although it went *up* after just another couple of minutes during which time I was just typing in this window: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 4725 co S 4:21 0 99 459 4828 3616 xx 8.6 33.5 Xsun So what's up? We're running X11R4.18, mwm (1.0a), SunOS 4.1. * Mind you, the Sun-3 was mono and the Sun-4 is 8-bit color... -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@euclid.jpl.nasa.gov)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/29/90)
Nothing you have shown demonstrates a leak in the X server. It seems you
expect process size to eventually decrease. Try an experiment, compile and
run this simple program:
main()
{
free(malloc(8000000));
pause();
}
See if the process size ever goes down. If it doesn't, don't expect the
server's process size to ever go down. As for resident set size, I'd say
that's a bit more complicated, the RSS will depend on what algorithms your
OS uses, what other activity is going on in the system, how the vendor's
memory allocator works, and probably a bunch of other things. I would not
take it directly as a memory leak indicator.
Mind you, the Sun-3 was mono and the Sun-4 is 8-bit color...
The big jumps in process size are probably due to your having enabled
save-unders on menus.brossard@sasun1.epfl.ch (Alain Brossard EPFL-SIC/SII) (10/31/90)
In article <1990Oct28.204148.17437@elroy.jpl.nasa.gov>, pjs@euclid.jpl.nasa.gov (Peter Scott) writes: > For some reason, this was never a problem on a Sun 3/160 with 8MB RAM, > and yet here I am on a Sun 4/40 with 12MB RAM running out of memory > all over the place.* A major culprit - as far as I can tell, I'm still > new at this system-debugging thing - turns out to be the R4 server, > which I had found doubled in size on various occasions. A little work > with ps -v in a window turned up the following: I'm also having the same problem on a sun4/110, OS 4.1, X.V11R4, patch 18, cg4. I think the problem started happening when I started using Open Windows 2.0. My server has grown up to 25MBytes before I was forced to kill it. Now it is at 16MBytes: PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 161 ? R 399:14 0 99 181216160 2696 xx 11.0 14.0 Xsun killing everything but xdm doesn't help at all. You can imagine the swapping that sometimes occurs when the server is that big! I realize this isn't a proper bug report, but I haven't been able to find what applications causes the X server to grow so much. I do suspect the mailtool or maybe cm the calendar manager. -- Alain Brossard, Ecole Polytechnique Federale de Lausanne, SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse brossard@sasun1.epfl.ch