Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#10122 closed Bug Report - General (Unverified)

mythbackend 100% cpu

Reported by: diespambox@… Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

My backend starts normal and after several hours the cpu usage goes up ~100%

Attachments (2)

myth_version (754 bytes) - added by anonymous 8 years ago.
mythtv version
gdb.txt (55.1 KB) - added by anonymous 8 years ago.
gdb log

Download all attachments as: .zip

Change History (13)

Changed 8 years ago by anonymous

Attachment: myth_version added

mythtv version

Changed 8 years ago by anonymous

Attachment: gdb.txt added

gdb log

comment:1 Changed 8 years ago by diespambox@…

forgot to mention that the backend seems to behave quiet normal except for the 100% cpu usage...

comment:2 Changed 8 years ago by danielk

Owner: set to danielk
Status: newassigned

I'm assigning this to myself as it looks like all the threads are sleeping except for two DVB recorder threads. Those two threads do at first blush look like they are doing valid work, but this needs looking at.

comment:3 Changed 8 years ago by Raymond Wagner

Where are these binaries coming from? That version output is different from what you should get if compiling from source, and that is not a hash recognized by git as being in the primary repository.

comment:4 Changed 8 years ago by diespambox@…

No binaries. This was build from the git ebuilds. I created the ebuild with the ebuild buildscript from the packaging repository. (0.25_pre20111018)

comment:5 Changed 8 years ago by Raymond Wagner

Look at this egg, it's all over my face! (I wrote the code that now appears to be generating the wrong version after Github changed their download mechanism)

For reference, the version in question is v0.25pre-3559-gae6621f.

comment:6 Changed 8 years ago by danielk

Status: assignedinfoneeded

I'm going to need "mythbackend -v channel,record" logs, attach the full log from startup, bzip2 -9 it if you have to.

I can answer both of these questions with the log, but FYI I'd like to know:

Do you have EIT data collection enabled? Is the system recording when the CPU jumps?

It looks like either we are reading a lot of data and processing it, in which case may not really be a problem since the backend continues to function properly. or a select/poll is failing and we are constantly reading small dribs and drabs of data from the DVB devices instead of reasonable chunks, in which case we need to find out why this is happening and correct the problem.

comment:7 in reply to:  6 Changed 8 years ago by diespambox@…

Replying to danielk:

I'm going to need "mythbackend -v channel,record" logs, attach the full log from startup, bzip2 -9 it if you have to.

I just restarted the backend with -v channel,record and also stared a new recording, the backend seems to stay steady at ~10% cpu usage...

Do you have EIT data collection enabled?

yes, on 2 out of 4 devices (/dev/dvb/adapter0/frontend0 and /dev/dvb/adapter1/frontend1)

Is the system recording when the CPU jumps?

no, it is steadily at 100% but it may have been recording when it started

I'll attach the log as soon as i see the backend hog the cpu again.

comment:8 in reply to:  6 Changed 8 years ago by diespambox@…

Replying to danielk:

I'm going to need "mythbackend -v channel,record" logs, attach the full log from startup, bzip2 -9 it if you have to.

it is still to large for trac, i uploaded it here: http://www.twobees.de/foobar/backend.log.bz2

comment:9 Changed 8 years ago by danielk

Resolution: Unverified
Status: infoneededclosed

Assuming mythbackend was using 100% CPU when the log was captured it appears that the system was busy collecting EIT. It doesn't look like any expensive fixup was being used so I think plain old EIT collection may just be stressing your system.

Are you using an Atom or ARM processor?

Since it's nothing really obvious the only way we can really figure this out is if you use oprofile to find the hot-spots, but that isn't really a task I can expect of you unless you are a programmer familiar with optimization so I'm going to tag this as unverified for now. Again, it may just be that the EIT rate is high enough that it would be expected to saturate a CPU.

comment:10 in reply to:  9 Changed 8 years ago by diespambox@…

Replying to danielk:

Assuming mythbackend was using 100% CPU when the log was captured it appears that the system was busy collecting EIT.

yes, it was at 100% when i stopped the backend.

Are you using an Atom or ARM processor?

no

Since it's nothing really obvious the only way we can really figure this out is if you use oprofile to find the hot-spots, but that isn't really a task I can expect of you unless you are a programmer familiar with optimization so I'm going to tag this as unverified for now. Again, it may just be that the EIT rate is high enough that it would be expected to saturate a CPU.

Do you have any good link on how to do this?

comment:11 Changed 8 years ago by danielk

This will get you started:

http://code.mythtv.org/doxygen/group__profiling__mythtv.html

But once you find a line that is using a lot of CPU it may be something like the QString constructor so you need to find out why we are calling the QString constructor so often. Then you may need to do a call graph profile. You also generally need to tweak the sampling, too much sampling changes the performance characteristics and may obscure the problem, too little may fail to narrow down the problem area.

This will give a lot more info, but perhaps too much:

http://oprofile.sourceforge.net/doc/index.html

Note: See TracTickets for help on using tickets.