[mythtv] [mythtv-commits] Ticket #2782: automatic simultaneous jobs scaling

[f-myth-users at media.mit.edu]

    > Date: Sat, 9 Dec 2006 00:08:07 +0200
    > From: "osma ahvenlampi" <oa at iki.fi>

    > On 12/8/06, f-myth-users at media.mit.edu <f-myth-users at media.mit.edu> wrote:
    > > No I/O scheduling setting did a damn at preventing trashed recordings
    > > when I was debugging issues of MySQL being too disk-intensive a few
    > > months ago.  I tried 'em all.

    > Did you try niceing MySQL? See my earlier message.

If you're talking CPU niceness, it doesn't matter.  MySQL uses a tiny
amount of CPU while scheduling, but absolutely thrashes the disk
unless it has huge caches.  (I don't know how much of that is writing,
but if any substantial amount of it is, then ionice won't help since
ionice [according to a recent post] doesn't nice writes at all, and
the encoders are writing too.  I don't recall if Breezy fully
supported ionice or only the I/O scheduling stuff, but I wasn't
about to go to the pain of revving the kernel [hence -everything- on
-both- boxes, e.g., ivtv versions, lirc, etc etc] just to test it.)

    > > But since you can't specify
    > > "thou shalt run a kernel where I/O scheduling must work in
    > > such-and-such a way", you can't depend on it.

    > In the same vein, one might also argue that since you can't specify
    > users must have hard disks faster than the combined bandwidth of their
    > recorders, you can't depend on that either -- but if you don't,
    > recordings will break. So you HAVE to make assumptions, it's just a
    > question what assumptions are good ones.

Don't create strawman arguments.  The disks -aren't- slower than the
recorders (not even 6 SD recorders), but they -are- slower if the
heads are being thrashed by another process, and even a -single-
recording will be trashed if the heads are thrashed enough.  I saw
that behavior when the scheduler ran when using MySQL's default
settings for this distribution (Ubuntu Breezy), and the scheduler
runs -every- time a recording ends.  That means that a recording that
ended while another was ongoing cause the ongoing one to drop many
seconds at a time.  Not always, but often.

Note, btw, that even putting MySQL's DB on a separate spindle -and-
IDE controller did -not- help (enough); you'd think that recordings on
hda and the DB on hdc would separate out head motion and other I/O,
but it didn't.  It helped somewhat (raising the number of simultaneous
streams and/or commflagging load that could typically be tolerated
before scheduler activity trashed encoding streams), but not by a lot.

And you're assuming that everybody runs Myth under particular Linux
kernels.  They don't even all use Linux!  So assuming that they can
exercise the sort of fine-grained control over the I/O subsystem that
-might- be possible under the most bleeding-edge Linux kernel isn't
something that can be applied to the entire user base.  And if you
can't apply it everywhere, it needs an off switch.

So -my- assumptions are, "Any automatic system that tries to increase
I/O load on the MBE without my say-so is likely to cause trashed recordings."

    > > What -did- work (sort of) was changing some MySQL parameters (I'll
    > > send followup mail at some point for the archives), and even so, I
    > > have to be cautious not to have too many processes flailing on the
    > > MBE's disk (e.g., via NFS mounts from the SBE/FE, via other programs
    > > moving things around as part of my automation, via commflagging, etc.)

    > All of this would make a good argument for using an embedded libsqlite
    > instead of MySQL, since then the parameters would be in MythTV's
    > control.. I don't want to pick a fight by arguing that, though :)

I have no opinion on that, but it hasn't gotten a good reception on
the list when others have suggested it.  (Or maybe it's that it just
wasn't up to the task; I don't recall.)

    > > for whom it does, fine.  But you can't claim "it works so well it
    > > won't need an OFF switch" because you haven't seen everyone's
    > > configurations, and there will always be new ones in the future.

    > Sure. So is that "off switch" a ./configure param, a mythtv-setup
    > param, or what? Does the old settings need to stay too? Is everyone
    > really happy with the ever-increasing amount of config params and how
    > they create an exponentially more complicated universe of different
    > combinations?

Some parameter that can be set without recompiling.  Lots of people
use prepackaged distributions; having to recompile just to turn this
off would shaft them.  So presumably a mythtv-setup value or at least
a flag in the DB that can be set via a MySQL statement.