@tsteur opened this Issue on March 30th 2020 Member

@diosmosis I don't 100% remember anymore why the ArchivingStatus lock was needed?

However, I see we often get heaps of lock timeouts. And these locks often take a considerable amount of load on our DB servers. Eg
image

Often even more than any other query. Often causing a lot of lock wait timeout, and potentially even deadlocks.

Should this lock really still be needed (looked at code again and wasn't sure where it was actually used).
Maybe in ArchivingDbAdapter it could be a start to not reexpire the lock on every DB query but maybe every 10 minutes or 30 minutes considering the lock is valid for up to 7200s by default?

@diosmosis commented on March 30th 2020 Member

It's needed for #15117 I use it more heavily there. Will look at this soon and coment...

@diosmosis commented on March 30th 2020 Member

I think we could maybe wait up to, say, have timeout value? Ie, if the timeout is 2 hours, then after an hour, we re-expire?

@diosmosis commented on March 30th 2020 Member

Actually, wasn't there a timeout for archiving queries? We could use that, if we're N minutes away from expiring or, less, re-expire the lock.

@tsteur commented on March 30th 2020 Member

Actually, wasn't there a timeout for archiving queries

Not sure what you mean? We have live_query_max_execution_time but this affects only live queries.

Yeah should the TTL be 2 hours, re-expiring say every 30 min be fine (25% of TTL)

This Issue was closed on March 30th 2020
Powered by GitHub Issue Mirror