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

[osma ahvenlampi]

On 12/8/06, Daniel Kristjansson <danielk at cuymedia.net> wrote:
> $ cat /sys/block/hda/queue/scheduler
> noop anticipatory deadline [cfq]
>
> No idea what this means. I guess I'm using cfq, is that correct?

yes

> It's the seeks to the DB for writing the keyframe DB entries
> which seems to throw the most randomness into the elevator.

mysql is most likely running at the same nice value (0) as the backend
writing the recordings. In this setting, it would most likely be the
best approach to run recordings at (unnice) -5, mysql at 0, playback
at (nice) +5 and transcodings and commflags at (nice) +10.

I realize this is not how most systems are set up, and in order to run
anything unnice that must be root -- scale those down by +5 and all
can be user processes.

> If this is disk scheduler dependant how does this work on Macs,
> the BSDs and MS Windows?

If some OS can not balance its I/O well, that's their problem. Users
will have to compensate by providing more I/O capacity. Or think of it
this way -- Linux I/O scheduler can probably let the user get away
with overcommitting their available I/O.

> I would think that networking would still be a problem even if
> the disk is taken care of. Though maybe this could be addressed
> by only doing commercial flagging and transcoding on the file
> server instead of on the myth backend and frontend machines.

Networking can at least in theory be solved with the same principles
using QoS settings on per-connection basis. Although what's more
likely to be a problem is that "network reads", which in many cases
with Myth are in fact nfs/smb clients will cause disk access with the
priority level of the nfs/smb daemon (and see above regarding nice
levels..) -- to solve that either those daemons would have to be
reprioritised or myth processes would in fact need to work as file
servers (http on custom ports might do the trick, sort of like UPnP).

Or you could solve it the way Internet is usually solved -- brute
force and more capacity than is going to be needed for the job at hand
:)

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