[mythtv-users] Slow MySQL query after delete
Michael T. Dean
mtdean at thirdcontact.com
Fri Nov 30 00:41:11 UTC 2007
On 11/28/2007 10:10 PM, Larry K wrote:
>>> (Though there's a good chance you /should/ enable slow deletes.)
>> Since the issue here is a slow SQL statement and not a slow file system
>> (mine is xfs and deletes have never been slow), I wonder how this will
>> help? I thought this myth-setup option was to implemented to help overcome
>> slow file system deletes.
>>> Yep. Without changing your MySQL configuration, that's as good as it
>>> will get. I'll leave figuring out how to change your MySQL
>>> configuration--and the consequences of doing so--to you (as really, the
>>> fact that it takes 6-7 seconds to schedule recordings should make no
>>> difference to you).
> If the scheduler is blocking the frontend when it does this 7 second
> operation, it clearly makes a difference
Like I said (and you (?--the "Since the issue" is you, right?) trimmed),
"Though, if you configure Myth appropriately you shouldn't even notice."
> to me.
Which means... :)
> It is very frustrating to
> sit and wait up to 10 seconds after every delete (from either the frontend
> or mythweb).
> I am open to suggestions as to how I can improve this situation.
Do you have your MySQL database on the same drive as your recording
disk? 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 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). I'd bet
the BUSQ (and the reschedule in general) is the least of the concerns if
it truly completes in 6-7 seconds.
More information about the mythtv-users