[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