[mythtv-users] Threaded File Writer 'taking a long time'

[John Pilkington]

On 19/10/12 21:17, John Pilkington wrote:
> On 19/10/12 17:53, Craig Treleaven wrote:
>> At 4:28 PM +0100 10/19/12, John Pilkington wrote:
>>> Over the past few days I've been seeing this quite often.  I don't
>>> remember seeing it before.  I first noticed it after an upgrade on
>>> Wednesday to mysql 5.5.28-1 on Fedora 16 x86_64, but I can't swear
>>> that it hadn't been happening before.  Recordings seem ok but I've
>>> seen instances of over 6 seconds.
>>>
>>>
>>> 2012-10-19 13:54:18.836330 W
>>> TFW(/mnt/sam1/recb/1703_20121019125800.mpg:78): write(55648) cnt 18
>>> total 1017644 -- took a long time, 6044 ms
>>> 2012-10-19 13:54:24.314063 W
>>> TFW(/mnt/sam1/recb/1703_20121019125800.mpg:78): write(56212) cnt 35
>>> total 1977948 -- took a long time, 5477 ms
>>> 2012-10-19 13:54:26.330029 W
>>> TFW(/mnt/sam1/recb/1703_20121019125800.mpg:78): write(56024) cnt 19
>>> total 1074044 -- took a long time, 1058 ms
>>>
>>> The latest mysql changelog includes:
>>>   - Export THR_KEY_mysys as a workaround for inadequate threading
>>> support
>>>   Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=846602
>>>
>>> That report seems to be Fedora-specific.  Has anyone else seen this?
>>
>> Don't know about MySQL but, using 0.25.2, I was experiencing HDHR
>> recordings that would fail.  Thread is on mythtv-dev:
>>
>> http://www.gossamer-threads.com/lists/mythtv/dev/530543
>>
>> Bottom line, applying the fix committed to 0.26 has solved the problem
>> for me.  Previously, I would have at least one failed recording every
>> 1-2 days.  Haven't had one in the last 5 days since applying the patch:
>>
>> http://code.mythtv.org/trac/changeset/dc0bf9b03248775bbd186f4029b217bba9d4b6a6/mythtv
>>
>>
>>
>> HTH,
>>
>> Craig
>
> Thanks for the links.  I'm on v0.25.2-25-g0817eb2.  I've seen a couple
> of flurries of reports immediately after a previewgen, and there's been
> a fix lowering the priority of that, although I don't have it installed.
>   I'll look again at ionice-ing other disk-intensive stuff and wait a
> bit longer before doing anything else; if problems continue I might try
> reverting mysql, too.  I'd prefer not to build from source if I can
> avoid it.
>
> Cheers,
>
> John P
>

I saw a lot more of these warnings overnight.  Some are certainly linked 
to remuxing within eg mytharchive, or to commflag --rebuild, but they 
don't actually cause failed or faulty recordings.  I tried reverting the 
mysql upgrade but my package manager (smart 1.4.1) just sat at 100% CPU 
apparently doing nothing until I killed it.  The original upgrade had 
similar problems but eventually worked, taking small groups of packages 
at a time. That  wasn't something I usually have to do.  It seems to 
find managing 2400 from 37000 packages a strain :-)

I put a note on the bugzilla thread mentioned above and was told that it 
wasn't the problem, suggesting I try the patch.  Fair enough, but I 
think I'm seeing a very recent change in behaviour.

One recent change was a memory upgrade from 2 to 4 GB; could that have 
caused lengthier writes by increasing buffer size?

John P