[ATrpms-users] mythfilldatabase increased run time

[John Welch]

On Thu, Jan 19, 2012 at 1:19 PM, Chris Schanzle <schanzle at nist.gov> wrote:

> Since upgrading from Fedora 14 to 16 during the Christmas break, I notice
> "mythfilldatabase --refresh-all" has increased in runtime from about 4
> minutes to about 2 hours +/- 20 mins.  Same hardware & disks,
> schedules-direct channels basically unchanged (maybe added a few).  Was
> running mythtv-0.24.1-278, which is same version before and after.  I
> suspect it's a change in mysql from 5.1.58 to 5.5.14.  It's really pounding
> on the system disks, quite likely the /var/lib/mysql/ib* log files.  db's
> have been optimized via optimize_mythdb.pl and I occasionally defragment
> the db files by copying /usr/lib/mysql/ to a new dir and moving it into
> place every so often.
>
> Check mythfilldatabase start/stop times via:
> egrep '[^:] Running mythfill|run complete' /var/log/mythtv/mythbackend.**
> log
>
> While realizing this is not a mysql support forum, I was curious if other
> atrpms mythtv users noticed this and might have suggestions.
> Thanks!
>
>
I have seen this as well since doing the same jump from F14 to F16 that you
did.  I don't typically time the 'mythfilldatabase' process, but I have
noticed the hard drive light pinned on my MythTV back-end system and each
time I check it is this process causing it.  The system is totally dragging
when this happens and it takes a while to complete.  I think / thought this
had something to do with F16 using a 3.1 kernel, which now has the default
of mounting ext3 / ext4 file systems with barriers enabled.  I have seen
some discussion on this on the MythTV mailing list and the suggested
solution was to disable barriers by adding the 'barrier=0' option to
/etc/fstab for the file system that contains the myth database.  However, I
have to say that I have tried this and it has not fixed the problem for me,
so there could be something else going on.  I would be interested to hear
how you make out with this problem.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.atrpms.net/pipermail/atrpms-users/attachments/20120119/58073c9b/attachment.html>