https://lp-oops.canonical.com/oops.py/?oopsid=1662O772
SQL time: 18142 ms
Non-sql time: 1566 ms
Total time: 19708 ms
Statement Count: 202
url - https://answers.launchpad.net/ubuntu/+question/118287/+edit doing a post to save changes.
one high cost thing we'll want to fix later:
163 705 4 701 session SELECT TeamParticipation.id, TeamParticipation.person, TeamParticipation.team FROM TeamParticipation WHERE TeamParticipation.person = %s AND TeamParticipation.team = %s
thats 163 probably redundant / irrelevant checks.
This is the culprit though:
17002.0 1 launchpad-main-master SELECT PublishedPackage.archive, PublishedPackage.binarypackagedescription, PublishedPackage.binarypackagename, PublishedPackage.binarypackagerelease, PublishedPackage.binarypackagesummary, PublishedPackage.binarypackageversion, PublishedPackage.build, PublishedPackage.component, PublishedPackage.datebuilt, PublishedPackage.distribution, PublishedPackage.distroarchseries, PublishedPackage.distroseries, PublishedPackage.distroseriesname, PublishedPackage.id, PublishedPackage.packagepublishingstatus, PublishedPackage.processorfamily, PublishedPackage.processorfamilyname, PublishedPackage.section, PublishedPackage.sourcepackagename, PublishedPackage.sourcepackagerelease, PublishedPackage.sourcepackagereleaseversion FROM PublishedPackage WHERE PublishedPackage.sourcepackagename = 'grub2' AND PublishedPackage.binarypackagename = 'grub2' AND PublishedPackage.distribution = 1 AND PublishedPackage.archive IN (1, 534) ORDER BY PublishedPackage.id DESC LIMIT 1
I'm going to guess we had contention or a load spike. I wonder if such queries :- querying data not part of the app - should always be coming from a slave?
https:/ /pastebin. canonical. com/34874/
demonstrates the query, which is on a view, going boom inconsistently - and choosing a nuts plan when it goes boom.