afc@shibaya.lonestar.org (Augustine Cano) (02/05/91)
My 3b1 had been up for more than a month, without any reboots. At some point I had the feeling that it was really slow when changing windows, via <SHIFT><SUSPEND> or <SHIFT><RESUME> (I'm running 3.51m). It looked like a lot of swapping, sometimes taking more than 5 seconds to get to the next/previous window. Of course the disk was hard at work in this period. Oh well, thought I, time to add RAM (I have 2 MB on the mother-board), but then I thought it wasn't this slow before, so I ran a test. With 3 windows open (through the UA), with nothing but shells in each of them, I tested response time. Then I rebooted. Three ksh windows, as before, but now trn running in one, elm on another and page on the third. You wouldn't believe the difference! window switching is now almost instantaneous, like it used to be. Not only that, but after the reboot 2 more daemons were started that were not there before: cron and mthreads. 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? -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc
craig@attcan.UUCP (Craig Campbell) (02/09/91)
In article <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? >-- >Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc I have found that, if I have a parallel port printer connected to the system, and the printer is powered off, a lot of disk activity occurs. The printer is, of course, configured as well. This seems related to a lot of activity by one of the first system processes (can't quite remember which one). Don't know why. Don't know if this helps. Fix was to leave printer on. later, craig
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
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