[mythtv-users] Slow MySQL query after delete
f-myth-users at media.mit.edu
f-myth-users at media.mit.edu
Fri Nov 30 09:35:52 UTC 2007
> Date: Thu, 29 Nov 2007 19:41:11 -0500
> From: "Michael T. Dean" <mtdean at thirdcontact.com>
> Do you have your MySQL database on the same drive as your recording
> disk?
I'm going to jump in here and say that -my- DB isn't on the same
spindle and -I- still see terrible performance, even after doing ALL
of the frequently-recommended performance "improvement" tasks. Go
back and look at all those threads I posted in talking about corrupted
recordings (eventually fixed by not hanging the writing thread on DB)
and see the enormous litany: different spindle, huge memory, screwing
around w/IO scheduling algorithms, constant DB optimization, yadda
yadda yadda.
-My- terrible performance is on BOTH deletions AND simple reschedules.
Even though I have fairly few (less than a dozen?) any-channel rules.
But I do have a lot of rules and a large oldrecorded, and that's what
Myth is -supposed- to be able to handle.
It's certainly -possible- that deletions are even slower than
reschedules because of recordedseek (I haven't checked), but the
resched is the lion's share, as is trivially discoverable from the
logs saying "Scheduled n items in m = q match + r place" where m
and r are huge (e.g,. 60 seconds).
(Assuming you're wrong about XFS deletes -themselves- being slow, the
easy way to check, of course, is to simply do a delete from recordedseek
that deletes a few thousand records, and time it. That's two lines of
SQL: One to clone all the records from a recording to one w/a different
starttime, and the second to delete all matching starttimes.)
> If so, that's the first thing you should consider fixing. I
> don't think it's the "slow" MySQL query causing your problem (especially
> since it's running in almost exactly the same time as mine does and I
> don't notice /any/ issue when deleting recordings). I really think it's
> a file system thing--i.e. disk thrashing as XFS tries to delete the
> recording at full speed
This sounds -extremely- unlikely. Certainly JFS never takes more than
milliseconds, and XFS doesn't, either, if I can believe the benchmarks.
Easy way to test: Before deleting a recording, delete (or rename) the
actual video file, then touch the same filename to create a zero-length
one. THEN delete and see if the filesystem is involved at all.
> and MySQL on the same disk tries to delete the
> recordedseek entries for the recording (i.e. finding 7200 needles (per
> hour of recording you're deleting) in a 1.1M straw haystack).
If this is truly the problem, then either Myth or MySQL is horribly
misdesigned. Are you actually saying that this database can't delete
a few thousand items in less than 10 seconds or so?
How about indexing recordedseek better? Maybe not using strings?
Maybe giving each recording its OWN table (e.g., recordedseek-chanid-starttime)
so a deletion is as simple as DROP TABLE RECORDEDSEEK-chanid-starttime?
Of course, all of these would have to be benchmarked.
More information about the mythtv-users
mailing list