Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Storage Groups: Usage Preferences

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


spam at afoyi

Mar 5, 2007, 10:23 PM

Post #1 of 7 (3335 views)
Permalink
Storage Groups: Usage Preferences

Hey All,

Firstly, thanks heaps to the devs and testers who have got Storage
Groups working really well. It's simplified my setup hugely!

Just wondering if there is any capability (or plans) or specify a
preference to how the storage groups are utilised?

At the moment I believe Myth will record to the drive with the most
amount of free space if there's only a single recording and will spread
simultaneous the recordings across all available drives to reduce head
movements.

It would be really great if it was possible to define a priority for the
storage group (is there already?) and also a policy of when to go up to
the next priority level (eg, load-balance, free-space, etc)

At the moment I have 2x 250Gb drives in the machine which has all my
tuners. I'm thinking of adding a drive to another machine on the network
and making it available via NFS, but I would like for this remote drive
to only be used if there is not enough storage space on the local drives.

Regards
Darryl
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


cpinkham at bc2va

Mar 6, 2007, 1:29 AM

Post #2 of 7 (3183 views)
Permalink
Re: Storage Groups: Usage Preferences [In reply to]

* On Tue Mar 06, 2007 at 04:53:31PM +1030, Darryl Ross wrote:
> Firstly, thanks heaps to the devs and testers who have got Storage
> Groups working really well. It's simplified my setup hugely!

Glad it's working well for you. :)

> Just wondering if there is any capability (or plans) or specify a
> preference to how the storage groups are utilised?

There is limited ability for this via some undocumented settings, but
there is no GUI to set them up.

> At the moment I believe Myth will record to the drive with the most
> amount of free space if there's only a single recording and will spread
> simultaneous the recordings across all available drives to reduce head
> movements.

It's a bit more complicated than that. Myth uses weights to determine
what filesystem/directory to record to. The following default values are
used:

SGweightPerRecording = 10
SGweightPerPlayback = 5
SGweightPerCommFlag = 5
SGweightPerTranscode = 5
SGweightLocalStarting = -1.99 * SGweightPerRecording
SGmaxRecOverlapMins = 3

The drive with the lowest weight is used first. In a tie, the drive with
the highest amount of free disk space is used first.

Each Storage Group Directory has its own weight, but Myth is smart enough
to know if several directories are on the same shared filesystem. When
a weight is applied to a directory that is in use, it is applied to all
directories on that filesystem because we are trying to spread the load
out across filesystems, not directories on the same filesystem.

The starting weight of all drives is 0. Local filesystems/directories
are then offset by SGweightLocalStarting, so by default they are then
at -19 because SGweightPerRecording defaults to 10. This makes it so
that local drives are preferred over remote drives. A local drive has
to have an effective weight of 20 before a remote drive will be used to
store a new recording. If you do not have any playback going on, this
would mean that you'd have to have 2 recordings going to a local drive
before a remote drive would get used. If you have 2 local drives and
1 remote drive, you'd have to have 4 recordings going on locally before
a remote drive would get used.

So, if you have less than 4 tuners and 2 local drives, then the default
should already give you what you are looking for. If you have more than
4 tuners or want to guarantee that all recordings go to the local drives
unless they fill up, you can do so using the undocumented SGweightPerDir
setting.

In order to make Myth not use a filesystem/directory, we need to
artificially inflate the starting weight for that directory. We can do
this by insertting a setting in the database.

The key for the setting is SGweightPerDir:HOSTNAME:DIRECTORY. The
hostname is the hostname that sees the directory. So if the directory
is actually on the fileserver which is server1 but is mounted via NFS on
server2 which is running mythbackend, we'd use server2 here. The
directory is the local path on HOSTNAME, so you'd put /mnt/video or
whatever you use here for the remotely mounted directory.

SGweightPerDir:server2:/mnt/video

The value that we put in this setting will be applied as an offset to
the initial weight for this directory. You can play it safe by setting
this to something large like 99 or 100 or even higher. So in the
example here, the actual setting key would be:

You need to run the following SQL to insert that into the settings table:

INSERT settings
(value, data, hostname)
VALUES
("SGweightPerDir:server2:/mnt/video", 99, "server2");

So, now when the Storage Groups scheduling code runs, /mnt/video will
start out with a weight of 0. Since it is a remote drive, the only
offsets that will be initially applied will be the one we specified in
the settings table with the SGweightPerDir setting. Your two local
directories would each end up starting out at -19 and the remote
directory would start out at +99. So unless you have a huge number of
recordings and playbacks going on on each of your local drives, the
remote directory will never be used unless the locals fill up.

If you run mythbackend with the "-v schedule,file" option, you can
see the weights as they are applied and the logs will show you why
Myth chose one directory over another when determining where to put
the next recording.

--
Chris (who still needs to get around to documenting this more on the
wiki or in the HOWTO)

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


spam at afoyi

Mar 6, 2007, 2:30 AM

Post #3 of 7 (3179 views)
Permalink
Re: Storage Groups: Usage Preferences [In reply to]

Hi Chris,

Wow, thanks for the in-depth response!

I'm just waiting for my wiki confirmation email to arrive, then I'll
paste in what you've written into the storage groups page.

Regards
Darryl


[Chris Pinkham wrote on 6/03/2007 7:59 PM]:
> * On Tue Mar 06, 2007 at 04:53:31PM +1030, Darryl Ross wrote:
>> Firstly, thanks heaps to the devs and testers who have got Storage
>> Groups working really well. It's simplified my setup hugely!
>
> Glad it's working well for you. :)
>
>> Just wondering if there is any capability (or plans) or specify a
>> preference to how the storage groups are utilised?
>
> There is limited ability for this via some undocumented settings, but
> there is no GUI to set them up.
>
>> At the moment I believe Myth will record to the drive with the most
>> amount of free space if there's only a single recording and will spread
>> simultaneous the recordings across all available drives to reduce head
>> movements.
>
> It's a bit more complicated than that. Myth uses weights to determine
> what filesystem/directory to record to. The following default values are
> used:
>
> SGweightPerRecording = 10
> SGweightPerPlayback = 5
> SGweightPerCommFlag = 5
> SGweightPerTranscode = 5
> SGweightLocalStarting = -1.99 * SGweightPerRecording
> SGmaxRecOverlapMins = 3
>
> The drive with the lowest weight is used first. In a tie, the drive with
> the highest amount of free disk space is used first.
>
> Each Storage Group Directory has its own weight, but Myth is smart enough
> to know if several directories are on the same shared filesystem. When
> a weight is applied to a directory that is in use, it is applied to all
> directories on that filesystem because we are trying to spread the load
> out across filesystems, not directories on the same filesystem.
>
> The starting weight of all drives is 0. Local filesystems/directories
> are then offset by SGweightLocalStarting, so by default they are then
> at -19 because SGweightPerRecording defaults to 10. This makes it so
> that local drives are preferred over remote drives. A local drive has
> to have an effective weight of 20 before a remote drive will be used to
> store a new recording. If you do not have any playback going on, this
> would mean that you'd have to have 2 recordings going to a local drive
> before a remote drive would get used. If you have 2 local drives and
> 1 remote drive, you'd have to have 4 recordings going on locally before
> a remote drive would get used.
>
> So, if you have less than 4 tuners and 2 local drives, then the default
> should already give you what you are looking for. If you have more than
> 4 tuners or want to guarantee that all recordings go to the local drives
> unless they fill up, you can do so using the undocumented SGweightPerDir
> setting.
>
> In order to make Myth not use a filesystem/directory, we need to
> artificially inflate the starting weight for that directory. We can do
> this by insertting a setting in the database.
>
> The key for the setting is SGweightPerDir:HOSTNAME:DIRECTORY. The
> hostname is the hostname that sees the directory. So if the directory
> is actually on the fileserver which is server1 but is mounted via NFS on
> server2 which is running mythbackend, we'd use server2 here. The
> directory is the local path on HOSTNAME, so you'd put /mnt/video or
> whatever you use here for the remotely mounted directory.
>
> SGweightPerDir:server2:/mnt/video
>
> The value that we put in this setting will be applied as an offset to
> the initial weight for this directory. You can play it safe by setting
> this to something large like 99 or 100 or even higher. So in the
> example here, the actual setting key would be:
>
> You need to run the following SQL to insert that into the settings table:
>
> INSERT settings
> (value, data, hostname)
> VALUES
> ("SGweightPerDir:server2:/mnt/video", 99, "server2");
>
> So, now when the Storage Groups scheduling code runs, /mnt/video will
> start out with a weight of 0. Since it is a remote drive, the only
> offsets that will be initially applied will be the one we specified in
> the settings table with the SGweightPerDir setting. Your two local
> directories would each end up starting out at -19 and the remote
> directory would start out at +99. So unless you have a huge number of
> recordings and playbacks going on on each of your local drives, the
> remote directory will never be used unless the locals fill up.
>
> If you run mythbackend with the "-v schedule,file" option, you can
> see the weights as they are applied and the logs will show you why
> Myth chose one directory over another when determining where to put
> the next recording.
>
> --
> Chris (who still needs to get around to documenting this more on the
> wiki or in the HOWTO)
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


janne-mythtvusers at grunau

Mar 6, 2007, 6:16 AM

Post #4 of 7 (3202 views)
Permalink
Re: Storage Groups: Usage Preferences [In reply to]

On Tuesday 06 March 2007 10:29:11 Chris Pinkham wrote:
>
> It's a bit more complicated than that. Myth uses weights to
> determine what filesystem/directory to record to. The following
> default values are used:
>
> SGweightPerRecording = 10
> SGweightPerPlayback = 5
> SGweightPerCommFlag = 5
> SGweightPerTranscode = 5

We might should think of using higher weight for lossless mpeg2
transcodes. They are the most IO demanding job we have.
I'll look into it.

Janne
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


cpinkham at bc2va

Mar 6, 2007, 7:34 AM

Post #5 of 7 (3182 views)
Permalink
Re: Storage Groups: Usage Preferences [In reply to]

* On Tue Mar 06, 2007 at 03:16:00PM +0100, Janne Grunau wrote:
> On Tuesday 06 March 2007 10:29:11 Chris Pinkham wrote:
> > It's a bit more complicated than that. Myth uses weights to
> > determine what filesystem/directory to record to. The following
> > default values are used:
> >
> > SGweightPerRecording = 10
> > SGweightPerPlayback = 5
> > SGweightPerCommFlag = 5
> > SGweightPerTranscode = 5
>
> We might should think of using higher weight for lossless mpeg2
> transcodes. They are the most IO demanding job we have.
> I'll look into it.

Actually now that I think about it, transcode in general may need
to be higher than recording because it involves both reading and
writing. So SGweightPerTranscode could be at least 15.

I don't know if it does it, but the lossless transcoder needs
to honor the JobQueue CPU setting. If that is done, then we
could make these weights dependent on the JobQueue CPU setting.
A transcode running at the Low CPU setting shouldn't use anywhere
near as many resources as one running at High. The same holds
true for mythcommflag.

We could change SGweightPerTranscode to 15 by default and then
multiply SGweightPerCommFlag and SGweightPerTranscode by 0.5 (or
0.75) if the JobQueue CPU setting is Low or multiply by 1.5 if
the JobQueue CPU setting is High, that way we weight things more
if we know they'll use more CPU (hence higher disk I/O).

--
Chris
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


janne-mythtvusers at grunau

Mar 6, 2007, 10:23 AM

Post #6 of 7 (3178 views)
Permalink
Re: Storage Groups: Usage Preferences [In reply to]

On Tuesday 06 March 2007 16:34:02 Chris Pinkham wrote:
> * On Tue Mar 06, 2007 at 03:16:00PM +0100, Janne Grunau wrote:
> > On Tuesday 06 March 2007 10:29:11 Chris Pinkham wrote:
> > > It's a bit more complicated than that. Myth uses weights to
> > > determine what filesystem/directory to record to. The following
> > > default values are used:
> > >
> > > SGweightPerRecording = 10
> > > SGweightPerPlayback = 5
> > > SGweightPerCommFlag = 5
> > > SGweightPerTranscode = 5
> >
> > We might should think of using higher weight for lossless mpeg2
> > transcodes. They are the most IO demanding job we have.
> > I'll look into it.
>
> Actually now that I think about it, transcode in general may need
> to be higher than recording because it involves both reading and
> writing.

And depending on the CPU might also use a higher frame rate.

> So SGweightPerTranscode could be at least 15.

Ack.

> I don't know if it does it, but the lossless transcoder needs
> to honor the JobQueue CPU setting.

How? The trancodes doesn't use much CPU (except I/O wait). The only way
to slow it down would be a sleep() in the main processing loop.

I'm not sure if slowing the lossless transcode from more than 20MByte/s
to below 20mbit/s is a good idea. At least when the rest of the system
is idle.
A process with nice value 19 is able to use 100% cpu, mythtranscode with
sleep can't use the full I/O bandwidth regardlessly of the system
state.

> We could change SGweightPerTranscode to 15 by default and then
> multiply SGweightPerCommFlag and SGweightPerTranscode by 0.5 (or
> 0.75) if the JobQueue CPU setting is Low or multiply by 1.5 if
> the JobQueue CPU setting is High, that way we weight things more
> if we know they'll use more CPU (hence higher disk I/O).

I'm not sure if this kind of scaling is useful.

I hope I'll find a method to slow down the lossless transcoder if a
recording is using the same filesystem.

Janne
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


cpinkham at bc2va

Mar 6, 2007, 2:59 PM

Post #7 of 7 (3174 views)
Permalink
Re: Storage Groups: Usage Preferences [In reply to]

* On Tue Mar 06, 2007 at 07:23:02PM +0100, Janne Grunau wrote:
> > I don't know if it does it, but the lossless transcoder needs
> > to honor the JobQueue CPU setting.
>
> How? The trancodes doesn't use much CPU (except I/O wait). The only way
> to slow it down would be a sleep() in the main processing loop.

That's exactly what mythcommflag does when running at Low CPU usage.

Low = sleep some every frame and run niced
Medium = just run niced, don't sleep any
High = no sleeping and not nice at all

Realtime flagging of course ignores the CPU setting and tries to stay
as close to realtime as possible (well, within 30 seconds I think). :)

> I'm not sure if slowing the lossless transcode from more than 20MByte/s
> to below 20mbit/s is a good idea. At least when the rest of the system
> is idle.

I think that can be addressed separately as several people want to do
with adjusting the max number of Jobs based on CPU or system load.

If a user sets their JobQueue CPU usage to Low, and a lossless transcode
fires off while they are recording something else, it could cause problems
with the recording if mythtranscode doesn't honor the CPU setting.

I can also see adding another "Auto" value to the JobQueue CPU setting
that would let jobs throttle themselves based on current load.

> A process with nice value 19 is able to use 100% cpu, mythtranscode with
> sleep can't use the full I/O bandwidth regardlessly of the system
> state.

Right, that's why Low = nice & sleep, medium = nice, and high = no sleep and
not nice.

> > We could change SGweightPerTranscode to 15 by default and then
> > multiply SGweightPerCommFlag and SGweightPerTranscode by 0.5 (or
> > 0.75) if the JobQueue CPU setting is Low or multiply by 1.5 if
> > the JobQueue CPU setting is High, that way we weight things more
> > if we know they'll use more CPU (hence higher disk I/O).
>
> I'm not sure if this kind of scaling is useful.

A commercial flagging job running at High will use a whole lot more
resources than a recording or a playback since it will run at a few hundred
frames per second on a decent speed CPU.

> I hope I'll find a method to slow down the lossless transcoder if a
> recording is using the same filesystem.

I'm open to ideas. I'm not sure that that should be up to the transcoder
though. Should the Storage Groups scheduling code try to schedule storage
around other things going on, or shoudl it blindly put recordings on
in-use filesystems hoping the app will throttle itself back? I think
the SG code should be the one to make the decision since it has the bigger
picture of the whole environment.

Time to head home for the day though, so I'll give this some more thought
while driving. :)

--
Chris
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.