tom at redpepperracing
Jun 19, 2012, 6:14 AM
Post #6 of 13
(929 views)
Permalink
|
On Mon, Jun 18, 2012 at 9:21 AM, Tom Lichti <tom [at] redpepperracing> wrote:
> On Mon, Jun 18, 2012 at 3:48 AM, Joseph Fry <joe [at] thefrys> wrote:
>>>
>>> >> Is anyone else seeing extremely high CPU usage on their backend when
>>> >> playing back *any* content on a remote front end? I just noticed that
>>> >> during playback, the CPU usage of my backend stays around 175-200% on
>>> >> a 2 x Dual core AMD system. I can't imagine what it would be doing
>>> >> other than just streaming the file, is anyone else seeing this, or can
>>> >> explain it?
>>> >>
>>> >> I am on close to current master:
>>> >>
>>> >> MythTV Version : v0.26-pre-629-g181641a-dirty
>>> >> MythTV Branch : master
>>> >> Network Protocol : 75
>>> >> Library API : 0.26.20120614-1
>>> >> QT Version : 4.6.3
>>> >> Options compiled in:
>>> >> linux profile use_hidesyms using_alsa using_oss using_backend
>>> >> using_bindings_perl using_bindings_python using_bindings_php using_dvb
>>> >> using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv
>>> >> using_ivtv using_joystick_menu using_libcrypto using_libdns_sd
>>> >> using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit
>>> >> using_qtscript using_qtdbus using_v4l2 using_v4l1 using_x11
>>> >> using_xrandr using_bindings_perl using_bindings_python
>>> >> using_bindings_php using_mythtranscode using_opengl
>>> >> using_ffmpeg_threads using_live using_mheg using_libxml2
>>> >
>>> > Hmmm....looks like it may have been a memory leak of some sort, I
>>> > started getting OOM killers and lots of swapping. I'll keep an eye on
>>> > it and see if it happens again.
>>> >
>>>
>>> I love talking to myself. Now with one frontend playing back and two
>>> recordings (1 HDHR and 1 HD-PVR on a slave BE) the BE CPU is over
>>> 250%. Lots of free memory (overall system memory is 8GB), so the OOM
>>> doesn't explain it.
>>>
>>
>> The only things I can think of that MAY cause excessive CPU usage on the
>> backend, explicitly during playback/recording are:
>>
>> 1. Jobs (transcode/commercial flagging)
>> 2. Degraded software RAID array.
>> 3. non-DMA disk IO.
>> 4. Encrypted/compressed drive
>> 5. non-DMA network controller, or some on chipset NIC and a really horrible
>> network causing a ton of errors?
>>
>> First try doing a couple of IO intensive tasks to confirm if it's mythtv
>> (perhaps use VLC to stream from the HDHR to a file?). I suspect it's
>> something on the system itself, not mythtv.
>>
>> If I am right I would start by verifying all RAID arrays are clean, and if
>> all looks good, do a full shutdown. Then disconnect power and let it sit
>> for 15 minutes so any charged caps can dissipate before plugging in and
>> turning on. This has fixed countless weird issues for me in the past,
>> primarily with NIC's that support WOL. Seems as though many components of
>> your system don't truly reset anymore until the power is cut completely.
>
> 1,2 and 4 are definitely not a factor, 3 and 5 I haven't looked at, I
> will look at those, as well as a restart, but it's been running fine
> for months, it only started with the a recent git pull that I did. If
> I rule out everything else, I'll try to track down the commit that may
> have caused it. I have my suspicions... :)
There is definitely a massive memory leak in the back end logging
system, I have opened ticket 10846 with a valgrind log attached.
Tom
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users
|
