[mythtv-users] Slow MySQL query after delete
Boleslaw Ciesielski
bolek-mythtv at curl.com
Wed Dec 5 14:33:29 UTC 2007
Michael T. Dean wrote:
> However, when deleting multiple recordings at once, the deletions occur
> sequentially, so when slow deletes are enabled, the first delete request
> is made, data is removed from the DB, a reschedule is requested, then
> the 1GB/2min10sec deletion occurs. If, during that deletion process,
> another recording is deleted, the DB data deletion and reschedule waith
> until the first recording is gone. When the first file's deletion
> completes, the backend waits another 3 seconds for the frontend to catch
> up (though by now it surely already has), then removes data from the DB,
> reschedules, and begins the deletion process. Any additional deletion
> requests wait in the queue for their turn to remove DB data, reschedule,
> then delete.
Are you sure about this part? Delete from DB has it's own separate lock
from the truncate lock. From MainServer::DoDeleteThread():
deletelock.lock();
[...]
DoDeleteInDB(ds);
if (pginfo->recgroup != "LiveTV")
ScheduledRecording::signalChange(0);
deletelock.unlock();
if (slowDeletes && fd != -1)
TruncateAndClose(pginfo, fd, ds->filename, size);
So all the deletes from DB (and unlinks) happen right away and only the
slow truncates are delayed, no?
Bolek
More information about the mythtv-users
mailing list