[mythtv-users] Commflag-related IOBOUND errors

Brandon Beattie brandon+myth at linuxis.us
Wed Jan 18 15:00:00 UTC 2006


On Tue, Jan 17, 2006 at 04:52:02PM -0800, Yeechang Lee wrote:
> Rescheduling's always seemed pretty lightweight on my setup, but I
> *do* see intermittent IOBOUNDs; when they occur, they appear every
> five minutes on the dot for 3-8 seconds (:10:02-05, :20:02-08,
> :25:02-06, etc.), especially when I'm recording dual HD streams and
> especially especially when also watching a third stream, using gigabit
> Ethernet and a RAID 1 NAS. I am pretty sure this is related to my
> frontend/backend checking for user/commflag jobs every five minutes;
> before I changed this from the default setting of every minute, I'd
> see the IOBOUNDs pop up in the exact same way (you guessed it) every
> minute. (Note, also, that I see the IOBOUNDs even if I'm outside the
> 2:30-6am time block I've told the backend to run commflag jobs in.)
> It's quite possible that this is a swap-related issue and that adding
> more RAM to my 512MB system would take care of this, but as a
> cheapskate I'm reluctant to do so because I haven't run into any other
> memory-related issues I know of.

Every time a recording, transcode, commercial detection, and so on start
or finish the recordings table is updated.  If you use EIT monitoring
with a HD tuner than every time this finishes it can cause the
recording scheduler to be re-run.  Adding RAM will not help at all.
This is purely a system and disk IO issue.  I have my mysql databases on
a seperate drive than recordings, but I still get IO bound issues once
in a while.  The thread for rescheduling does take all the CPU and IO it
can get for those few seconds, and with the mysql and disk writing
threads they don't always work well together.  It's a known problem but
only shows up for HD users more so because HD requires such a large
amount of bandwidth and it can't really stand a hickup.  Also, the PCI
bus can be occupied and cause data from the card to be lost if the
system IO can't be freed up quick enough to handle the data.  HD tuner
cards have a rather small cache on them.  If anything occupies the
system IO longer than 500ms then you risk losing data from the HD tuner,
and Myth and the scheduler does this at times.

It's also not just disk access, if you use a remote frontend you'll
notice network traffic (Depending on the motherboards and ethernet
chipset) will also stutter during the time the schedular runs.

The best way to fix this?  Keep the drive for the database on a
different disk than one used for recordings.  Use XFS or JFS.  Make sure
nothing else IO intensive is running when the schedular runs.  Intel
based systems have less of a problem than AMD from what I've seen (Intel
systems with hyper threading that is).  Reiser is a good choice though
for the filesystem holding the database, since it does a better job with
sub GB size files.  

--Brandon


More information about the mythtv-users mailing list