> On Apr 30, 2015, at 2:30 AM, Thomas Raschbacher <lord...@lordvan.com> wrote: > > Am 29.04.2015 um 17:36 schrieb Mark Maurer: >> apologies, I forgot to add this originally. In addendum to below: >> >> while this occurs, I’m seeing this in the logs from dbmail: >> >> Apr 29 15:26:31 mail dbmail/imap4d[4621]: Error:[db] db_exec(+388): >> SQLException: Lock wait timeout exceeded; try restarting transaction >> Apr 29 15:26:31 mail last message repeated 2 times >> Apr 29 15:26:31 mail dbmail/imap4d[4621]: Error:[db] db_exec(+389): failed >> query [UPDATE dbmail_messages SET status=2 WHERE message_idnr=24497739 ] >> Apr 29 15:26:31 mail dbmail/imap4d[4621]: Error:[db] db_exec(+389): failed >> query [UPDATE dbmail_messages SET status=2 WHERE message_idnr=24497733 ] >> Apr 29 15:26:31 mail dbmail/imap4d[4621]: Error:[db] db_exec(+389): failed >> query [UPDATE dbmail_messages SET status=2 WHERE message_idnr=24497745 ] >> Apr 29 15:26:32 mail dbmail/imap4d[4621]: Error:[db] db_exec(+388): >> SQLException: Lock wait timeout exceeded; try restarting transaction >> Apr 29 15:26:32 mail last message repeated 2 times >> Apr 29 15:26:32 mail dbmail/imap4d[4621]: Error:[db] db_exec(+389): failed >> query [UPDATE dbmail_messages SET status=2 WHERE message_idnr=24497735 ] >> Apr 29 15:26:32 mail dbmail/imap4d[4621]: Error:[db] db_exec(+389): failed >> query [UPDATE dbmail_messages SET status=2 WHERE message_idnr=24497747 ] >> Apr 29 15:26:32 mail dbmail/imap4d[4621]: Error:[db] db_exec(+389): failed >> query [UPDATE dbmail_messages SET status=2 WHERE message_idnr=24497741 ] >> > > Hi > > Did you try running one/some of those queries manually? > If so what was the result? > > Regards
I did indeed. I got the same results of lock contention that was showing up in the processlist. However, I did manage to find the culprit late last night, and am not seeing the issue anymore: I traced all the message id’s back to a single user, who was running thunderbird 31.6.0. They had approximately 33k messages in Trash that they were trying to delete. It was that action that was causing all the lock contention on the dbmail_messages table. The user switched clients, deleted their trash with no issues, and switched back. The issue has not cropped up since, and everything is as fast and stable as can be. Not sure why thunderbird was having such a hard time deleting the trash, but there it is. -- Mark Maurer m...@solinus.com _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
