Moovida (formerly Elisa), a universal and user-friendly media center

100% cpu usage on some systems

Reported by Fabian-elisa on 2008-03-20
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Moovida
High
Unassigned

Bug Description

I'm experiencing CPU usage of almost 100% running the following setup on a 1.2GHz gentoo machine:

 * elisa trunk
 * pigment 0.3.5
 * pigment-python 0.3.3
 * twisted 2.5.0
 * zopeinterface 3.0.1
 * CS nvidia driver version 169.09 (Geforce 5200 PCI)

It's neither a pigment problem (text.py, sphere.py from the examples run fine at 2% cpu usage), nor is it the media scanner scanning for files. Elisa constantly uses up 100% cpu no matter if idling, watching movies, looking at pictures or listening to music. It's 98% for /usr/bin/elisa and 0.5% for gst_metadata_runner.py

Fabian-elisa (fabian-elisa) wrote :

elisa log file

Florian Boucault (fboucault) wrote :

Fabian, is that issue still relevant in Elisa 0.5.1. Can you please try it out? Thanks.

Changed in elisa:
status: New → Incomplete
Changed in elisa:
importance: Undecided → High
luzik (luzik) wrote :

this is still issue on elisa 0.5.17 100% of cpu when elisa is idle

Olivier Tilloy (osomon) wrote :

From the support forums (https://elisa.fluendo.com/forums/viewtopic.php?id=903):

    100 % cpu on one core when idling

    my specs:
    elisa 5.22
    opensuse 11.1
    cv : nvidia 8800 gtx - proprio driver -xinerama on (1440x900 x 2 monitors)
    ram 3 go - non dual channel
    proc amd 5600+ 2x core

    Edit : update to 5.23 elisa version and 180.11.02 opengl3 beta nvidia driver - always the same

Changed in elisa:
milestone: none → 0.5.x
status: Incomplete → Confirmed
Philippe Normand (philn) on 2009-04-30
tags: added: pigment
ch4204 (ch4204) wrote :

cpu at 100 % with elisa 5.37 on ubuntu jaunty => critical
when using new web plugins (games, movies or grooveshark...)

Note:
reading movie .avi or dvd = CPU's behaviour OK

other problems:
*bad integration of new gnome notifications (jaunty)
*triptic "minimize/resize/close" is sometimes present on primary menu (and more times not)
*Backspace do not close elisa but resize it and the top of the window is hide by the taskbar...

comments:
*Good idea the menu "slideshow" on the right top... but why not a such a selection in the primary menu to configure the "slideshow view" for all choices (videos, music...)
*Bad integration of weather plugin - unusefull there where it is (and how configure it ?)
*There is no link to the to reading track when moving inside elisa menu (music video ..)
*Why not a button "Exit"?

By the way.... congratulations for this mediacenter... I understand why ubuntu team support it!
thks.

Olivier Tilloy (osomon) wrote :

@ch4204: thanks for your feedback.
If you want to discuss ideas for improvements, the mailing list (http://lists.fluendo.com/mailman/listinfo/elisa) or our IRC channel (irc://freenode/#elisa) is better suited than a bug report.
For all mentioned problems, could you please file new bug reports?

Olivier Tilloy (osomon) wrote :

Anyone still experiencing similar issues with Moovida 1.0 and the latest pigment?

Changed in elisa:
milestone: 0.5.x → none
status: Confirmed → Incomplete

I still have this 100% load issue running pigment 0.3.11 and moovida 1.0.1.
It is the case for nvidia and intel graphics.

Olivier Tilloy (osomon) on 2009-06-02
Changed in elisa:
status: Incomplete → Confirmed
Krzysztof Adamski (kadamski) wrote :
Download full text (6.5 KiB)

I have similar issue with latest Moovida (from bzr) and latest pigment (from svn). I did some research about that, however, and I'm not sure if it's accually Moovida/Pigment BUG. My setup is:
- Fedora 11
- Moovida 1.0.3 (from git)
- Pigment ?.?.? (from svn)
- Mesa
- Xorg
- intel-driver
- Twisted
- GTK

First of all, I've checked if it's a Pigment bug by running python-pigment examples. They run fine so it's not. Second thing i have done was checking what is Moovida actually doing with strace and I found out that this (running again and again):

15519 poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN}, {fd=8, events=POLLIN}, {fd=14, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=32, events=POLLIN}, {fd=25, events=POLLIN}, {fd=29, events=POLLIN}, {fd=34, events=POLLIN}, {fd=36, events=POLLIN}, {fd=12, events=POLLIN}, {fd=3, events=POLLIN}, {fd=38, events=POLLIN}], 16, 25) = 1 ([{fd=8, revents=POLLIN}])
15519 gettimeofday({1246013664, 941148}, NULL) = 0
15519 read(11, 0x9606d98, 4096) = -1 EAGAIN (Resource temporarily unavailable)
15519 gettimeofday({1246013664, 941223}, NULL) = 0

15519 poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN}, {fd=8, events=POLLIN}, {fd=14, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=32, events=POLLIN}, {fd=25, events=POLLIN}, {fd=29, events=POLLIN}, {fd=34, events=POLLIN}, {fd=36, events=POLLIN}, {fd=12, events=POLLIN}, {fd=3, events=POLLIN}, {fd=38, events=POLLIN}], 16, 25) = 1 ([{fd=8, revents=POLLIN}])
15519 gettimeofday({1246013664, 941401}, NULL) = 0
15519 read(11, 0x9606d98, 4096) = -1 EAGAIN (Resource temporarily unavailable)
15519 gettimeofday({1246013664, 941569}, NULL) = 0

Note couple things:
- it looks like it's a poll loop running all the time consuming 100% CPU
- poll is returning 1 FD ready (fd=8)
- this fd is NEVER READ (?!)
- after this, fd=11 is read and there is next poll immediately (check out gettimeofday values)
- next poll returns immediately with fd=8 since it wasn't read before.. this continues forever and uses all the CPU

So I've done some more research to find what douse FD's are:
$ ls -l /proc/15519/fd/8 /proc/15519/fd/11
razem 0
lrwx------. 1 k k 64 06-26 13:02 11 -> socket:[244343]
lr-x------. 1 k k 64 06-26 13:02 8 -> pipe:[244347]

and from trace file:

15519 execve("/usr/bin/python", ["python", "moovida/elisa-core/bin/moovida", "-c", "moovida.conf"], [/* 50 vars */]) = 0
[...]
15519 socket(PF_FILE, SOCK_STREAM, 0) = 11
15519 connect(11, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, 20) = 0
15519 getpeername(11, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, [20]) = 0
[...]
15519 fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR)
15519 fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0
15519 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
[...]
15519 rt_sigaction(SIGCHLD, {0x2c51a90, [], 0}, {SIG_DFL, [], 0}, 8) = 0
[...]
15519 pipe([8, 9]) = 0
[...]
15519 pipe([16, 17]) = 0
15519 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb8004728) = 15523
1551...

Read more...

Krzysztof Adamski (kadamski) wrote :

Sorry I forgot to write my software versions. So I'm running on Fedora 11 (i386) with:
- Moovida 1.0.3 (from git)
- Pigment ?.?.? (from svn)
- Mesa 7.5
- Xorg server 1.6.1
- intel-driver 2.7.0
- Twisted 8.2.0
- GTK 2.16.2
- pygtk 2.14

Michał Sawicz (saviq) wrote :

I'm experiencing the same thing with openSUSE 11.1 (x86_64) + GNOME 2.26:
- Mesa 7.2
- Xorg server 1.5.2
- nvidia driver 180.51
- Twisted 8.1.0
- GTK 2.16.1
- pygtk 2.12.1

summary: - 100% cpu usage with nvidia-drivers
+ 100% cpu usage on some systems
Olivier Tilloy (osomon) wrote :

Thanks for your very thorough investigations Krzysztof.
I cannot tell where exactly the problem is, but I know that some time ago people at Fluendo suggested that using the GTK2 reactor is useless and that we could save memory usage by getting rid of it. Maybe time to evaluate this solution? Could potentially fix the problem, or at least simplify it by removing one of its components.

Krzysztof Adamski (kadamski) wrote :

I've got some new informations - looks like It's related to the PySignal_SetWakeupFd function from CPython:
http://docs.python.org/dev/c-api/exceptions.html#PySignal_SetWakeupFd. From my understanding, it seams that the bug only exists with Python 2.6 (i didn't test it, however). It is quite clear for me now that this is not Moovida bug and I think the problem is in pygobject/pygtk:
http://bugzilla.gnome.org/show_bug.cgi?id=481569

I'm using:
Python 2.6.9
pygobject 2.16.1
pygtk 2.14.1

I'm going to try never versions of pygtk/pygobject to see if anything changes.

Krzysztof Adamski (kadamski) wrote :

Here's related Twisted bug report:
http://twistedmatrix.com/trac/ticket/3096

Krzysztof Adamski (kadamski) wrote :

Conclusion is that this is pygtk bug. They have a patch in their bug trucking system but since it is not included in the mainstream (it has one corner case). Twisted does not want to create any workaround so it seams there are 2 possibilities:
- get rid of using gtk2reactor, as Olivier said
- fix mainstream pygtk

Note that this issue will be more and more common for all users as they switch to python 2.6.

Olivier Tilloy (osomon) wrote :

According to Guillaume, the glib2 reactor (which is the one we use, sorry for the confusion) _is_ needed, so getting rid of it is not an option. That leaves us with fixing pygtk.

Philippe Normand (philn) wrote :

Hmm some precisions to add. pygtk & pygobject are both broken but in the case of Moovida it is pygobject that needs fixing. The glib2reactor uses a pygobject main loop, AFAIK. And Moovida uses pygtk only for the splash screen, which is unrelated with this bug.

tags: added: performance
dino99 (9d9) wrote :

The latest free moovida 1.09 does not get any maintenance since a while. Now moovidadb.com is supporting Linux and support can be found at : http://www.fluendo.com/faq/

Changed in moovida:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.