gst@gnosys.svle.ma.us (Gary S. Trujillo) (02/06/91)
In <1991Feb5.040416.354@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: > So, what is slowly degrading in the kernel that is fixed at boot time? > Has anybody else noticed this? Does anybody have a clue as to what it is? Yup. It's a memory leak of some sort in the window manager. Do a "ps -el" and take a look at the memory size numbers | v 1 S 0 17268 1 3 27 20 14d 18: 13 5af68 w4 2:36 wmgr I just killed and restarted wmgr recently, so not much memory has been consumed so far (I've seen the first number as high as 80 or 90). Let's see what I get if I kill and restart wmgr again: 1 S 0 20490 1 6 27 20 1e5 6: 12 5af68 w4 0:04 wmgr Maybe one of the UNIXpc development team out there who have access to the source code of wmgr can take a look for us. I've just learned to kill and restart wmgr every 2 or 3 days. Gary -- Gary S. Trujillo gst@gnosys.svle.ma.us Somerville, Massachusetts {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst
thad@public.BTR.COM (Thaddeus P. Floryan) (02/06/91)
In article <979@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >[...] >Yup. It's a memory leak of some sort in the window manager. Do a "ps -el" >and take a look at the memory size numbers | > v > 1 S 0 17268 1 3 27 20 14d 18: 13 5af68 w4 2:36 wmgr > >I just killed and restarted wmgr recently, so not much memory has been >consumed so far (I've seen the first number as high as 80 or 90). Let's >see what I get if I kill and restart wmgr again: > > 1 S 0 20490 1 6 27 20 1e5 6: 12 5af68 w4 0:04 wmgr > Weird. What is it that you're doing such that the wmgr uses so much time? Reason I ask is that my "main" system has been up nearly 3 months continuously, is used extremely heavily by multiple users, and shows nothing like what you describe; has 3.5MB RAM, running 3.51,, and the load is 0.03 with: thadlabs ksh 24989/24990> date Wed Feb 6 03:53:59 PST 1991 thadlabs ksh 24989/24990> uptime up 86 days 0:17:52 booted Mon Nov 12 03:36:12 1990 thadlabs ksh 24989/24990> who -b . system boot Nov 12 03:44 thadlabs ksh 24989/24990> ps -el F S UID PID PPID C PRI NI ADR SZ:RSZ WCHAN TTY TIME COMD 3 S 0 0 0255 0 20 53 0: 0 251bc ? 120354:56 swapper 1 S 0 1 0 3 49 20 56 6: 9 70900 ? 7:37 init 3 S 0 2 0 3 1 20 54 48: 0 4a1e0 ? 0:05 pagedaemon 3 S 0 3 0 3 3 20 55 0: 0 59770 ? 144:20 windaemon 1 S 102 19821 1 3 27 20 218 27: 5 5ae78 w1 0:07 ksh 1 S 0 22461 1 3 27 20 219 6: 10 1d920 ? 0:01 uugetty 1 S 0 183 1 3 27 20 1ba 6: 0 5ca14 001 0:01 uugetty 1 S 99 24989 204 3 40 20 36a 3: 0 4a410 p0 0:00 sl 1 S 102 24990 24989250 40 20 1e2 28: 6 4a480 p0 3:21 ksh 1 S 0 117 1 3 26 20 fe 10: 0 35ef5a ? 0:00 telnetd 1 S 0 97 1 3 28 20 10d 5: 0 330194 ? 0:00 rasdaemo 1 S 0 119 1 3 26 20 10f 16: 0 35ed5a ? 0:00 ftpd 1 S 0 121 1 3 26 20 13b 10: 5 35ea2e ? 47:45 rwhod 1 S 0 123 1 3 26 20 147 12: 0 35ebda ? 0:00 fingerd 1 S 0 18401 1 3 27 20 1c6 6: 9 5cb0e ? 0:00 uugetty 1 S 0 159 1 3 27 20 172 50: 21 5af18 w3 6:02 ph 1 S 0 166 1 3 27 20 186 5: 0 5af68 w4 0:08 wmgr 1 S 0 172 1 3 49 20 18e 20: 12 1eeec w5 151:26 smgr 1 S 0 184 1 3 27 20 1a3 6: 0 5ca6e ? 0:00 uugetty 1 S 0 179 1 4 49 20 1b3 4: 5 70900 ? 6:58 loadavgd 1 R 102 22470 24990 88 82 20 16d 7: 10 p0 0:03 ps 1 S 71 17314 1 3 26 20 31c 8: 10 4034e ? 0:03 lpsched 1 S 102 29446 1 3 49 25 162 4: 8 70900 w1 227:33 sysinfo 1 S 99 204 1 3 26 20 1f7 11: 10 4ab15 ? 0:03 listen 1 S 102 19831 1 3 49 25 1a9 4: 9 70900 w1 40:10 sysinfo 1 S 0 24248 1 3 26 20 28f 10: 0 35e05a ? 0:00 rexecd 1 S 0 24259 1 3 26 20 319 10: 0 35de5a ? 0:00 rlogind 1 S 0 24337 1 3 26 20 138 10: 4 35da5a ? 0:00 rshd thadlabs ksh 24989/24990> ps -ef UID PID PPID C STIME TTY TIME COMMAND root 0 0255 Nov 12 ? 120355:02 swapper root 1 0 3 Nov 12 ? 7:37 init root 2 0 3 Nov 12 ? 0:05 pagedaemon root 3 0 3 Nov 12 ? 144:20 windaemon thad 19821 1 3 Feb 4 w1 0:07 ksh root 22461 1 3 03:50:16 ? 0:01 uugetty root 183 1 3 Nov 12 001 0:01 uugetty listen 24989 204 3 Jan 9 p0 0:00 sl thad 24990 24989 10 Jan 9 p0 3:21 ksh root 117 1 3 Nov 12 ? 0:00 telnetd root 97 1 3 Nov 12 ? 0:00 rasdaemon root 119 1 3 Nov 12 ? 0:00 ftpd root 121 1 3 Nov 12 ? 47:45 rwhod root 123 1 3 Nov 12 ? 0:00 fingerd root 18401 1 3 Feb 3 ? 0:00 uugetty root 159 1 3 Nov 12 w3 6:02 ph root 166 1 3 Nov 12 w4 0:08 wmgr root 172 1 3 Nov 12 w5 151:26 smgr root 184 1 3 Nov 12 ? 0:00 uugetty root 179 1 3 Nov 12 ? 6:58 loadavgd thad 22471 24990181 03:54:33 p0 0:03 ps lp 17314 1 3 Jan 1 ? 0:03 lpsched thad 29446 1 6 Jan 14 w1 227:33 sysinfo listen 204 1 3 Nov 12 ? 0:03 listen thad 19831 1 6 Feb 4 w1 40:11 sysinfo root 24248 1 3 Jan 9 ? 0:00 rexecd root 24259 1 3 Jan 9 ? 0:00 rlogind root 24337 1 3 Jan 9 ? 0:00 rshd Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
afc@shibaya.lonestar.org (Augustine Cano) (02/08/91)
In article <979@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >In <1991Feb5.040416.354@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: > >> So, what is slowly degrading in the kernel that is fixed at boot time? >> Has anybody else noticed this? Does anybody have a clue as to what it is? > >Yup. It's a memory leak of some sort in the window manager. Do a "ps -el" >and take a look at the memory size numbers | > v > 1 S 0 17268 1 3 27 20 14d 18: 13 5af68 w4 2:36 wmgr > >I just killed and restarted wmgr recently, so not much memory has been >consumed so far (I've seen the first number as high as 80 or 90). Let's >see what I get if I kill and restart wmgr again: > > 1 S 0 20490 1 6 27 20 1e5 6: 12 5af68 w4 0:04 wmgr > >Maybe one of the UNIXpc development team out there who have access to >the source code of wmgr can take a look for us. I've just learned to >kill and restart wmgr every 2 or 3 days. This is not a leak, it's a FLOOD! I just hit the <SHIFT><RESUME> button 24 times and that was enough to bump the memory size by 1. Please, somebody with source, would it be possible to either get a patch to fix this or to store a fixed binary version at osu? >Gary > >-- > Gary S. Trujillo gst@gnosys.svle.ma.us >Somerville, Massachusetts {wjh12,bu.edu,spdcc,ima,cdp}!gnosys!gst -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc
bruce@balilly.UUCP (Bruce Lilly) (02/09/91)
In article <1991Feb7.161712.9239@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >In article <979@gnosys.svle.ma.us> gst@gnosys.svle.ma.us (Gary S. Trujillo) writes: >>In <1991Feb5.040416.354@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >> >>> So, what is slowly degrading in the kernel that is fixed at boot time? >>> Has anybody else noticed this? Does anybody have a clue as to what it is? >> >>Yup. It's a memory leak of some sort in the window manager. Do a "ps -el" >>and take a look at the memory size numbers | >> v >> 1 S 0 17268 1 3 27 20 14d 18: 13 5af68 w4 2:36 wmgr >> >>I just killed and restarted wmgr recently, so not much memory has been >>consumed so far (I've seen the first number as high as 80 or 90). Let's >>see what I get if I kill and restart wmgr again: >> >> 1 S 0 20490 1 6 27 20 1e5 6: 12 5af68 w4 0:04 wmgr >> >>Maybe one of the UNIXpc development team out there who have access to >>the source code of wmgr can take a look for us. I've just learned to >>kill and restart wmgr every 2 or 3 days. > >This is not a leak, it's a FLOOD! I just hit the <SHIFT><RESUME> button >24 times and that was enough to bump the memory size by 1. Now hold on just a minute. While the above sounds plausible, I'm not 100% convinced. I have 2 machines. The one I'm posting from has been up about a month, switching windows is rapid, no phone manager running. Here's the output from ps -elf: (oh yes: 3.5MB, Ethernet, combo card) F S UID PID PPID C PRI NI ADR SZ:RSZ WCHAN STIME TTY TIME COMD 3 S root 0 0 0 0 20 4d 0: 0 264a8 Jan 11 ? 36267:18 swapper 1 S root 1 0 3 49 20 50 6: 6 70900 Jan 11 ? 5:50 init 3 S root 2 0 0 1 20 4e 48: 0 466ac Jan 11 ? 0:42 pagedaemon 3 S root 3 0 0 3 20 4f 0: 0 5377c Jan 11 ? 227:38 windaemon 1 S bruce 206 1 3 27 20 6e 38: 7 54e74 Jan 11 w1 1:35 ksh 1 S root 10908 1 3 27 20 399 6: 5 37ca1c 19:29:17 001 0:01 uugetty 1 S root 157 1 3 27 20 220169: 35 54f14 Jan 11 w3 52:11 wmgr 1 S root 161 1 3 49 20 2fc 29: 17 1ff3c Jan 11 w4 67:13 smgr 1 S root 4489 1 3 49 20 205 4: 0 70900 Feb 4 w5 0:01 .phclr 1 S root 75 1 3 26 20 297 3: 0 374a5a Jan 11 ? 0:01 timed 1 S root 58 1 3 26 20 252 10: 0 376f5a Jan 11 ? 0:00 telnetd 1 S root 60 1 3 26 20 25c 16: 0 376d5a Jan 11 ? 0:00 ftpd 1 S root 62 1 3 26 20 24e 8: 0 376bae Jan 11 ? 0:00 tftpd 1 S root 64 1 3 26 20 256 10: 0 376ada Jan 11 ? 0:00 rlogind 1 S root 66 1 3 26 20 2a2 10: 5 37662e Jan 11 ? 14:03 rwhod 1 S root 68 1 3 26 20 2ae 10: 0 37695a Jan 11 ? 0:01 rshd 1 S root 70 1 3 26 20 2b9 12: 0 3767da Jan 11 ? 0:00 fingerd 1 S root 72 1 3 26 20 2c4 10: 0 37655a Jan 11 ? 0:00 rexecd 1 S root 7870 1 3 26 20 3e4 42: 15 374f5a Feb 6 ? 1:36 sendmail 1 S root 77 1 3 26 20 2d1 22: 0 3761da Jan 11 ? 0:00 nntpd 1 S bruce 11002 10899 3 40 20 54 31: 9 46e8c 19:51:11 w8 0:04 ksh 1 S root 3979 1 3 27 20 3c0 35: 13 54ec4 Jan 14 w2 8:31 ksh 1 S uucp 8082 1 3 27 20 3f4 34: 0 55054 Feb 6 w7 0:04 ksh 1 S bin 29102 1 3 27 20 30c 35: 1 55004 Feb 1 w6 2:28 ksh 1 S bruce 10899 1 3 40 20 3d9 50: 29 4704c 19:26:07 w8 0:17 rn 1 S lp 177 1 3 26 20 354 8: 0 42662 Jan 11 ? 0:06 lpsched 1 R bruce 11011 11002 6 26 20 221 63: 20 19:51:26 w8 0:11 vi 1 Z bruce 11012 11011 13 73 20 <defunct> 1 S bruce 11013 11011 45 40 20 3e1 30: 7 4720c 19:54:06 w8 0:02 ksh 1 R bruce 11014 11013204 111 20 69 7: 11 19:54:09 w8 0:02 ps Note the large numbers for size of wmgr. My other machine has been up about the same amount of time, wmgr numbers are much smaller, window switching is painfully slow, AND ph is running there (and is pretty big also). Configuration is 2MB, Ethernet. Here's output from ps -elf there: F S UID PID PPID C PRI NI ADR SZ:RSZ WCHAN STIME TTY TIME COMD 3 S root 0 0 0 0 20 53 0: 0 264a8 Jan 13 ? 35976:05 swapper 1 S root 1 0 7 49 20 56 6: 4 70900 Jan 13 ? 8:15 init 3 S root 2 0 0 1 20 54 48: 0 4d150 Jan 13 ? 1:27 pagedaemon 3 S root 3 0 0 3 20 55 0: 0 5977c Jan 13 ? 85:47 windaemon 1 S bruce 275 1 7 27 20 74 33: 0 5ae74 Jan 13 w1 0:27 ksh 1 S root 260 1 7 27 20 1e0 81: 12 5b004 Jan 13 w6 15:40 ph 1 S root 234 1 7 27 20 a5 60: 0 5af14 Jan 13 w3 16:52 wmgr 1 S root 238 1 7 49 20 128 49: 4 1ff3c Jan 13 w4 66:51 smgr 1 S root 8833 75 11 26 20 177 11: 6 3786e0 19:56:41 ? 0:00 rshd 1 S root 82 1 3 26 20 d7 3: 0 37cbda Jan 13 ? 0:01 timed 1 S root 65 1 3 26 20 d8 10: 0 37df5a Jan 13 ? 0:00 telnetd 1 S root 67 1 3 26 20 f2 16: 0 37dd5a Jan 13 ? 0:00 ftpd 1 S root 69 1 3 26 20 dd 8: 0 37dbae Jan 13 ? 0:00 tftpd 1 S root 71 1 3 26 20 11a 10: 0 37dada Jan 13 ? 0:01 rlogind 1 S root 73 1 7 26 20 131 10: 5 37d7ae Jan 13 ? 15:59 rwhod 1 S root 75 1 7 26 20 134 10: 5 37d95a Jan 13 ? 0:14 rshd 1 S root 77 1 3 26 20 13f 12: 0 37d6da Jan 13 ? 0:00 fingerd 1 S root 79 1 3 26 20 14a 10: 0 37d55a Jan 13 ? 0:00 rexecd 1 S root 88 1 7 26 20 151 41: 7 37d0da Jan 13 ? 14:17 sendmail 1 S root 84 1 7 26 20 157 22: 8 37d1da Jan 13 ? 0:05 nntpd 1 S root 314 1 7 27 20 1e2 33: 0 5aec4 Jan 13 w2 2:52 ksh 1 S lp 243 1 7 26 20 186 8: 0 4904a Jan 13 ? 0:06 lpsched 1 S root 8762 84 7 26 20 150 31: 15 37c92e 19:26:26 ? 0:05 nntpd 1 S bruce 8834 8833 13 40 20 b2 22: 4 4da80 19:56:42 ? 0:00 sh 1 R bruce 8835 8834175 103 20 8e 7: 11 19:56:43 ? 0:03 ps 1 S root 26795 1 7 27 20 123 31: 14 5b054 Feb 3 w7 8:54 watch 1 S bin 23327 1 7 27 20 71 33: 0 5b0f4 Feb 1 w9 0:15 ksh 1 S root 1234 1 8 27 20 18b 31: 6 5b0a4 Feb 5 w8 52:54 watch I just walked into the other room, killed ph, checked window switching (much, much better), restarted ph, rechecked window switching speed (still good). More ps -elf output: F S UID PID PPID C PRI NI ADR SZ:RSZ WCHAN STIME TTY TIME COMD 3 S root 0 0 0 0 20 53 0: 0 264a8 Jan 13 ? 35981:59 swapper 1 S root 1 0 7 49 20 56 6: 4 70900 Jan 13 ? 8:15 init 3 S root 2 0 0 1 20 54 48: 0 4d150 Jan 13 ? 1:27 pagedaemon 3 S root 3 0 0 3 20 55 0: 0 5977c Jan 13 ? 85:48 windaemon 1 S bruce 275 1 7 27 20 74 33: 0 5ae74 Jan 13 w1 0:27 ksh 1 S root 8853 75 9 26 20 148 11: 6 3786e0 20:03:04 ? 0:00 rshd 1 S root 234 1 7 27 20 a5 61: 56 5af14 Jan 13 w3 17:06 wmgr 1 S root 238 1 7 49 20 128 49: 3 1ff3c Jan 13 w4 66:52 smgr 1 S adm 8845 8842 0 49 20 1db 3: 0 70900 20:00:05 w4 0:00 sa1 1 S root 82 1 3 26 20 d7 3: 0 37cbda Jan 13 ? 0:01 timed 1 S root 65 1 3 26 20 d8 10: 0 37df5a Jan 13 ? 0:00 telnetd 1 S root 67 1 3 26 20 f2 16: 0 37dd5a Jan 13 ? 0:00 ftpd 1 S root 69 1 3 26 20 dd 8: 0 37dbae Jan 13 ? 0:00 tftpd 1 S root 71 1 3 26 20 11a 10: 0 37dada Jan 13 ? 0:01 rlogind 1 S root 73 1 7 26 20 131 10: 5 37d7ae Jan 13 ? 15:59 rwhod 1 S root 75 1 7 26 20 134 10: 4 37d95a Jan 13 ? 0:14 rshd 1 S root 77 1 3 26 20 13f 12: 0 37d6da Jan 13 ? 0:00 fingerd 1 S root 79 1 3 26 20 14a 10: 0 37d55a Jan 13 ? 0:00 rexecd 1 S root 88 1 7 26 20 151 41: 0 37d0da Jan 13 ? 14:17 sendmail 1 S root 84 1 7 26 20 157 22: 0 37d1da Jan 13 ? 0:05 nntpd 1 S root 314 1 7 27 20 1e2 33: 7 5aec4 Jan 13 w2 2:52 ksh 1 S lp 243 1 7 26 20 186 8: 0 4904a Jan 13 ? 0:06 lpsched 1 S root 8762 84 7 26 20 150 31: 1 37c92e 19:26:26 ? 0:05 nntpd 1 S root 8848 1 7 27 20 19a 79: 19 5afb4 20:01:01 sys 0:00 ph 1 S root 8842 1 7 40 20 d6 22: 0 4daf0 20:00:01 w4 0:00 sh 1 S root 26795 1 7 27 20 123 31: 10 5b054 Feb 3 w7 8:55 watch 1 S bin 23327 1 7 27 20 71 33: 0 5b0f4 Feb 1 w9 0:15 ksh 1 S root 1234 1 7 27 20 18b 31: 6 5b0a4 Feb 5 w8 52:54 watch 1 S bruce 8854 8853 12 40 20 1e5 22: 4 4dcb0 20:03:05 ? 0:00 sh 1 R bruce 8855 8854173 103 20 1d9 7: 11 20:03:05 ? 0:03 ps ph size is still the largest, wmgr size went up, BUT window switching is faster. I still can't say exactly what the slow window switching is caused by, but the above simple experiment seems to suggest that it's not solely due to the size of the wmgr process. It might be some interaction with the phone manager (which has an annoying tendency to pop open a window everytime the phone rings), then again it might not be. I just don't know. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
michael@stb.info.com (Michael Gersten) (02/11/91)
In article <1991Feb9.011213.8868@blilly.UUCP> bruce@balilly.UUCP (Bruce Lilly) writes: > F S UID PID PPID C PRI NI ADR SZ:RSZ WCHAN STIME TTY TIME COMD <3.5 meg machine, good speed> > 1 S root 157 1 3 27 20 220169: 35 54f14 Jan 11 w3 52:11 wmgr <2 meg machine, slow speed> > 1 S root 234 1 7 27 20 a5 60: 0 5af14 Jan 13 w3 16:52 wmgr <2 meg machine, good speed> > 1 S root 234 1 7 27 20 a5 61: 56 5af14 Jan 13 w3 17:06 wmgr What these have in common is the RESIDENT size of wmgr. The slow speed on the middle one is because wmgr is completely swapped out on the disk. So any suspend/resume activity causes it to be swapped in. Both of the other cases have wmgr resident in memory (or at least enough of it). A recently restarted wmgr has a smaller working set size needed to switch. Therefore, it will be faster. Michael -- Michael michael@stb.info.com denwa!stb!michael anes.ucla.edu!stb!michael "Space is an illusion; disk space doubly so"
afc@shibaya.lonestar.org (Augustine Cano) (02/11/91)
In article <1991Feb9.011213.8868@blilly.UUCP> bruce@balilly.UUCP (Bruce Lilly) writes: >Previous messages by: afc@shibaya.lonestar.org, gst@gnosys.svle.ma.us, afc@shibaya.lonestar.org: >>> >>> [ how the wmgr memory leak makes wmgr bigger, and killing it makes >>> it smaller again ] >> >>This is not a leak, it's a FLOOD! I just hit the <SHIFT><RESUME> button >>24 times and that was enough to bump the memory size by 1. > >Now hold on just a minute. While the above sounds plausible, I'm not 100% >convinced. I have 2 machines. The one I'm posting from has been up about >a month, switching windows is rapid, no phone manager running. Here's the >output from ps -elf: (oh yes: 3.5MB, Ethernet, combo card) ^^^^^ Here's the key: 1.5 Mb additional memory. It will take wmgr much longer to get big enough to slow down swapping appreciably. >... > 1 S root 157 1 3 27 20 220169: 35 54f14 Jan 11 w3 52:11 wmgr >... > >Note the large numbers for size of wmgr. >My other machine has been up about the same amount of time, wmgr numbers are much >smaller, window switching is painfully slow, AND ph is running there (and >is pretty big also). Configuration is 2MB, Ethernet. Here's output from ps -elf there: More stuff in favor of the other machine. Much less RAM, and an additional (BIG) program running. Also, the smaller wmgr seems to indicate that you use it less on this machine, right? >... > 1 S root 260 1 7 27 20 1e0 81: 12 5b004 Jan 13 w6 15:40 ph > 1 S root 234 1 7 27 20 a5 60: 0 5af14 Jan 13 w3 16:52 wmgr >... > >I just walked into the other room, killed ph, checked window switching >(much, much better), restarted ph, rechecked window switching speed (still >good). More ps -elf output: Well, yes... You have one less big program running, so the memory is available for use by wmgr with less swapping. The "still good" speed, was it before ph was used for anything? If so, the non-resident part was probably completely swapped out. Just wait 'til ph starts popping up windows and has to be swapped out... >... > 1 S root 234 1 7 27 20 a5 61: 56 5af14 Jan 13 w3 17:06 wmgr >... > 1 S root 8848 1 7 27 20 19a 79: 19 5afb4 20:01:01 sys 0:00 ph >... > > ph size is still the largest, wmgr size went up, BUT window switching is > faster. I still can't say exactly what the slow window switching is > caused by, but the above simple experiment seems to suggest that it's > not solely due to the size of the wmgr process. It might be some > interaction with the phone manager (which has an annoying tendency to > pop open a window everytime the phone rings), then again it might not > be. I just don't know. I suspect it is affected by all programs running, since they all compete for the memory. In any case wmgr has no business growing like it does. This is my wmgr entry, after running for 6 days 12 hours 18 minutes. It has been getting bigger and bigger. 1 S root 143 1 3 27 20 df 58: 0 5af64 Feb 4 w4 9:45 wmgr Someone else said something about this slowdown happening when a printer is connected to the parallel port but not turned on. I haven't tested this yet. Has anyone else had this experience? >-- > Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc