[mythtv-users] Mythbackend causing high load

[glen martin]

Not an answer so much as a thought: there is some text floating around
online that talks about filesystems for the video partition. In
particular, delete performance.  If you're floating near the available
space, then deletes will be going on, and if the deletes block for any
appreciable time, this could seem to cause things to go a little asymptotic.

See:

- http://www.mythtv.org/pipermail/mythtv-users/2004-February/030853.html

- http://www.mythtv.org/docs/mythtv-HOWTO-24.html  section 24.2, JFS
   In particular: "There is however, one aspect of filesystem
performance that can have a bearing on the performance of MythTV. In
Linux, deleting a file will utilize I/O bandwidth until the deletion has
been completed. If deleting the file takes long enough, the video
capture buffer may overrun, thereby resulting in dropped frames. Some
filesystems are faster at deleting files than others and, for
multi-gigabyte MythTV video files, these differences can be significant."

HTH

glen

Mike Benoit wrote:
> Interesting, I'm using ReiserFS and I have about 20GB free on a 300gb
> partition. However its been like this for about a month now, and worked
> fine before last week.
>
>
> On Fri, 2006-06-16 at 12:58 -0500, Stuart Larson wrote:
>   
>> I've seen this sort of behavior when recoding or transcoding (doesn't seem
>> to make a difference which) when my free space on drive was close to what
>> Myth is set to keep free - I have Myth set to keep 20G free, and when it
>> reached around 22-23G free, I started seeing this behavior (I'm running
>> reiserfs, so the xfs space-free thing shouldn't be an issue).  Not sure if
>> it would be related...  The recordings did work fine (PVR-250), but
>> watching while recording doesn't work very well.
>>
>>     
>>> I'm seeing something very familiar, mythbackend uses about 100% CPU
>>> during a recording and though not always, I sometimes see IOBOUND errors
>>> in the log. I have transcode/commflag jobs set to run after midnight
>>> each day, and no other processes are using CPU while mythbackend is
>>> hogging it all.
>>>
>>> The weird thing is my box was running fine for a few months prior to a
>>> power outage. After the outage I booted up the box and I started to
>>> notice IVTV buffer overflows happening during every recording causing
>>> the load to spike up to 10+ during each recording. The recording was
>>> useless of course too. This was with IVTV 0.4.1 on a PVR-500.
>>>
>>> So I decided to upgrade to IVTV 0.4.5 to see if that solved the problem.
>>> Well, I no longer see IVTV buffer overflow messages in the log, but now
>>> mythbackend uses 100% CPU. I upgraded to the latest SVN snapshot of
>>> 019-fixes branch to see if that helped at all, but it didn't.
>>>
>>> So now mythbackend uses 100% CPU, the recordings seem to be working
>>> fine, but I can't watch any recordings while this is happening.
>>>
>>> I'm running an Athlon 2100 with kernel 2.6.14.
>>>
>>> Just last week I could have two recordings going at once, mythcomm flag
>>> running in real-time, and two frontends both watching recordings with no
>>> issues at all. Now one recording at a time and NOTHING else is all that
>>> can happen. :(
>>>
>>> Does anyone know what I can do to try and track this issue down?
>>>
>>> Thanks.
>>>
>>> On Fri, 2006-06-16 at 06:41 -0400, Jeff wrote:
>>>       
>>>> On 6/15/06, Ryan Steffes <rbsteffes at gmail.com> wrote:
>>>>
>>>>         
>>>>> Do you, by any chance, have a slave to offload the transcode onto?
>>>>>           
>>>> Try
>>>>         
>>>>> disabling transcode jobs on that backend, and see if it comes back.
>>>>>           
>>>> Mine
>>>>         
>>>>> hasn't since then, even though it's a less than ideal fix.
>>>>>
>>>>>           
>>>> For the most part I don't do transcoding. I do have a 'transcode for
>>>> ipod'
>>>> job which seems to have gotten itself attached to every recording (it
>>>> was
>>>> only supposed to be one show) but I don't think its working at the
>>>> moment.
>>>>
>>>> I do commercial flagging though at the end of each show.
>>>>
>>>> I can try moving this to a slave backend.
>>>> _______________________________________________
>>>> mythtv-users mailing list
>>>> mythtv-users at mythtv.org
>>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>>>         
>>> --
>>> Mike Benoit <ipso at snappymail.ca>
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>>
>>>       
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>     
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>