indicator-applet guzzles CPU

[Brian RIstuccia]

On a system up for roughly 6 days, indicator-applet had used over 200 minutes of CPU time. This is a portable system, so it's also wasting battery runtime. Considering the rather limited scope of what indicator-applet does, it should be consuming 2-3 orders of magnitude less CPU time.

4911 brianr 20 0 31740 13m 5804 R 91 0.7 208:45.69
   indicator-apple

(To put things in perspective, the X server on this same machine has racked up only 332 minutes of CPU time).

[Brian RIstuccia (brianr-launchpad-net)]

Architecture: lpia
DistroRelease: Ubuntu 9.04
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-11-lpia i686
UserGroups: adm admin cdrom dialout dip fuse lpadmin plugdev sambashare video

[Ted Gould (ted)]

On Wed, 2009-04-22 at 17:35 +0000, Brian RIstuccia wrote:
> 4911 brianr 20 0 31740 13m 5804 R 91 0.7 208:45.69
> indicator-apple

Hmm, that's really odd. To put things in perspective my machine has
been up for about 6 hours (I rebooted last night) and the indicator
applet has used about 14 seconds of CPU time. Which is about half as
much as the screensaver which only blanks the screen! ;)

Is there anything you know to be odd about your system. The only
'hidden' CPU usage in the indicator applet should use a little bit of
CPU anytime someone comes on or of DBus, but for most folks that's
pretty infrequent. Do you have a lot of apps starting and stopping?

Also, could you compare to the CPU usage of
running /usr/lib/indicator-applet/listen-and-print at the same time?
That would show if the issue is on the GTK side or the libindicate side.

  status incomplete
  priority medium

[Brian RIstuccia (brianr-launchpad-net)]

Since I killed and restarted it about an hour ago, it's only racked up about 5 seconds of CPU time.

There's no rapidly scrolling messages in /usr/lib/indicator-applet/listen-and-print, just the usual notifications about new mail, IM, etc.

[Mark Shuttleworth (sabdfl)]

For me, top shows:

 20 0 726m 431m 25m S 21.5 363:42.85 firefox
 20 0 587m 379m 19m S 19.0 134:53.92 thunderbird-bin
 20 0 361m 78m 9432 S 3.9 106:10.89 Xorg
 20 0 160m 14m 10m S 0.7 97:36.08 pulseaudio
 20 0 151m 75m 4036 S 3.8 35:46.30 evolution-data-
 20 0 214m 61m 10m S 3.1 15:02.36 pidgin
 20 0 43252 11m 5700 S 0.6 9:12.01 indicator-apple
 20 0 55424 19m 4640 S 1.0 6:25.02 connman-applet
 20 0 42092 9864 6128 S 0.5 5:41.08 metacity
 20 0 3368 1456 632 S 0.1 2:01.29 dbus-daemon
 20 0 3004 1300 804 S 0.1 1:38.10 dbus-daemon
 20 0 7828 4452 1968 S 0.2 1:25.45 gconfd-2
 20 0 62228 11m 5228 S 0.6 1:13.89 gnome-do
 20 0 115m 26m 8764 S 1.3 1:13.59 gnome-panel
 20 0 28000 5224 3884 S 0.3 1:11.32 python
 20 0 17440 5292 3852 S 0.3 0:50.89 gnome-screensav

It does seem too high, Ted. Can we make a 9.10 goal a review of that?

Mark

[Ted Gould (ted)]

On Thu, 2009-04-23 at 05:38 +0000, Mark Shuttleworth wrote:
> It does seem too high, Ted. Can we make a 9.10 goal a review of that?

Sure, I'm running it under callgrind now. I'm guessing that we're
getting killed by getting woken up when people come off and on DBus,
which we're doing to protect against applications crashing... but, data
is better that suspicion :)

[jonaz__ (jonaz-86)]

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 5166 jonaz 20 0 69396 21m 4956 S 8 0.6 349:02.65 indicator-apple

From top on my ubuntu 9.04

indicator-applet uses about 10-20% cpu all the time. Sometimes even more. It comes after a few days of uptime. current: up 7 days, 3:39

Please let me know if i can provide any more helpful information!

[pLr (miscpc)]

94 percent cpu here, it was slowing down my entire box.
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14219 username 20 0 380m 76m 4328 R 94 3.8 3924:35 indicator-applet

I have lots of contacts on pidgin (msn+facebook plugin) going offline/online all day&night

Running jaunty 9.04 2.6.28-11
2 gigs of ram + 3ghz dual-core cpu

[Ka-Hing Cheung (kahing)]

 3200 root 20 0 653m 214m 13m S 17 5.9 996:42.46 996:42 Xorg
 3805 khc 20 0 305m 31m 6308 S 24 0.9 937:09.89 937:09 indicator-ap

indicator-applet is using about as much CPU time as Xorg, and regularly consumes 100% CPU for couple seconds.

ran /usr/lib/indicator-applet/listen-and-print as suggested, and it produces no additional output and consumes no CPU when indicator-applet is using 100% CPU. Buddy signon/off notification is disabled in pidgin-libnotify.

31MB RES also seems to be a bit heavy for a process that just sends message to notify-osd

[Ka-Hing Cheung (kahing)]

ran dbus-monitor too, and there aren't noticeably more dbus messages going on when indicator-applet consumes 100% cpu

[Ka-Hing Cheung (kahing)]

looked at it over several minutes, seems like it uses 100% cpu for about 20 seconds every minute starting on the same second, does it have some timer that runs every minute?

[Ka-Hing Cheung (kahing)]

since I can't find the -dbg package for it, I can't see a nice callgraph from sysprof...

Looked at the source for indicator-applet and indicator-message, found one place where there's a timeout in src/im-menu-item.c in indicator-message and that timeout happens to be 60 seconds.

I noticed that there's a time_update_min which is being checked but never set, maybe it should be?

        if (priv->time_update_min == 0) {
                g_timeout_add_seconds(60, time_update_cb, self);
        }

time_update_cb returns TRUE, so the timer is never automatically removed, which means you will have lots and lots of timer eventually if you have it running for a long time.

[Ka-Hing Cheung (kahing)]

sure enough, killing it and letting it restart and this behavior stopped (not leaked enough timers yet for this to be noticeable)

[Ka-Hing Cheung (kahing)]

someone should look into this soon instead of waiting until 9.10, 20 seconds every minute is 1/3, it doesn't bother me that much because I have enough cores but the majority of people are probably on slower hardware, especially people on netbooks/laptops who suspend them all the time instead of reboot

[Ka-Hing Cheung (kahing)]

pretty sure that's it, I changed the timeout to 1 second, and IM'ed myself about 100 times, and I can see indicator-applet's CPU time go up every second even after the notifications are gone. Changed it to priv->time_update_min = g_timeout_add_seconds() and that behavior goes away.

[Ted Gould (ted)]

I packaged this fix into indicator-message_0.1.6-0ubuntu2~ppa2 in my
bugfix PPA:

  https://launchpad.net/~ted/+archive/bugfix

If everyone could update to that package and see if it fixes their
problem that'd be helpful. Thanks Ka-Hing Cheung for finding the bug!

  --Ted

[Ka-Hing Cheung (kahing)]

after running my own patched version in a while I am not sure if it fixes everything. indicator-applet's CPU usage still jumps up every minute. Total CPU time is considerably less than before the change though (after factoring in uptime), but that may or may not be affected by the number of notifications I received.

[Ryan (ryan-delaney)]

After 13 days of uptime, indicator-applet has used ... wait for it... 1216 minutes of CPU time.

You read that correctly. In 13 days, indicator-applet has used over 20 _hours_ of CPU time.

I'll try applying Ted Gould's patch and report back.

[Ryan (ryan-delaney)]

All better since I installed Ted Gould's bugfix PPA. Thanks.

[Brendan Braybrook (brendan-ming)]

ted gould's ppa build solved my problems as well.

[Adam Buchbinder (adam-buchbinder)]

I'm not sure why this bug was showing as incomplete, but I'm marking it confirmed, as a number of people have been able to reproduce it and confirm the fix.

[Brian J. Cohen (brianjcohen)]

I can confirm this bug, on Ubuntu 9.04. I have not yet tried Ted's patch.

[ENOTTY (enotty)]

Confirming the bug. indicator-applet used 390 minutes CPU time in 5 days uptime. X and pulseaudio used ~200. Applied the fix, and after 2 days, it has used 22 minutes CPU time. Still seems a tad high at 11 minutes per day, but its better now.

Will this fix be pushed to general Jaunty users?

[Ted Gould (ted)]

On Tue, 2009-09-01 at 17:07 +0000, ARcanUSNUMquam wrote:
> Will this fix be pushed to general Jaunty users?

I think that this should be able to get an SRU, though no one has
applied for one on this. I don't have the time currently to get it
through the process, but the instructions are here:

 https://wiki.ubuntu.com/DistributedDevelopment/Requirements/SRU

[Brian J. Cohen (brianjcohen)]

Several days after installing Ted's patch, indicator-applet is still eating a LOT of CPU, just about the same as before.

[William King (quentusrex)]

Same issue here. I run pidgin and x-chat with many buddies and with many irc channels. I get about 25% usage... on a quad core it means that it's using an entire core... also dbus-daemon is running with 15%....

[Ben Beasley (ben-musicinmybrain)]

I’ve been experiencing this issue from time to time on one of two systems running 9.04. Ted’s update did not fix this issue on that system, but I have not experienced it since disabling automatic update checking in Synaptic/Update Manager a couple of weeks ago. Perhaps for those still experiencing it, this could be worth a try?

[Ted Gould (ted)]

Could the people on this bug please confirm if they're seeing it on the Karmic release? I am not. Thank you!

[Ryan (ryan-delaney)]

No problems in Karmic amd64

[Robert Collins (lifeless)]

Feedback says fixed.

Please file a new bug if you encounter this again (or if you're really really sure its the same one reopen it).

[Arie Skliarouk (skliarie)]

Just updated from 9.10 to 10.04 (amd64) and immediately saw that indicator-applet uses about 10-20% cpu all the time. Sometimes even more.
# dpkg -l | grep indicator-applet
ii indicator-applet 0.3.6-0ubuntu2 GNOME panel indicator applet
#

[Ka-Hing Cheung (kahing)]

looking at lucid I still don't see -dbg packages. If those are present people who are affected can just install -dbg and run sysprof, and the problem would be a lot more apparent. I suggest whoever's still affected build indicator-applet from source and run sysprof to capture a profile, and/or file bug to get -dbg packages.

[Michael (michaeljt)]

Not sure if this belongs on this ticket, otherwise let me know and I will open a new one. When Indicator Applet fails to access pulseaudio it pushes system CPU usage to use up all spare capacity of one core (most of this is accounted for by top as "system" time). Seen on Lucid and Maverick. To reproduce, change $HOME/.pulse* to be owned by root and kill pulseaudio. To make the problem go away again, rm -r $HOME/.pulse*.

[Ka-Hing Cheung (kahing)]

Not the same bug

[panticz.de (panticz.de)]

Try to uninsatall indicator-me:

sudo apt-get remove -y indicator-me

then logout and login again, after that the problem disappeared for me.

[Derek (bugs-m8y)]

So, investigated remote family member's computer running 11.04 after complaints of slowness, overheating and shutdown.
One of the two accounts had indicator-applet-appmenu taking 100% of CPU seconds after starting, even after being killed.
I had tried comment #34 since they weren't using -me anyway, without success.
lsof revealed a log file in .cache that was filled with complaints about an instance already existing (regrettably I did not note down the precise message).

A panel reset:
gconftool-2 --shutdown
gconftool --recursive-unset /apps/panel
rm -rf ~/.gconf/apps/panel
pkill gnome-panel

Appears to have solved things. Not clear exactly how it was screwed up, however