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

Mailing List Archive: MythTV: Users

Very slow mythfrontend, mysql at 100%

 

 

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


pijnacker at dse

Nov 19, 2009, 10:46 AM

Post #1 of 14 (1000 views)
Permalink
Very slow mythfrontend, mysql at 100%

Hi all,

My primary frontend is very slow since a while.
Deleting recordings etc. is taking seconds, which is very annoying.
I noticed that mysql is at 100% cpu on the backend.
Could it be that over the years mythconverg has become so big that
this is the cause of the issue?

If so, which tables can I safely purge?

Thanks,

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


mtdean at thirdcontact

Nov 19, 2009, 11:05 AM

Post #2 of 14 (968 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On 11/19/2009 01:46 PM, Ronald Pijnacker wrote:
> My primary frontend is very slow since a while.
> Deleting recordings etc. is taking seconds, which is very annoying.
> I noticed that mysql is at 100% cpu on the backend.
> Could it be that over the years mythconverg has become so big that
> this is the cause of the issue?
>
> If so, which tables can I safely purge?

No, MythTV cleans up the data in the mythconverg database--and besides,
myth doesn't use that much data, so even if stuff wasn't being cleaned
up, it wouldn't get that large.

Something else is going on.

I have a clean mythconverg database and get:

# du -sh /srv/mysql/mythconverg/
448M /srv/mysql/mythconverg/

(that's 448MiB). That's not very big from a MySQL standpoint but is
probably rather large from a mythconverg standpoint. My performance is
fine, though.

I'd guess it's more likely schema corruption (i.e. missing/broken
indices, etc.--and, yes, I saw that you said in IRC it's not crashed
tables, but I mean broken schema) or something.

If you'd like to get Myth to recreate your schema (and all indices,
etc.) see http://www.mythtv.org/wiki/Database_Backup_and_Restore and:
a) Back up your DB
b) Drop your DB
c) Create a new DB with mc.sql
d) Create a new DB schema by running and exiting mythtv-setup
e) Do a partial restore (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
)
f) Run mythtv-setup to reconfigure mythbackend
g) Start mythbackend
h) Run mythfrontend and reconfigure mythfrontend and all your plugins

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


info at gxl

Nov 19, 2009, 11:09 AM

Post #3 of 14 (973 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

Ronald Pijnacker said the following on 19/11/09 19:46:
> Hi all,
>
> My primary frontend is very slow since a while.
> Deleting recordings etc. is taking seconds, which is very annoying.
> I noticed that mysql is at 100% cpu on the backend.
> Could it be that over the years mythconverg has become so big that
> this is the cause of the issue?
>
> If so, which tables can I safely purge?
>
> Thanks,
>
> Ronald
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
Hi,

I have the same thing, also made a bug report (#7604) for it since it only happens since I upgraded to 0.22 (and from Ubuntu
8.04 to 9.1).

I have enabled the slow-query-log from MySQL and it shows the following query as being slow (13 secs):

SELECT DISTINCT channel.chanid, channel.sourceid, program.starttime, program.endtime, program.title, program.subtitle,
program.description, channel.channum, channel.callsign, channel.name, oldrecduplicate, program.category,
sched_temp_record.recpriority, sched_temp_record.dupin, recduplicate, findduplicate, sched_temp_record.type,
sched_temp_record.recordid, program.starttime - INTERVAL sched_temp_record.startoffset
MINUTE AS recstartts, program.endtime + INTERVAL sched_temp_record.endoffset
MINUTE AS recendts, program.previouslyshown, sched_temp_record.recgroup, sched_temp_record.dupmethod, channel.commmethod,
capturecard.cardid, cardinput.cardinputid, UPPER( cardinput.shareable ) = 'Y' AS shareable, program.seriesid,
program.programid, program.category_type, program.airdate, program.stars, program.originalairdate,
sched_temp_record.inactive, sched_temp_record.parentid, (

CASE sched_temp_record.type
WHEN 6
THEN sched_temp_record.findid
WHEN 9
THEN to_days( date_sub( program.starttime, INTERVAL time_format( sched_temp_record.findtime, '%H:%i' )
HOUR_MINUTE ) )
WHEN 10
THEN floor( (
to_days( date_sub( program.starttime, INTERVAL time_format( sched_temp_record.findtime, '%H:%i' )
HOUR_MINUTE ) ) - sched_temp_record.findday ) /7
) *7 + sched_temp_record.findday
WHEN 7
THEN sched_temp_record.findid
ELSE 0
END
), sched_temp_record.playgroup, oldrecstatus.recstatus, oldrecstatus.reactivate, program.videoprop +0, program.subtitletypes
+0, program.audioprop +0, sched_temp_record.storagegroup, capturecard.hostname, recordmatch.oldrecstatus,
sched_temp_record.avg_delay, channel.recpriority + cardinput.recpriority + ( cardinput.cardinputid =
sched_temp_record.prefinput ) *2 AS powerpriority
FROM recordmatch
INNER JOIN sched_temp_record ON ( recordmatch.recordid = sched_temp_record.recordid )
INNER JOIN program ON ( recordmatch.chanid = program.chanid
AND recordmatch.starttime = program.starttime
AND recordmatch.manualid = program.manualid )
INNER JOIN channel ON ( channel.chanid = program.chanid )
INNER JOIN cardinput ON ( channel.sourceid = cardinput.sourceid )
INNER JOIN capturecard ON ( capturecard.cardid = cardinput.cardid )
LEFT JOIN oldrecorded AS oldrecstatus ON ( oldrecstatus.station = channel.callsign
AND oldrecstatus.starttime = program.starttime
AND oldrecstatus.title = program.title )
ORDER BY sched_temp_record.recordid DESC

I dug in a little deeper and when I run this query direclt from mysql (phpmyadmin) it takes 13 secs but if I remove the two
fields from oldrecstatus it only takes 3 secs. For this test I have disabled the cache with SQL_NO_CACHE and I have only
removed the two fields (oldrecstatus.recstatus, oldrecstatus.reactivate) but have kept the JOIN on that table.

Anyone have an idea?

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


mythtv-users2 at dwilga-linux1

Nov 19, 2009, 1:12 PM

Post #4 of 14 (951 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

At 8:09 PM +0100 11/19/09, GXL.nl wrote:
>I dug in a little deeper and when I run this query direclt from
>mysql (phpmyadmin) it takes 13 secs but if I remove the two fields
>from oldrecstatus it only takes 3 secs. For this test I have
>disabled the cache with SQL_NO_CACHE and I have only removed the two
>fields (oldrecstatus.recstatus, oldrecstatus.reactivate) but have
>kept the JOIN on that table.

In my experience, there should be no speed difference if all you did
was remove two fields from the SELECT part of the statement. It's
usually necessary to remove a JOIN or sub-select.

The other two things that can have a huge effect on speed are missing
indices on JOINed fields and different character collations (latin1
vs. UTF-8, for instance) on fields being compared or JOINed.

I just ran this on my machine, with the parts you removed, and it
took 746 mS to return 9400 rows.

Perhaps if you give me the output of EXPLAIN for this statement,
something will jump out. Search and replace "sched_temp_record" with
"record" for this to work. A few indices I found that may help are:

ALTER TABLE `cardinput` ADD INDEX ( `sourceid` );
ALTER TABLE `cardinput` ADD INDEX ( `cardid` );
ALTER TABLE `channel` ADD INDEX ( `sourceid` );

One other thing: Where is your "tmpdir", as set in /etc/my.cnf? This
query operates on a temporary table which can be quite large, and
uses another temporary table for sorting. If your tmp_table_size is
too low and you haven't set a tmpdir, then mysql may be writing to a
slow (USB, perhaps?) disk.
--
Dan Wilga "Ook."
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 19, 2009, 1:49 PM

Post #5 of 14 (959 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On 11/19/2009 04:12 PM, Dan Wilga wrote:
> At 8:09 PM +0100 11/19/09, GXL.nl wrote:
>> I dug in a little deeper and when I run this query direclt from mysql
>> (phpmyadmin) it takes 13 secs but if I remove the two fields from
>> oldrecstatus it only takes 3 secs. For this test I have disabled the
>> cache with SQL_NO_CACHE and I have only removed the two fields
>> (oldrecstatus.recstatus, oldrecstatus.reactivate) but have kept the
>> JOIN on that table.
>
> In my experience, there should be no speed difference if all you did
> was remove two fields from the SELECT part of the statement. It's
> usually necessary to remove a JOIN or sub-select.
>
> The other two things that can have a huge effect on speed are missing
> indices on JOINed fields and different character collations (latin1
> vs. UTF-8, for instance) on fields being compared or JOINed.
>
> I just ran this on my machine, with the parts you removed, and it took
> 746 mS to return 9400 rows.
>
> Perhaps if you give me the output of EXPLAIN for this statement,
> something will jump out.

Excellent idea.

> Search and replace "sched_temp_record" with "record" for this to work.
> A few indices I found that may help are:
>
> ALTER TABLE `cardinput` ADD INDEX ( `sourceid` );
> ALTER TABLE `cardinput` ADD INDEX ( `cardid` );
> ALTER TABLE `channel` ADD INDEX ( `sourceid` );

Please don't modify the schema. Doing so only breaks upgrades and then
results in invalid tickets that waste time (when we're trying to find
out why your broken database schema doesn't upgrade).

If there's a need for those indices, please file a ticket on trac with
information such as the reasoning behind the indices and examples of the
improvement they show.

> One other thing: Where is your "tmpdir", as set in /etc/my.cnf? This
> query operates on a temporary table which can be quite large, and uses
> another temporary table for sorting. If your tmp_table_size is too low
> and you haven't set a tmpdir, then mysql may be writing to a slow
> (USB, perhaps?) disk.

Good point. NFS/CIFS may also be bad.

Mike

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


info at gxl

Nov 19, 2009, 1:59 PM

Post #6 of 14 (955 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

Dan Wilga said the following on 19/11/09 22:12:
> At 8:09 PM +0100 11/19/09, GXL.nl wrote:
>> I dug in a little deeper and when I run this query direclt from mysql
>> (phpmyadmin) it takes 13 secs but if I remove the two fields from
>> oldrecstatus it only takes 3 secs. For this test I have disabled the
>> cache with SQL_NO_CACHE and I have only removed the two fields
>> (oldrecstatus.recstatus, oldrecstatus.reactivate) but have kept the
>> JOIN on that table.
>
> In my experience, there should be no speed difference if all you did was
> remove two fields from the SELECT part of the statement. It's usually
> necessary to remove a JOIN or sub-select.
>
> The other two things that can have a huge effect on speed are missing
> indices on JOINed fields and different character collations (latin1 vs.
> UTF-8, for instance) on fields being compared or JOINed.
>
> I just ran this on my machine, with the parts you removed, and it took
> 746 mS to return 9400 rows.
>
> Perhaps if you give me the output of EXPLAIN for this statement,
> something will jump out. Search and replace "sched_temp_record" with
> "record" for this to work. A few indices I found that may help are:
>
> ALTER TABLE `cardinput` ADD INDEX ( `sourceid` );
> ALTER TABLE `cardinput` ADD INDEX ( `cardid` );
> ALTER TABLE `channel` ADD INDEX ( `sourceid` );
>
> One other thing: Where is your "tmpdir", as set in /etc/my.cnf? This
> query operates on a temporary table which can be quite large, and uses
> another temporary table for sorting. If your tmp_table_size is too low
> and you haven't set a tmpdir, then mysql may be writing to a slow (USB,
> perhaps?) disk.


My tmpdir is on the same disk as the tables (tmpdir = /tmp)

The explain is below:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE capturecard ALL PRIMARY NULL NULL NULL 3 Using temporary; Using filesort
1 SIMPLE cardinput ALL NULL NULL NULL NULL 4 Using where; Using join buffer
1 SIMPLE recordmatch ALL recordid NULL NULL NULL 456 Using join buffer
1 SIMPLE sched_temp_record eq_ref PRIMARY PRIMARY 4 myth-test.recordmatch.recordid 1
1 SIMPLE channel eq_ref PRIMARY,sourceid PRIMARY 4 myth-test.recordmatch.chanid 1 Using where
1 SIMPLE program eq_ref PRIMARY,id_start_end,program_manualid,starttime PRIMARY 16
myth-test.recordmatch.chanid,myth-test.recordmatch.starttime,myth-test.recordmatch.manualid 1
1 SIMPLE oldrecstatus ALL NULL NULL NULL NULL 4224



Below are the two queries I used, it might be that I'm overseeing something, to run them I copied the record table to
sched_tmp_record. I though maybe the two missing fields made the query to big for memory but removing other fields don't have
the same result. Am I missing something here, can you see another difference? I ran both queries multiple times, yesterday
and today and always the same result?


SELECT SQL_NO_CACHE DISTINCT channel.chanid, channel.sourceid, program.starttime, program.endtime, program.title,
program.subtitle, program.description, channel.channum, channel.callsign, channel.name, oldrecduplicate, program.category,
sched_temp_record.recpriority, sched_temp_record.dupin, recduplicate, findduplicate, sched_temp_record.type,
sched_temp_record.recordid, program.starttime - INTERVAL sched_temp_record.startoffset
MINUTE AS recstartts, program.endtime + INTERVAL sched_temp_record.endoffset
MINUTE AS recendts, program.previouslyshown, sched_temp_record.recgroup, sched_temp_record.dupmethod, channel.commmethod,
capturecard.cardid, cardinput.cardinputid, UPPER( cardinput.shareable ) = 'Y' AS shareable, program.seriesid,
program.programid, program.category_type, program.airdate, program.stars, program.originalairdate,
sched_temp_record.inactive, sched_temp_record.parentid, (

CASE sched_temp_record.type
WHEN 6
THEN sched_temp_record.findid
WHEN 9
THEN to_days( date_sub( program.starttime, INTERVAL time_format( sched_temp_record.findtime, '%H:%i' )
HOUR_MINUTE ) )
WHEN 10
THEN floor( (
to_days( date_sub( program.starttime, INTERVAL time_format( sched_temp_record.findtime, '%H:%i' )
HOUR_MINUTE ) ) - sched_temp_record.findday ) /7
) *7 + sched_temp_record.findday
WHEN 7
THEN sched_temp_record.findid
ELSE 0
END
), sched_temp_record.playgroup, program.videoprop +0, program.subtitletypes +0, program.audioprop +0,
sched_temp_record.storagegroup, capturecard.hostname, recordmatch.oldrecstatus, sched_temp_record.avg_delay,
channel.recpriority + cardinput.recpriority + ( cardinput.cardinputid = sched_temp_record.prefinput ) *2 AS powerpriority
FROM recordmatch
INNER JOIN sched_temp_record ON ( recordmatch.recordid = sched_temp_record.recordid )
INNER JOIN program ON ( recordmatch.chanid = program.chanid
AND recordmatch.starttime = program.starttime
AND recordmatch.manualid = program.manualid )
INNER JOIN channel ON ( channel.chanid = program.chanid )
INNER JOIN cardinput ON ( channel.sourceid = cardinput.sourceid )
INNER JOIN capturecard ON ( capturecard.cardid = cardinput.cardid )
LEFT JOIN oldrecorded AS oldrecstatus ON ( oldrecstatus.station = channel.callsign
AND oldrecstatus.starttime = program.starttime
AND oldrecstatus.title = program.title )
ORDER BY sched_temp_record.recordid DESC
608 rows in set (2.89 sec)

SELECT SQL_NO_CACHE DISTINCT channel.chanid, channel.sourceid, program.starttime, program.endtime, program.title,
program.subtitle, program.description, channel.channum, channel.callsign, channel.name, oldrecduplicate, program.category,
sched_temp_record.recpriority, sched_temp_record.dupin, recduplicate, findduplicate, sched_temp_record.type,
sched_temp_record.recordid, program.starttime - INTERVAL sched_temp_record.startoffset
MINUTE AS recstartts, program.endtime + INTERVAL sched_temp_record.endoffset
MINUTE AS recendts, program.previouslyshown, sched_temp_record.recgroup, sched_temp_record.dupmethod, channel.commmethod,
capturecard.cardid, cardinput.cardinputid, UPPER( cardinput.shareable ) = 'Y' AS shareable, program.seriesid,
program.programid, program.category_type, program.airdate, program.stars, program.originalairdate,
sched_temp_record.inactive, sched_temp_record.parentid, (

CASE sched_temp_record.type
WHEN 6
THEN sched_temp_record.findid
WHEN 9
THEN to_days( date_sub( program.starttime, INTERVAL time_format( sched_temp_record.findtime, '%H:%i' )
HOUR_MINUTE ) )
WHEN 10
THEN floor( (
to_days( date_sub( program.starttime, INTERVAL time_format( sched_temp_record.findtime, '%H:%i' )
HOUR_MINUTE ) ) - sched_temp_record.findday ) /7
) *7 + sched_temp_record.findday
WHEN 7
THEN sched_temp_record.findid
ELSE 0
END
), sched_temp_record.playgroup, oldrecstatus.recstatus, oldrecstatus.reactivate, program.videoprop +0, program.subtitletypes
+0, program.audioprop +0, sched_temp_record.storagegroup, capturecard.hostname, recordmatch.oldrecstatus,
sched_temp_record.avg_delay, channel.recpriority + cardinput.recpriority + ( cardinput.cardinputid =
sched_temp_record.prefinput ) *2 AS powerpriority
FROM recordmatch
INNER JOIN sched_temp_record ON ( recordmatch.recordid = sched_temp_record.recordid )
INNER JOIN program ON ( recordmatch.chanid = program.chanid
AND recordmatch.starttime = program.starttime
AND recordmatch.manualid = program.manualid )
INNER JOIN channel ON ( channel.chanid = program.chanid )
INNER JOIN cardinput ON ( channel.sourceid = cardinput.sourceid )
INNER JOIN capturecard ON ( capturecard.cardid = cardinput.cardid )
LEFT JOIN oldrecorded AS oldrecstatus ON ( oldrecstatus.station = channel.callsign
AND oldrecstatus.starttime = program.starttime
AND oldrecstatus.title = program.title )
ORDER BY sched_temp_record.recordid DESC
608 rows in set (16.19 sec)



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


pijnacker at dse

Nov 20, 2009, 6:00 AM

Post #7 of 14 (939 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

Hi Mike,

>> My primary frontend is very slow since a while.
>> Deleting recordings etc. is taking seconds, which is very annoying.
>> I noticed that mysql is at 100% cpu on the backend.
>> Could it be that over the years mythconverg has become so big that
>> this is the cause of the issue?
>>
>> If so, which tables can I safely purge?
>
> No, MythTV cleans up the data in the mythconverg database--and besides,
> myth doesn't use that much data, so even if stuff wasn't being cleaned up,
> it wouldn't get that large.
>
> Something else is going on.
>
> I have a clean mythconverg database and get:
>
> # du -sh /srv/mysql/mythconverg/
> 448M /srv/mysql/mythconverg/
>
> (that's 448MiB). That's not very big from a MySQL standpoint but is
> probably rather large from a mythconverg standpoint. My performance is
> fine, though.
>
> I'd guess it's more likely schema corruption (i.e. missing/broken indices,
> etc.--and, yes, I saw that you said in IRC it's not crashed tables, but I
> mean broken schema) or something.
>
> If you'd like to get Myth to recreate your schema (and all indices, etc.)
> see http://www.mythtv.org/wiki/Database_Backup_and_Restore and:
> a) Back up your DB
> b) Drop your DB
> c) Create a new DB with mc.sql
> d) Create a new DB schema by running and exiting mythtv-setup
> e) Do a partial restore (
> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
> )
> f) Run mythtv-setup to reconfigure mythbackend
> g) Start mythbackend
> h) Run mythfrontend and reconfigure mythfrontend and all your plugins

Since the wiki page discourages partial restores and I wasn't in the mood
to reconfigure my systems, I tried just doing a backup/restore.
I compared the first backup with a second (after restore) with identical results.
But still somehow this managed to make the problem go away!

Thanks,

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


mtdean at thirdcontact

Nov 20, 2009, 6:43 AM

Post #8 of 14 (926 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On 11/20/2009 09:00 AM, Ronald Pijnacker wrote:
>>> My primary frontend is very slow since a while.
>>> Deleting recordings etc. is taking seconds, which is very annoying.
>>> I noticed that mysql is at 100% cpu on the backend.
>>> Could it be that over the years mythconverg has become so big that
>>> this is the cause of the issue?
>>>
>>> If so, which tables can I safely purge?
>>>
>> I'd guess it's more likely schema corruption (i.e. missing/broken indices,
>> etc.--and, yes, I saw that you said in IRC it's not crashed tables, but I
>> mean broken schema) or something.
>>
>> If you'd like to get Myth to recreate your schema (and all indices, etc.)
>> see http://www.mythtv.org/wiki/Database_Backup_and_Restore and:
>> a) Back up your DB
>> b) Drop your DB
>> c) Create a new DB with mc.sql
>> d) Create a new DB schema by running and exiting mythtv-setup
>> e) Do a partial restore (
>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
>> )
>> f) Run mythtv-setup to reconfigure mythbackend
>> g) Start mythbackend
>> h) Run mythfrontend and reconfigure mythfrontend and all your plugins
>>
> Since the wiki page discourages partial restores and I wasn't in the mood
> to reconfigure my systems,

FWIW, fixing a corrupt DB schema is the one good reason to do a partial
restore.

Anyway, it may have just been a problem with your index files or something.

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


mtdean at thirdcontact

Nov 20, 2009, 6:48 AM

Post #9 of 14 (923 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On 11/19/2009 04:59 PM, GXL.nl wrote:
> Below are the two queries I used, it might be that I'm overseeing
> something, to run them I copied the record table to sched_tmp_record.
> I though maybe the two missing fields made the query to big for memory
> but removing other fields don't have the same result. Am I missing
> something here, can you see another difference? I ran both queries
> multiple times, yesterday and today and always the same result?

Could you try doing a full SQL-based backup (
http://www.mythtv.org/wiki/Database_Backup_and_Restore ), then dropping
your database and creating a new database (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Database_Restore
), then doing a full restore of the backup (
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Full_restore_of_a_specific_backup_file
)?

If that doesn't help, try
http://www.gossamer-threads.com/lists/mythtv/users/409050#409050 .

Mike


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


myth at robinhill

Nov 20, 2009, 6:55 AM

Post #10 of 14 (926 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On Fri Nov 20, 2009 at 03:00:16PM +0100, Ronald Pijnacker wrote:

> Since the wiki page discourages partial restores and I wasn't in the mood
> to reconfigure my systems, I tried just doing a backup/restore.
> I compared the first backup with a second (after restore) with identical results.
> But still somehow this managed to make the problem go away!
>
Are you running the optimize_mythdb.pl script on a regular basis? If
not, the backup/restore would have done many of the same
cleanups/optimisations as this script.

Cheers,
Robin
--
___
( ' } | Robin Hill <myth [at] robinhill> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |


mythtv-users2 at dwilga-linux1

Nov 20, 2009, 7:21 AM

Post #11 of 14 (932 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

At 10:59 PM +0100 11/19/09, GXL.nl wrote:
>The explain is below:
>id select_type table type possible_keys key
> key_len ref rows Extra
>1 SIMPLE capturecard ALL PRIMARY NULL NULL NULL
> 3 Using temporary; Using filesort
>1 SIMPLE cardinput ALL NULL NULL NULL NULL
> 4 Using where; Using join buffer
>1 SIMPLE recordmatch ALL recordid NULL NULL
> NULL 456 Using join buffer
>1 SIMPLE sched_temp_record eq_ref PRIMARY PRIMARY 4
> myth-test.recordmatch.recordid 1
>1 SIMPLE channel eq_ref PRIMARY,sourceid PRIMARY 4
> myth-test.recordmatch.chanid 1 Using where
>1 SIMPLE program eq_ref
> PRIMARY,id_start_end,program_manualid,starttime PRIMARY 16
>myth-test.recordmatch.chanid,myth-test.recordmatch.starttime,myth-test.recordmatch.manualid
> 1
>1 SIMPLE oldrecstatus ALL NULL NULL NULL NULL 4224

You've got a few NULLs in the "key" column which suggest possible
inefficiencies due to missing indices. For starters, it definitely
looks like you are missing indices on the oldrecorded (aliased as
oldrecstatus) table. Here's what the schema says there should be:

ALTER TABLE oldrecorded ADD PRIMARY KEY (station,starttime,title);
ALTER TABLE oldrecorded ADD KEY endtime (endtime);
ALTER TABLE oldrecorded ADD KEY title (title);
ALTER TABLE oldrecorded ADD KEY seriesid (seriesid);
ALTER TABLE oldrecorded ADD KEY programid (programid);
ALTER TABLE oldrecorded ADD KEY recordid (recordid);
ALTER TABLE oldrecorded ADD KEY recstatus (recstatus,programid,seriesid);
ALTER TABLE oldrecorded ADD KEY recstatus_2 (recstatus,title,subtitle);

You should be able to apply these to the table, and any that already
exist will just produce an error message (duplicate key). I suggest
you make a backup of the table first, though.

Assuming there were some missing indices, try re-running the explain.
You can just replace everything between DISTINCT and FROM with
"DISTINCT channel.chanid FROM", to make the query easier to
understand; explain doesn't care about the other columns, in this
case.

Here's what the same explain looks like on my DB (hope the wrapping
is preserved):

+----+-------------+--------------+--------+-------------------------------------------------+----------+---------+---------------------------------------------------------------------------------------------------------------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys
| key | key_len | ref
| rows | Extra |
+----+-------------+--------------+--------+-------------------------------------------------+----------+---------+---------------------------------------------------------------------------------------------------------------+------+----------------------------------------------+
| 1 | SIMPLE | record | index | PRIMARY
| PRIMARY | 4 | NULL
| 106 | Using index; Using temporary; Using filesort |
| 1 | SIMPLE | recordmatch | ref | recordid
| recordid | 5 | mythconverg_022.record.recordid
| 7 | Using where |
| 1 | SIMPLE | channel | eq_ref |
PRIMARY,sourceid,sourceid_2 | PRIMARY | 4
| mythconverg_022.recordmatch.chanid
| 1 | |
| 1 | SIMPLE | cardinput | ALL | sourceid,cardid
| NULL | NULL | NULL
| 9 | Using where; Distinct; Using join buffer |
| 1 | SIMPLE | capturecard | eq_ref | PRIMARY
| PRIMARY | 4 | mythconverg_022.cardinput.cardid
| 1 | Using index; Distinct |
| 1 | SIMPLE | program | eq_ref |
PRIMARY,id_start_end,program_manualid,starttime | PRIMARY | 16
|
mythconverg_022.recordmatch.chanid,mythconverg_022.recordmatch.starttime,mythconverg_022.recordmatch.manualid
| 1 | Distinct |
| 1 | SIMPLE | oldrecstatus | eq_ref | PRIMARY,title
| PRIMARY | 456 |
mythconverg_022.channel.callsign,mythconverg_022.recordmatch.starttime,mythconverg_022.program.title
| 1 | Using index; Distinct |
+----+-------------+--------------+--------+-------------------------------------------------+----------+---------+---------------------------------------------------------------------------------------------------------------+------+----------------------------------------------+
--
Dan Wilga "Ook."
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Nov 20, 2009, 7:43 AM

Post #12 of 14 (924 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On 11/20/2009 10:21 AM, Dan Wilga wrote:
> You've got a few NULLs in the "key" column which suggest possible
> inefficiencies due to missing indices. For starters, it definitely
> looks like you are missing indices on the oldrecorded (aliased as
> oldrecstatus) table. Here's what the schema says there should be:
>
> ALTER TABLE oldrecorded ADD PRIMARY KEY (station,starttime,title);
> ALTER TABLE oldrecorded ADD KEY endtime (endtime);
> ALTER TABLE oldrecorded ADD KEY title (title);
> ALTER TABLE oldrecorded ADD KEY seriesid (seriesid);
> ALTER TABLE oldrecorded ADD KEY programid (programid);
> ALTER TABLE oldrecorded ADD KEY recordid (recordid);
> ALTER TABLE oldrecorded ADD KEY recstatus
> (recstatus,programid,seriesid);
> ALTER TABLE oldrecorded ADD KEY recstatus_2 (recstatus,title,subtitle);

He posted his indices to another message (
http://www.gossamer-threads.com/lists/mythtv/users/409074#409074 ).
None are missing.

And please, do not edit the database schema.

The best approach, now, would be to do the backup/restore I outlined in
another message. (
http://mythtv.org/pipermail/mythtv-users/2009-November/271541.html )

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


pijnacker at dse

Nov 21, 2009, 2:42 PM

Post #13 of 14 (855 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

> On Fri Nov 20, 2009 at 03:00:16PM +0100, Ronald Pijnacker wrote:
>
> > Since the wiki page discourages partial restores and I wasn't in the mood
> > to reconfigure my systems, I tried just doing a backup/restore.
> > I compared the first backup with a second (after restore) with identical results.
> > But still somehow this managed to make the problem go away!
> >
> Are you running the optimize_mythdb.pl script on a regular basis? If
> not, the backup/restore would have done many of the same
> cleanups/optimisations as this script.

No, I not doing this. However would you expect that the output of the database-backup
script would be identical before and after restoring it?
I'm not that knowledgable about databases, but I would think that with the same (exactly)
output there would be no difference...

Ronald

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


mtdean at thirdcontact

Nov 21, 2009, 6:25 PM

Post #14 of 14 (843 views)
Permalink
Re: Very slow mythfrontend, mysql at 100% [In reply to]

On 11/21/2009 05:42 PM, Ronald Pijnacker wrote:
>> On Fri Nov 20, 2009 at 03:00:16PM +0100, Ronald Pijnacker wrote:
>>
>>> Since the wiki page discourages partial restores and I wasn't in the mood
>>> to reconfigure my systems, I tried just doing a backup/restore.
>>> I compared the first backup with a second (after restore) with identical results.
>>> But still somehow this managed to make the problem go away!
>>>
>> Are you running the optimize_mythdb.pl script on a regular basis? If
>> not, the backup/restore would have done many of the same
>> cleanups/optimisations as this script.
>>
>
> No, I not doing this. However would you expect that the output of the database-backup
> script would be identical before and after restoring it?
> I'm not that knowledgable about databases, but I would think that with the same (exactly)
> output there would be no difference...

The optimize_mythdb.pl script doesn't fix or even change data. All
that's in a backup is data. So the backups should look the same
before/after.

The optimize_mythdb.pl script tells the DB to repair crashed tables, fix
up/update indices, and compress the on-disc storage area allocated for
the database.

Similarly, dropping the DB and restoring a backup will re-create indices
(which means they're all fixed up and updated) and will write the data
without any space/garbage in the middle, so...

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