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

[osma ahvenlampi]

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.

> 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.

> 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 :)

> 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?

-- 
Osma Ahvenlampi   <oa at iki.fi>       http://www.fishpool.org