I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
KDE, Gnome, or other WM?
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
I don't know what to tell you then because, like you, I use gnome but not evolution. So our systems-- what of them which are directly related to clock-applet-- are much the same, yet you have a memory problem with clock-applet which I don't.
Here are some items to compare:
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 9d21ca21a0e99ad26aa10e1cd5b42024 /usr/libexec/clock-applet
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
I don't know what to tell you then because, like you, I use gnome but not evolution. So our systems-- what of them which are directly related to clock-applet-- are much the same, yet you have a memory problem with clock-applet which I don't.
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
in which I note it is now up to "149m".
Here are some items to compare:
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 9d21ca21a0e99ad26aa10e1cd5b42024 /usr/libexec/clock-applet
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 2bc9a73a5251d1b4747ec133839412b7 /usr/libexec/clock-applet
it's the same version and size as yours, but the md5sum differs. have you perhaps disabled prelink? (I don't call that I have ever done so) It's not obvious to me what other (legitimate) event would account for the difference in checksum.
If I run:
rpm -V -v gnome-panel
it shows no differences at all, so I don't think the clock-applet has been damaged or hacked. (but I wonder what it shows on your system, since yours has a different md5sum.)
........ /usr/libexec/clock-applet
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/07/2013 11:18 AM, fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
I don't know what to tell you then because, like you, I use gnome but not evolution. So our systems-- what of them which are directly related to clock-applet-- are much the same, yet you have a memory problem with clock-applet which I don't.
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
in which I note it is now up to "149m".
Here are some items to compare:
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 9d21ca21a0e99ad26aa10e1cd5b42024 /usr/libexec/clock-applet
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 2bc9a73a5251d1b4747ec133839412b7 /usr/libexec/clock-applet
I checked on one of my CentOS 5.8 systems and the size and version match. The md5sum is different, probably due to prelink. No way for me to check memory leak without opening a gnome desktop, which I will try later, once I work out how to access via another gateway server.
it's the same version and size as yours, but the md5sum differs. have you perhaps disabled prelink? (I don't call that I have ever done so) It's not obvious to me what other (legitimate) event would account for the difference in checksum.
If I run:
rpm -V -v gnome-panel
it shows no differences at all, so I don't think the clock-applet has been damaged or hacked. (but I wonder what it shows on your system, since yours has a different md5sum.)
........ /usr/libexec/clock-applet
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/06/2013 05:18 PM fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
I don't know what to tell you then because, like you, I use gnome but not evolution. So our systems-- what of them which are directly related to clock-applet-- are much the same, yet you have a memory problem with clock-applet which I don't.
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
in which I note it is now up to "149m".
Here are some items to compare:
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 9d21ca21a0e99ad26aa10e1cd5b42024 /usr/libexec/clock-applet
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 2bc9a73a5251d1b4747ec133839412b7 /usr/libexec/clock-applet
it's the same version and size as yours, but the md5sum differs. have you perhaps disabled prelink? (I don't call that I have ever done so) It's not obvious to me what other (legitimate) event would account for the difference in checksum.
Take a look in /etc/sysconfig/prelink. At the top it should tell you if you've got prelink on. You should also have a file called prelink in /etc/cron.daily/.
If none of that explains things, you might want to just reinstall gnome-panel and see if that fixes the memory problem.
If I run:
rpm -V -v gnome-panel
it shows no differences at all, so I don't think the clock-applet has been damaged or hacked. (but I wonder what it shows on your system, since yours has a different md5sum.)
........ /usr/libexec/clock-applet
Yeah, same here.
The clock applet would be a weird thing for somebody to hack. But maybe you're seeing an early sign of a disk problem. Bit rot or something like it could "damage" the executable.
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
On 01/06/2013 05:18 PM fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
I don't know what to tell you then because, like you, I use gnome but not evolution. So our systems-- what of them which are directly related to clock-applet-- are much the same, yet you have a memory problem with clock-applet which I don't.
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
it's now up to "156m". :(
in which I note it is now up to "149m".
Here are some items to compare:
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 9d21ca21a0e99ad26aa10e1cd5b42024 /usr/libexec/clock-applet
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 2bc9a73a5251d1b4747ec133839412b7 /usr/libexec/clock-applet
it's the same version and size as yours, but the md5sum differs. have you perhaps disabled prelink? (I don't call that I have ever done so) It's not obvious to me what other (legitimate) event would account for the difference in checksum.
Take a look in /etc/sysconfig/prelink. At the top it should tell you if you've got prelink on. You should also have a file called prelink in /etc/cron.daily/.
yes, it's on. there's a log in /var/log/prelink from just yesterday morning.
wouldn't ya think that if prelink has modified it, that the rpm -V would have flagged a modified checksum? Or is prelink smart enuff to tweak the RPM database? I have no clue.
If none of that explains things, you might want to just reinstall gnome-panel and see if that fixes the memory problem.
might try that, though it pains me to have to resort to the sort of "fixes" that Windows folks think are normal: power off, power on: reinstall: reboot. Gah! :)
If I run:
rpm -V -v gnome-panel
it shows no differences at all, so I don't think the clock-applet has been damaged or hacked. (but I wonder what it shows on your system, since yours has a different md5sum.)
........ /usr/libexec/clock-applet
Yeah, same here.
The clock applet would be a weird thing for somebody to hack. But maybe you're seeing an early sign of a disk problem. Bit rot or something like it could "damage" the executable.
I suppose it's POSSIBLE. I'm running two identical drives in a RAID-1 configuration, but as I understand it, RAID doesn't cover things like invalid/incorrect reads from a drive, it merely provides redundancy in case of total failure.
Thanks for the ideas, I'll post back to the list if anything interesting turns up.
Fred
On 01/04/2013 05:11 PM fred smith wrote:
I've discovered recently that something on my Centos 5.8 box (up to date) is hogging a ton of RAM.
so a little while ago I sat and watched top for a while. it showed (sorry, I didn't take screen shots or write this down, so the numbers are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, and all the RAM (except for the little the kernel keeps for itself) was in use (it's got 4 gigs).
this might not sound bad, but there's hardly ever anything big running on this box, it's just my home desktop machine used mostly for web browsing/music/email and similar.
so, watching top run for a while I could eventually make out that something had "1.6g" flashing in the "RES" column. slowing the refresh a little I saw that it was "clock applet". so I killed the clock applet and restarted it, then clock applet showed "11m" in the "RES" column, and the unused RAM was suddenly like a gig and 3/4, or so, and the swap used slowly started dropping while the free ram began being used up, as it normally should.
as I continue to watch it run (10-15 mins later) I can see that clock applet is now showing 14m in the RES column, so it's still growing.
Is anyone else seeing the clock applet hogging (tons of tiny leaks, I assume) RAM needlessly?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
On 01/06/2013 05:18 PM fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
Do you use evolution?
no, I have never found it to my liking.
KDE, Gnome, or other WM?
gnome.
I don't know what to tell you then because, like you, I use gnome but not evolution. So our systems-- what of them which are directly related to clock-applet-- are much the same, yet you have a memory problem with clock-applet which I don't.
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
it's now up to "156m". :(
in which I note it is now up to "149m".
Here are some items to compare:
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 9d21ca21a0e99ad26aa10e1cd5b42024 /usr/libexec/clock-applet
# rpm -q gnome-panel gnome-panel-2.16.1-7.el5 # ll /usr/libexec/clock-applet -rwxr-xr-x 1 root root 88048 May 24 2008 /usr/libexec/clock-applet # md5sum /usr/libexec/clock-applet 2bc9a73a5251d1b4747ec133839412b7 /usr/libexec/clock-applet
it's the same version and size as yours, but the md5sum differs. have you perhaps disabled prelink? (I don't call that I have ever done so) It's not obvious to me what other (legitimate) event would account for the difference in checksum.
Take a look in /etc/sysconfig/prelink. At the top it should tell you if you've got prelink on. You should also have a file called prelink in /etc/cron.daily/.
yes, it's on. there's a log in /var/log/prelink from just yesterday morning.
wouldn't ya think that if prelink has modified it, that the rpm -V would have flagged a modified checksum? Or is prelink smart enuff to tweak the RPM database? I have no clue.
Think about what we've already discovered. You and I have different results from md5sum, yet neither of our clock-applet files are flagged. So we do have some kind of clue. Without digging into code and running tests etc., I'm guessing that rpm must amend/revise its database contingent upon prelink's being invoked.
If none of that explains things, you might want to just reinstall gnome-panel and see if that fixes the memory problem.
might try that, though it pains me to have to resort to the sort of "fixes" that Windows folks think are normal: power off, power on: reinstall: reboot. Gah! :)
I know that feeling too. But, first, you shouldn't have to reboot... probably not, because this gnome stuff should load only at runlevel 5. Trace out the init scripts if you want to be sure. If so, that would mean you only need to "init 2 (or maybe just 3); rpm -e gnome-panel; yum install gnome-panel; init 5". That's really not very windozey. You might also want to determine whether that command sequence will wipe your current panel configuration and, if so, which files to backup prior and restore later (so you wouldn't have to set up your panel all over again). Do Windows folks do that?
1a: It just occurred to me that (and this is a long shot, but still a possibility) the problem could go away just by reloading the applet. Just delete it from the panel and then install it again. Then watch its memory consumption to see if there's a difference. Even if this works, it likely wouldn't be anything more than a temporary fix, but it might point to where the problem lies. And it's a real quick and easy.
Secondly, if the fate of the universe hung from our discovering exactly what the origin of the memory problem was, then yeah, it would be worth the effort. But it doesn't. There are lots of other and bigger issues around and dwelling on this little one would give people to think that we have too much time on our hands and that we don't know about all that bigger stuff.
#C: Reinstalling might not actually fix the problem, but only make the current memory problem go away... or maybe not even that. The actual origin of the problem could be lurking in a lot places, e.g., with the drive (which see below), with a small bit of the RAM where the executable got parked,....
If I run:
rpm -V -v gnome-panel
it shows no differences at all, so I don't think the clock-applet has been damaged or hacked. (but I wonder what it shows on your system, since yours has a different md5sum.)
........ /usr/libexec/clock-applet
Yeah, same here.
The clock applet would be a weird thing for somebody to hack. But maybe you're seeing an early sign of a disk problem. Bit rot or something like it could "damage" the executable.
I suppose it's POSSIBLE. I'm running two identical drives in a RAID-1 configuration, but as I understand it, RAID doesn't cover things like invalid/incorrect reads from a drive, it merely provides redundancy in case of total failure.
Correct. RAID 1 is lots better than JBOD, but doesn't do parity. I've run RAID 10 (and others) but never RAID 1, so I'm not sure about this... but there might be raid tools around that allows the examination and comparison of data on each drive separately. Perhaps the file is corrupt on one drive, but okay on the other. Failing a tool to do that, you may be able to take one of the disks out of the RAID, mount it separately as a data drive, and compare the files by hand. Of course you want to first be confident that you could re-mirror the drives.
Thanks for the ideas, I'll post back to the list if anything interesting turns up.
Fred
On 01/04/2013 05:11 PM fred smith wrote: > I've discovered recently that something on my Centos 5.8 box (up to date) > is hogging a ton of RAM. > > so a little while ago I sat and watched top for a while. it showed > (sorry, I didn't take screen shots or write this down, so the numbers > are a bit rough) that out of 8 gigs of swap, around 2 1/2 was in use, > and all the RAM (except for the little the kernel keeps for itself) > was in use (it's got 4 gigs). > > this might not sound bad, but there's hardly ever anything big running > on this box, it's just my home desktop machine used mostly for web > browsing/music/email and similar. > > so, watching top run for a while I could eventually make out that > something had "1.6g" flashing in the "RES" column. slowing the refresh > a little I saw that it was "clock applet". so I killed the clock applet > and restarted it, then clock applet showed "11m" in the "RES" column, > and the unused RAM was suddenly like a gig and 3/4, or so, and the > swap used slowly started dropping while the free ram began being used up, > as it normally should. > > as I continue to watch it run (10-15 mins later) I can see that clock > applet is now showing 14m in the RES column, so it's still growing. > > Is anyone else seeing the clock applet hogging (tons of tiny leaks, I > assume) RAM needlessly? > _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
ken wrote:
On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
On 01/06/2013 05:18 PM fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote: > Fred, > > Also running an up-to-date 5.8 but with just 2G of RAM, > clock-applet consumes the following: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
<snip>
it's the same version and size as yours, but the md5sum differs. have you perhaps disabled prelink? (I don't call that I have ever done so) It's not obvious to me what other (legitimate) event would account for the difference in checksum.
<snip> I've not been in this thread, but the above cmt *deeply* disturbs me. I'd start by yum remove the package with the applet and reinstall... after double checking what mirror it's getting the package from.
Yes, an infected repo is what's running through my mind, or a hijacked URL.
mark
m.roth@5-cent.us wrote:
ken wrote:
On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
On 01/06/2013 05:18 PM fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote: > On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote: >> Fred, >> >> Also running an up-to-date 5.8 but with just 2G of RAM, >> clock-applet consumes the following: >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
<snip> >>>> it's the same version and size as yours, but the md5sum differs. have >>>> you perhaps disabled prelink? (I don't call that I have ever done so) >>>> It's not obvious to me what other (legitimate) event would account for >>>> the difference in checksum. <snip> I've not been in this thread, but the above cmt *deeply* disturbs me. I'd start by yum remove the package with the applet and reinstall... after double checking what mirror it's getting the package from.
Yes, an infected repo is what's running through my mind, or a hijacked URL.
highly unlikely IMO. Remember: packages are signed. A bad guy would also need to have the centos key...
and I believe prelink does this sort of thing.
Nicolas Thierry-Mieg wrote:
m.roth@5-cent.us wrote:
ken wrote:
On Sun, Jan 06, 2013 at 06:23:20PM -0500, ken wrote:
On 01/06/2013 05:18 PM fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote: > On 01/06/2013 09:55 AM fred smith wrote: >> On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote: >>> >>> Also running an up-to-date 5.8 but with just 2G of RAM, >>> clock-applet consumes the following: >>> >>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>> 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 >>> clock-applet
<snip> >>>> it's the same version and size as yours, but the md5sum differs. >>>> have you perhaps disabled prelink? (I don't call that I have ever done >>>> so) It's not obvious to me what other (legitimate) event would account >>>> for the difference in checksum. <snip> I've not been in this thread, but the above cmt *deeply* disturbs me. I'd >> start by yum remove the package with the applet and reinstall...
after
double checking what mirror it's getting the package from.
Yes, an infected repo is what's running through my mind, or a hijacked URL.
highly unlikely IMO. Remember: packages are signed. A bad guy would also need to have the centos key...
and I believe prelink does this sort of thing.
Would change the md5sum of the package?
mark
On Mon, Jan 7, 2013 at 8:10 AM, m.roth@5-cent.us wrote:
Nicolas Thierry-Mieg wrote:
and I believe prelink does this sort of thing.
Would change the md5sum of the package?
prelink does change the md5sum. One needs to unprelink (use the -u flag) before comparing the hash value.
Akemi
On 01/07/2013 08:14 AM, Akemi Yagi wrote:
prelink does change the md5sum. One needs to unprelink (use the -u flag) before comparing the hash value.
Indeed. The prelink binary has --md5 and --sha flags to print the hash of the binary without prelink's data, and should be used in this case.
On 01/06/2013 06:32 PM, fred smith wrote:
yes, it's on. there's a log in /var/log/prelink from just yesterday morning.
wouldn't ya think that if prelink has modified it, that the rpm -V would have flagged a modified checksum? Or is prelink smart enuff to tweak the RPM database? I have no clue.
rpm is smart enough to undo the prelinking (to a temporary file) before verifying the checksum. IIRC, it also then re-prelinks the temp file and verifies that the result matches the current file on disk.
On 2013-01-06 23:18, fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
[...]
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
in which I note it is now up to "149m".
I had that problem also a few years back (CentOS 5.1, 5.2 or so). When Googling for it, I had found several bug reports about it. While some of those bug reports had some fixes in a "future" version mentioned, other bugreports mentioned that the problem disappeared all by itself.
And indeed, for me too, some upgrades later, the problem disappeared for me too.
Then I fell over:
https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories https://live.gnome.org/MemoryReduction
which seems to imply that the shared libraries of all stuff used by Gnome gets measured in one of the gnome programs, frequently the clock-applet apparently.
That implies that this problem is a red herring. I just means that during the lifetime of Gnome, there were lots of shared libraries loaded, and that memory shows up for 1 applet only.
And, yes indeed, looking carefully I notice that now the black sheep getting all the blame is the wnck-applet for me currently, instead of the clock-applet. It's using 342m memory now (68 days uptime, without logout of gnome).
And yes, googling for "wnck-applet memory" instead of "clock-applet memory" brings up a very similar list of bug reports, also telling sometimes it the problem disappeared all by itself.
To find out which libraries all get counted for the clock-applet, run "pmap -x PID-of-clock-applet" on regular times, and see where the increase in memory is coming from.
Maybe try valgrind... But after testing it on a few basic utilities like ls, find xclock, it seems that many of them do have leaks...
JD
Am 08.01.2013 um 16:19 schrieb m.roth@5-cent.us:
John Doe wrote:
Maybe try valgrind... But after testing it on a few basic utilities like ls, find xclock, it seems that many of them do have leaks...
More reason to dislike gnome....
mark
confirmation bias - you only see what you want to see :-)
-- LF
Leon Fauster wrote:
Am 08.01.2013 um 16:19 schrieb m.roth@5-cent.us:
John Doe wrote:
Maybe try valgrind... But after testing it on a few basic utilities like ls, find xclock, it seems that many of them do have leaks...
More reason to dislike gnome....
confirmation bias - you only see what you want to see :-)
Along with bloat, and then there's things like trying to configure it *bleah*. And I used to complain that to run kde, you needed a dozen things running... at least kde acts the way I expect a GUI on a ->UNIX<--derived o/s to work. Gnome, with its k3wl interface (don't start - I just installed the latest fc17 on someone's workstation), and its menus that wave, or the one on ubuntu that my stepson was using for a while, that exploded when they went away....
If you really, really want an o/s with a GUI accepted, make it acceptable by businesses, where non-computerphiles learn to use 'em.
mark
On 01/08/2013 08:25 AM Paul Bijnens wrote:
On 2013-01-06 23:18, fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
[...]
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
in which I note it is now up to "149m".
I had that problem also a few years back (CentOS 5.1, 5.2 or so). When Googling for it, I had found several bug reports about it. While some of those bug reports had some fixes in a "future" version mentioned, other bugreports mentioned that the problem disappeared all by itself.
And indeed, for me too, some upgrades later, the problem disappeared for me too.
Then I fell over:
https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories https://live.gnome.org/MemoryReduction
which seems to imply that the shared libraries of all stuff used by Gnome gets measured in one of the gnome programs, frequently the clock-applet apparently.
That implies that this problem is a red herring. I just means that during the lifetime of Gnome, there were lots of shared libraries loaded, and that memory shows up for 1 applet only.
And, yes indeed, looking carefully I notice that now the black sheep getting all the blame is the wnck-applet for me currently, instead of the clock-applet. It's using 342m memory now (68 days uptime, without logout of gnome).
And yes, googling for "wnck-applet memory" instead of "clock-applet memory" brings up a very similar list of bug reports, also telling sometimes it the problem disappeared all by itself.
To find out which libraries all get counted for the clock-applet, run "pmap -x PID-of-clock-applet" on regular times, and see where the increase in memory is coming from.
Paul,
Excellent! Thanks for unraveling the mystery.
On Wed, Jan 09, 2013 at 04:31:55AM -0500, ken wrote:
On 01/08/2013 08:25 AM Paul Bijnens wrote:
My thanks to Ken, Paul, and all the others who have replied to this thread. I haven't had time to dig into it over the last couple of days, but once I have worked thru all your suggestions I'll try to remember to post an update here.
thanks again!
Fred
On 2013-01-06 23:18, fred smith wrote:
On Sun, Jan 06, 2013 at 02:43:09PM -0500, ken wrote:
On 01/06/2013 09:55 AM fred smith wrote:
On Sun, Jan 06, 2013 at 06:33:07AM -0500, ken wrote:
Fred,
Also running an up-to-date 5.8 but with just 2G of RAM, clock-applet consumes the following:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4133 me 15 0 29568 3748 2944 S 0.0 0.2 190:51.33 clock-applet
My uptime at the moment is coming on 68 days. Over time the %CPU field may flicker up to 0.3 or even 0.7, but the RES column and others are steady at the numbers you see. I should add that all Preferences which we'd expect to consume more resources (e.g., display seconds, 12-hour time) are on.
[...]
here's what top reports today (clock-applet has not been restarted since the event mentioned in my original posting):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
in which I note it is now up to "149m".
I had that problem also a few years back (CentOS 5.1, 5.2 or so). When Googling for it, I had found several bug reports about it. While some of those bug reports had some fixes in a "future" version mentioned, other bugreports mentioned that the problem disappeared all by itself.
And indeed, for me too, some upgrades later, the problem disappeared for me too.
Then I fell over:
https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories https://live.gnome.org/MemoryReduction
which seems to imply that the shared libraries of all stuff used by Gnome gets measured in one of the gnome programs, frequently the clock-applet apparently.
That implies that this problem is a red herring. I just means that during the lifetime of Gnome, there were lots of shared libraries loaded, and that memory shows up for 1 applet only.
And, yes indeed, looking carefully I notice that now the black sheep getting all the blame is the wnck-applet for me currently, instead of the clock-applet. It's using 342m memory now (68 days uptime, without logout of gnome).
And yes, googling for "wnck-applet memory" instead of "clock-applet memory" brings up a very similar list of bug reports, also telling sometimes it the problem disappeared all by itself.
To find out which libraries all get counted for the clock-applet, run "pmap -x PID-of-clock-applet" on regular times, and see where the increase in memory is coming from.
Paul,
Excellent! Thanks for unraveling the mystery. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I'm still not really out of the problem either:
On 2013-01-09 14:21, fred smith wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
263m VIRT: We understand that virtual memory is sum of all, including the read only/executable parts of lots of shared libraries which are not using many resources in fact because they are backed by the real files.
149m RES: The parts that are really in use by "this" program, but including the parts shared by many others of the Gnome package that are running. (I put "this" between quotes, because someone seemed to believe that top or ps or some other program adds memory sizes in in "unfair" way to some processes only, while they should have been distributed over many. Actually I can't find any reason, or explanation of that.)
10m SHR: of those 149m that are in use, 10m is the shared portion.
That leaves 139m allocated exclusively by the clock-applet. Incredibly large yes.
What is that clock-applet doing with 139m? Or is that just because you do have lots of RAM, and in fact, lots of those pages could be swapped out (= for executables like shared libraries, just be removed; they can be swapped in from the file itself), but never had to be swapped out/deleted, because the OS still had unused pages.
I have rebooted my workstation (due to postponed kernel upgrade) yesterday. I have now:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5908 paulb 15 0 283m 13m 9496 S 0.0 0.3 0:25.29 wnck-applet 5950 paulb 15 0 268m 10m 8968 S 0.0 0.3 0:54.00 clock-applet
and I can't find any process that is taking large amounts of memory. Firefox & Thunderbird are using considerable amounts but not more than usual. I did not run any real large program yet (swap use is 0 now), and did not do heavy memory using programs except ff & tb. So why is my RES on 10m now? Probably because the clock-applet did not even touch more of the shared libraries (totaling 268m possibly being touched).
As I said, the problem of the large clock-applet magically disappeared for me somewhere between 5.1 and 5.5 or so. I remember fiddling with the seconds indicator, changing every option to default, monitoring the mem over several weeks, seeing it increasing, but seeing no trend/reason/cause. Gave up on searching intensly. And then some time later noticed the problem disappeared. Yesterday I thought wcnk-applet had the enormous amount of RAM, but I think I was looking at the VIRT size only then. VIRT is a useless indicator here.
Inspecting /proc/PID/smaps of such a large process may reveal something?
(Nostalgia: 1m private data for my running clock-applet still seems large to me, remembering to program on a mainframe with a total memory of 12 Mbyte, supporting hundreds of users. I remember it was upgraded to 16 Mbyte, the maximum amount. That was larger than one of its hard disks of 6 or 10 Mbyte, the size of a washing machine.)
On Wed, Jan 09, 2013 at 04:05:26PM +0100, Paul Bijnens wrote:
I'm still not really out of the problem either:
On 2013-01-09 14:21, fred smith wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
263m VIRT: We understand that virtual memory is sum of all, including the read only/executable parts of lots of shared libraries which are not using many resources in fact because they are backed by the real files.
149m RES: The parts that are really in use by "this" program, but including the parts shared by many others of the Gnome package that are running. (I put "this" between quotes, because someone seemed to believe that top or ps or some other program adds memory sizes in in "unfair" way to some processes only, while they should have been distributed over many. Actually I can't find any reason, or explanation of that.)
10m SHR: of those 149m that are in use, 10m is the shared portion.
That leaves 139m allocated exclusively by the clock-applet. Incredibly large yes.
What is that clock-applet doing with 139m?
I find that to be a really good question. When I first posted, the system had been up for (from my memory) something like 29 days, and the RES column for clock_applet was some number well above a gigabyte. I can imagine that those who say it's just being reported wrong may be right, but if so I don't see why that number would continue to grow. in fact it's also a fact that the amount of swap in use had grown above two gigs, which is definitely NOT the norm on this system. So I still think it's being leaked, _somewhere_.
Or is that just because you do have lots of RAM, and in fact, lots of those pages could be swapped out (= for executables like shared libraries, just be removed; they can be swapped in from the file itself), but never had to be swapped out/deleted, because the OS still had unused pages.
I have rebooted my workstation (due to postponed kernel upgrade) yesterday. I have now:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5908 paulb 15 0 283m 13m 9496 S 0.0 0.3 0:25.29 wnck-applet 5950 paulb 15 0 268m 10m 8968 S 0.0 0.3 0:54.00 clock-applet
and I can't find any process that is taking large amounts of memory. Firefox & Thunderbird are using considerable amounts but not more than usual. I did not run any real large program yet (swap use is 0 now), and did not do heavy memory using programs except ff & tb. So why is my RES on 10m now? Probably because the clock-applet did not even touch more of the shared libraries (totaling 268m possibly being touched).
As I said, the problem of the large clock-applet magically disappeared for me somewhere between 5.1 and 5.5 or so. I remember fiddling with the seconds indicator, changing every option to default, monitoring the mem over several weeks, seeing it increasing, but seeing no trend/reason/cause. Gave up on searching intensly. And then some time later noticed the problem disappeared. Yesterday I thought wcnk-applet had the enormous amount of RAM, but I think I was looking at the VIRT size only then. VIRT is a useless indicator here.
Inspecting /proc/PID/smaps of such a large process may reveal something?
well, there's a LOT of stuff dumped when one cats the file. but I have no adequate expertise to figure out what it all means.
On 2013-01-09 16:50, fred smith wrote:
On Wed, Jan 09, 2013 at 04:05:26PM +0100, Paul Bijnens wrote:
Inspecting /proc/PID/smaps of such a large process may reveal something?
well, there's a LOT of stuff dumped when one cats the file. but I have no adequate expertise to figure out what it all means.
What I know about it...
Here are some lines from my running system (first 3 blocks only):
00400000-00414000 r-xp 00000000 fd:00 190374 /usr/libexec/clock-applet Size: 80 kB Rss: 72 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 72 kB Private_Dirty: 0 kB Swap: 0 kB Pss: 72 kB 00614000-0061b000 rw-p 00014000 fd:00 190374 /usr/libexec/clock-applet Size: 28 kB Rss: 16 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 12 kB Private_Dirty: 4 kB Swap: 0 kB Pss: 16 kB 14c9e000-14ea3000 rw-p 14c9e000 00:00 0 [heap] Size: 2068 kB Rss: 2064 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 2064 kB Swap: 0 kB Pss: 2064 kB
That shows 3 memory blocks.
The first two blocks are from the program file itself "/usr/libexec/clock-applet".
The first block of that is not writable ("r-xp"). That are the executable instructions. The second one is writable ("rw-p"). Those are the writable data (variable etc.).
We see several sizes. We see the total size, and the RSS size (=what is using memory now). The RSS is again split up in different categories below it. (Shared/Private Clean/dirty).
The first block is the code, and thus non writable, and thus pages here can be deleted from memory at all times and can be paged back in from the file itself. They should always have 0 dirty pages. The second block is writable, having a mix of clean and dirty pages. These dirty pages must always be kept in memory. Dirty pages can also be shared with other processes, e.g. shmem segments.
Next we see the heap (memory from malloc etc). And as expected, all private and dirty here.
When a page is shared between many processes, this is reflected in the PSS value (proportional set size): 64 kB RSS, all shared between 4 processes, will show 16 kB PSS.
Example: 2aaaad317000-2aaaad346000 r-xp 00000000 fd:00 189693 /usr/lib64/libgsf-1.so.114.0.1 Size: 188 kB Rss: 56 kB Shared_Clean: 48 kB Shared_Dirty: 0 kB Private_Clean: 8 kB Private_Dirty: 0 kB Swap: 0 kB Pss: 21 kB
# lsof /usr/lib64/libgsf-1.so.114.0.1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME gnome-pan 5826 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1 stickynot 5932 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1 clock-app 5950 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1 nautilus 23427 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1
Apparently not all 56kB is shared with all these 4 processes, but proprotionally the clock is using 21 kB of that.
The ps and top show the sum of several of those values: VIRT: sum of Size RSS : sum of Rss SHR : sum of Shared_* (aproximately at least: When I do my additions, I get in the neighbourhood, but not exact. I do not know why...)
So to debug our problem, we should find some part(s) there and see where the memory is going to. Maybe there is 1 large part? (e.g. some enormous font file -- unicode font -- that somehow all is marked as dirty) Or many smaller parts (heap -> mostly malloc and friends, and thus suspecting a memory leak there).
On Wed, Jan 09, 2013 at 07:07:15PM +0100, Paul Bijnens wrote:
On 2013-01-09 16:50, fred smith wrote:
On Wed, Jan 09, 2013 at 04:05:26PM +0100, Paul Bijnens wrote:
Inspecting /proc/PID/smaps of such a large process may reveal something?
well, there's a LOT of stuff dumped when one cats the file. but I have no adequate expertise to figure out what it all means.
What I know about it...
Here are some lines from my running system (first 3 blocks only):
00400000-00414000 r-xp 00000000 fd:00 190374 /usr/libexec/clock-applet Size: 80 kB Rss: 72 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 72 kB Private_Dirty: 0 kB Swap: 0 kB Pss: 72 kB 00614000-0061b000 rw-p 00014000 fd:00 190374 /usr/libexec/clock-applet Size: 28 kB Rss: 16 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 12 kB Private_Dirty: 4 kB Swap: 0 kB Pss: 16 kB 14c9e000-14ea3000 rw-p 14c9e000 00:00 0 [heap] Size: 2068 kB Rss: 2064 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 2064 kB Swap: 0 kB Pss: 2064 kB
That shows 3 memory blocks.
here's the (I think) equivalent blocks from my system:
08048000-0805b000 r-xp 00000000 fd:00 4685290 /usr/libexec/clock-applet Size: 76 kB Rss: 68 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 68 kB Private_Dirty: 0 kB Swap: 0 kB Pss: 68 kB 0805b000-0805c000 rw-p 00012000 fd:00 4685290 /usr/libexec/clock-applet Size: 4 kB Rss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Swap: 0 kB Pss: 4 kB 09681000-1072a000 rw-p 09681000 00:00 0 [heap] Size: 115364 kB Rss: 115288 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 115288 kB Swap: 0 kB Pss: 115288 kB
I note that the heap shows 115288, or around 115 megabytes. Do I understand what you said (below) to imply that in this example, clock-applet is directly responsible for all 115288 KB, since Pss and RSS are the same?
top currently shows:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA nFLT nDRT COMMAND 23350 fredex 16 0 240m 124m 9.9m S 0.7 3.2 1:25.71 115m 76 125m 1 0 clock-applet
note that I've enabled some other memory-related columns here. I think it may be interesting to see that the swap amount appears to be the same as (or at least close) the size/rss/private-dirty/pss entries from the [heap] section shown above.
the other sections with large-ish values for 'size' are all in the 2x,xxx range or smaller-- mostly considerably smaller.
Another thing that might be interesting to try is to kill the clock-applet and leave it dead for a while, and see if top starts reporting that memory to some other app(let).
The first two blocks are from the program file itself "/usr/libexec/clock-applet".
The first block of that is not writable ("r-xp"). That are the executable instructions. The second one is writable ("rw-p"). Those are the writable data (variable etc.).
We see several sizes. We see the total size, and the RSS size (=what is using memory now). The RSS is again split up in different categories below it. (Shared/Private Clean/dirty).
The first block is the code, and thus non writable, and thus pages here can be deleted from memory at all times and can be paged back in from the file itself. They should always have 0 dirty pages. The second block is writable, having a mix of clean and dirty pages. These dirty pages must always be kept in memory. Dirty pages can also be shared with other processes, e.g. shmem segments.
Next we see the heap (memory from malloc etc). And as expected, all private and dirty here.
When a page is shared between many processes, this is reflected in the PSS value (proportional set size): 64 kB RSS, all shared between 4 processes, will show 16 kB PSS.
Example: 2aaaad317000-2aaaad346000 r-xp 00000000 fd:00 189693 /usr/lib64/libgsf-1.so.114.0.1 Size: 188 kB Rss: 56 kB Shared_Clean: 48 kB Shared_Dirty: 0 kB Private_Clean: 8 kB Private_Dirty: 0 kB Swap: 0 kB Pss: 21 kB
# lsof /usr/lib64/libgsf-1.so.114.0.1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME gnome-pan 5826 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1 stickynot 5932 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1 clock-app 5950 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1 nautilus 23427 paulb mem REG 253,0 210712 189693 /usr/lib64/libgsf-1.so.114.0.1
Apparently not all 56kB is shared with all these 4 processes, but proprotionally the clock is using 21 kB of that.
The ps and top show the sum of several of those values: VIRT: sum of Size RSS : sum of Rss SHR : sum of Shared_* (aproximately at least: When I do my additions, I get in the neighbourhood, but not exact. I do not know why...)
So to debug our problem, we should find some part(s) there and see where the memory is going to. Maybe there is 1 large part? (e.g. some enormous font file -- unicode font -- that somehow all is marked as dirty) Or many smaller parts (heap -> mostly malloc and friends, and thus suspecting a memory leak there).
On 2013-01-09 19:41, fred smith wrote:
here's the (I think) equivalent blocks from my system:
08048000-0805b000 r-xp 00000000 fd:00 4685290 /usr/libexec/clock-applet Size: 76 kB Rss: 68 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 68 kB Private_Dirty: 0 kB Swap: 0 kB Pss: 68 kB 0805b000-0805c000 rw-p 00012000 fd:00 4685290 /usr/libexec/clock-applet Size: 4 kB Rss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Swap: 0 kB Pss: 4 kB 09681000-1072a000 rw-p 09681000 00:00 0 [heap] Size: 115364 kB Rss: 115288 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 115288 kB Swap: 0 kB Pss: 115288 kB
I note that the heap shows 115288, or around 115 megabytes. Do I understand what you said (below) to imply that in this example, clock-applet is directly responsible for all 115288 KB, since Pss and RSS are the same?
Yes indeed. The heap is using an enourmous amount of memory there. And it is all private data used by this program all by itself.
The heap space is mostly used by malloc and related programs. So that points to some memory leak there.
What else could use the heap besides malloc? I'm not sure here.
A clock applet is of course very busy with time handling, and I guess, does use some feature to get awakened now and then to update what it is supposed to keep track of. Alarm interrrupts, sleeps etc. And malloc inside an interrupt handler could have such an effect. You could try to see if there is a correlation of that heap space size with time. Is it linear? Or does it increase more in certain situations (heavy CPU usage, heavy disk usage, when you have a VM-client running on the system at the same time,...)?
I've not looked into the source code of the clock applet. Neither do I have an explanation why the problem disappears some time later, as many people have observed, and as happend on my system too. Was that due to an upgrade of some package? Or due to a different sequence of events that happen to free after the malloc in the right order?.
I guess you are sure you're running all programs updated to the current 5.8 version.
top currently shows:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA nFLT nDRT COMMAND 23350 fredex 16 0 240m 124m 9.9m S 0.7 3.2 1:25.71 115m 76 125m 1 0 clock-applet
note that I've enabled some other memory-related columns here. I think it may be interesting to see that the swap amount appears to be the same as (or at least close) the size/rss/private-dirty/pss entries from the [heap] section shown above.
In modern Linux, I understand, the notion of swap, as we learned it from the early days is heavily changed. I'm not sure anymore if swap here means: paged out to swap space, or reserved in swap space, or something else. The DATA is indeed 125m, and that is indeed the heap above.
Another thing that might be interesting to try is to kill the clock-applet and leave it dead for a while, and see if top starts reporting that memory to some other app(let).
That would then verify the claim that the leak is not real (the above shows the contrary, I think), and gnome programs interact with each other in much more deeper ways than you would expect.
On Thu, Jan 10, 2013 at 2:13 AM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
That would then verify the claim that the leak is not real (the above shows the contrary, I think), and gnome programs interact with each other in much more deeper ways than you would expect.
I sort-of remember once having evolution hooked to an exchange server and the clock applet seemed to be aware of all of my exchange calendar events but it was really too buggy to use back then. Do you have any calendar settings that any gnome program knows about?
On Thu, Jan 10, 2013 at 08:10:43AM -0600, Les Mikesell wrote:
On Thu, Jan 10, 2013 at 2:13 AM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
That would then verify the claim that the leak is not real (the above shows the contrary, I think), and gnome programs interact with each other in much more deeper ways than you would expect.
I sort-of remember once having evolution hooked to an exchange server and the clock applet seemed to be aware of all of my exchange calendar events but it was really too buggy to use back then. Do you have any calendar settings that any gnome program knows about?
not sure what those settings might be, to which you refer. there aren't very many settings available in the clock applet.
also, I don't use/like evolution.
On 2013-01-10 15:10, Les Mikesell wrote:
On Thu, Jan 10, 2013 at 2:13 AM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
That would then verify the claim that the leak is not real (the above shows the contrary, I think), and gnome programs interact with each other in much more deeper ways than you would expect.
I sort-of remember once having evolution hooked to an exchange server and the clock applet seemed to be aware of all of my exchange calendar events but it was really too buggy to use back then. Do you have any calendar settings that any gnome program knows about?
I did not have items in some calendar. I do not run Evolution, it is not even installed anymore. Maybe I had it installed at some time, but just "yum erase"-d it at some point. I've never even started it once on this workstation.
I hate calendars (with deadlines and due dates just wooshing by).
I do have the Lightning plugin in Thunderbird, just to be able to read nice formatted invites to meetings etc. And that thing marks items in my calendar.
And I do remember having difficulties to install a working version of Lightning due to 32/64 bit problems at that time.
I think had to install a 32 bit version of TB on my 64bit workstation to be able to use it then. But when TB 10 replaced the TB 2 (or was that TB 3?), I just trow out all of it, and installed the standard CentOS TB 10. Even the Lightning plugin works now too.
Maybe that was around the time when I noticed my memory problem with the clock-applet disappeared? I not sure anymore.
I just mention this because I noticed that Fred also was experimenting with Firefox 18. And until a real cause of the problem is found, everything is suspect.
On Thu, Jan 10, 2013 at 12:03 PM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
I do have the Lightning plugin in Thunderbird, just to be able to read nice formatted invites to meetings etc. And that thing marks items in my calendar.
If you have notifications set, does the clock-applet pop them up?
And I do remember having difficulties to install a working version of Lightning due to 32/64 bit problems at that time.
I think had to install a 32 bit version of TB on my 64bit workstation to be able to use it then. But when TB 10 replaced the TB 2 (or was that TB 3?), I just trow out all of it, and installed the standard CentOS TB 10. Even the Lightning plugin works now too.
Maybe that was around the time when I noticed my memory problem with the clock-applet disappeared? I not sure anymore.
I just mention this because I noticed that Fred also was experimenting with Firefox 18. And until a real cause of the problem is found, everything is suspect.
I don't know anything about the mechanisms involved, but the clock-applet seemed to be aware of other stuff - and probably consumes memory in the process. The 6.x version also has a weather-checker in there.
On 2013-01-10 19:13, Les Mikesell wrote:
On Thu, Jan 10, 2013 at 12:03 PM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
I do have the Lightning plugin in Thunderbird, just to be able to read nice formatted invites to meetings etc. And that thing marks items in my calendar.
If you have notifications set, does the clock-applet pop them up?
No popops by the calendar (but I do not have the memory leak problem anymore either). Maybe I did had some experiments in that time when testing Lightning then.
I don't know anything about the mechanisms involved, but the clock-applet seemed to be aware of other stuff - and probably consumes memory in the process. The 6.x version also has a weather-checker in there.
Wow, now, that you say it... Now I have a remote temperature sensor in CentOS 6. My smartphone has one too :-)
On Wed, Jan 9, 2013 at 9:05 AM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
On 2013-01-09 14:21, fred smith wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
149m RES: The parts that are really in use by "this" program, but including the parts shared by many others of the Gnome package that are running. (I put "this" between quotes, because someone seemed to believe that top or ps or some other program adds memory sizes in in "unfair" way to some processes only, while they should have been distributed over many. Actually I can't find any reason, or explanation of that.)
10m SHR: of those 149m that are in use, 10m is the shared portion.
That leaves 139m allocated exclusively by the clock-applet. Incredibly large yes.
I think the scenario is that you have large shared libraries that other programs _could_ ahare but at the moment you don't have other running applications that actually are sharing the code..
(Nostalgia: 1m private data for my running clock-applet still seems large to me, remembering to program on a mainframe with a total memory of 12 Mbyte, supporting hundreds of users. I remember it was upgraded to 16 Mbyte, the maximum amount. That was larger than one of its hard disks of 6 or 10 Mbyte, the size of a washing machine.)
Think in terms of dollars instead of Mbytes here and it will make more sense that nobody cares anymore.
Les Mikesell wrote:
On Wed, Jan 9, 2013 at 9:05 AM, Paul Bijnens Paul.Bijnens@xplanation.com wrote:
On 2013-01-09 14:21, fred smith wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND11159 fredex 16 0 263m 149m 10m S 0.3 3.8 1:36.87 clock-applet
149m RES: The parts that are really in use by "this" program, but including the parts shared by many others of the Gnome package that are
running.
(I put "this" between quotes, because someone seemed to believe that top or ps or some other program adds memory sizes in in "unfair" way to some processes only, while they should have been distributed over many. Actually I can't find any reason, or explanation of that.)
10m SHR: of those 149m that are in use, 10m is the shared portion.
That leaves 139m allocated exclusively by the clock-applet. Incredibly large yes.
<snip>
(Nostalgia: 1m private data for my running clock-applet still seems large to me, remembering to program on a mainframe with a total memory of 12 Mbyte, supporting hundreds of users. I remember it was upgraded to 16 Mbyte, the maximum amount. That was larger than one of its hard disks of 6 or 10 Mbyte, the size of a washing machine.)
Yup. Of course, the punch cards did take up a lot of space.... I remember carrying boxes in college.
It still bothers me to align the new large disks on 1M or 2M boundaries, loosing that much disk space; I do remember wanting to kill for one of the 5M h/d's that had just come out for PCs....
Think in terms of dollars instead of Mbytes here and it will make more sense that nobody cares anymore.
You ain't got no sense o' history or wonder, Les.
mark
On Wed, Jan 9, 2013 at 10:16 AM, m.roth@5-cent.us wrote:
Think in terms of dollars instead of Mbytes here and it will make more sense that nobody cares anymore.
You ain't got no sense o' history or wonder, Les.
Oh, the days of wooden computers and iron programmers... I've been there, done that, and didn't like it much. Per-program memory bloat doesn't bother me nearly as much as the idea of having dozens of different shared libraries that all provide the same functionality but aren't compatible and thus aren't actually shared (and worse, all have different bugs to deal with). Or that it is so difficult and unusual to run multiple X desktops from the same host where all the code space would automatically be shared by all instances (in the unlikely event that they ran the same desktop flavor...). Or that a 'modern' system will need support for a dozen or more different programming languages and all their associated libraries none of which will share disk or RAM.. Or that even though the slowest computer operation for decades has been moving a disk head, operating systems are still to dumb to move frequently accessed things to nearby locations.
Les Mikesell wrote:
On Wed, Jan 9, 2013 at 10:16 AM, m.roth@5-cent.us wrote:
Think in terms of dollars instead of Mbytes here and it will make more sense that nobody cares anymore.
You ain't got no sense o' history or wonder, Les.
Oh, the days of wooden computers and iron programmers... I've been
*chuckle*
there, done that, and didn't like it much. Per-program memory bloat doesn't bother me nearly as much as the idea of having dozens of different shared libraries that all provide the same functionality but aren't compatible and thus aren't actually shared (and worse, all have
Yeah. And new languages every couple of years, now, that are the Greatest Thing Since Sliced Bread, and solve *all* your problems in creating a web page that you could have done in straight HTML.... <snip> mark
On 01/08/2013 05:25 AM, Paul Bijnens wrote:
Then I fell over:
https://blogs.oracle.com/bnitz/entry/thanks_for_the_memories https://live.gnome.org/MemoryReduction
which seems to imply that the shared libraries of all stuff used by Gnome gets measured in one of the gnome programs, frequently the clock-applet apparently.
That implies that this problem is a red herring. I just means that during the lifetime of Gnome, there were lots of shared libraries loaded, and that memory shows up for 1 applet only.
It doesn't imply that at all. Shared memory use is reported as RES for all of the applications that load the shared libraries. It's not just for one of them.
Since shared libraries are also loaded when the application starts, RES will normally start out large for applications so affected. When RES grows over time, without bound, it's probably an actual memory leak.
To debug the clock applet, first you'd have to kill it, and then start it under valgrind: valgrind -v --log-file=/var/tmp/clock-applet.log clock-applet
Let it run until you believe it has leaked memory, then kill it again. The log file should have details about any detected memory leaks.
-
Akemi Yagi -
fred smith -
Gordon Messmer -
John Doe -
ken -
Leon Fauster -
Les Mikesell -
m.roth＠5-cent.us -
Nicolas Thierry-Mieg -
Paul Bijnens -
Rob Kampen -
Robert Nichols