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@xxxxxxxxxx
> >>>> http://lists.centos.org/mailman/listinfo/centos
> >>>
> >> _______________________________________________
> >> CentOS mailing list
> >> CentOS@xxxxxxxxxx
> >> http://lists.centos.org/mailman/listinfo/centos
> >
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
--
---- Fred Smith -- fredex@xxxxxxxxxxxxxxxxxxxxxx -----------------------------
But God demonstrates his own love for us in this:
While we were still sinners,
Christ died for us.
------------------------------- Romans 5:8 (niv) ------------------------------
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
