Timeline for Deadlocked queries cause an instant error for end-users, but are retried in other circumstances
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 14, 2018 at 19:13 | comment | added | Andrew West | oops sorry - missed this. Email me at [email protected] and I'll send it over (just because it's not easy to put code in these comments) | |
| Sep 4, 2018 at 10:06 | comment | added | Richard van Oosterhout | nice! would it be possible you can show me the code you inserted for that? | |
| Sep 3, 2018 at 9:22 | comment | added | Andrew West | @RichardvanOosterhout we used a combination of two things. First we use New Relic monitoring, which lets us drill down into slow queries. Secondly I added basic time logging to Contact/BAO/GroupContactCache::load() - basically just starting a timer at the start of the function, stopping it at the end, and logging it along with the group ID. Quite revealing! | |
| Aug 31, 2018 at 7:18 | comment | added | Richard van Oosterhout | I would be interested in how you analyzed the slowest smartgroups. We also experience deadlock problems with too many and too complex smartgroups | |
| Aug 28, 2018 at 20:00 | comment | added | Andrew West | We've done this to an extent, but we're heavy users of smart groups (well over 1000) and the staff make new ones every day. They would be quite confused / annoyed if their groups didn't update right away. We did some analysis of the most time consuming groups - as well as the 'base' groups that many others rely on - and turned these into regular groups that populate overnight. This helped a lot. To be honest I'm quite happy with the setup as it is: the deadlocks get caught and retried, and very rarely fail. It's just the UI deadlocks that are a difficulty. | |
| Aug 28, 2018 at 14:04 | history | answered | Xavier | CC BY-SA 4.0 |