Description of problem: in 2.4K vms scale engine generate lot of getsnapshotbyleafguid calls. this query running high CPU utlizaion as standalone SQL. engine profile 2.4K vms * 3 disks = ~7K disks. see also https://bugzilla.redhat.com/show_bug.cgi?id=1302752 Version-Release number of selected component (if applicable): 4.0.2-1 How reproducible: 100% Steps to Reproduce: 1. 2.4K vms / ~7K disks Actual results: high CPU utilization on postgres host (90-100%) Expected results: stable CPU utilization & optimized query Additional info:
Eldad, any insight on what called this? I see it in a couple of commands (which makes sense to me), in a query that IIUC is called by some interactive dialogs and during OVF processing. The approach here probably won't be to optimize the query (I doubt there's TOO much we can do there without being too adventurous), but to find the offensive flow and fix it.
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Eldad - having said that (comment 3), I have an idea that may improve the underlying view's performance. While the theory about it seems to be solid, I'm unable to prove it with the limited dataset I have on my env. Could you cherry-pick it to your env, apply the change in the view and report if there's any improvement back here? The patch: https://gerrit.ovirt.org/#/c/62044/
(In reply to Allon Mureinik from comment #5) > Could you cherry-pick it to your env, apply the change in the view and > report if there's any improvement back here? That was misphrased - the patch also adds a couple indexes - if possible, just cherry-pick it and run the database upgrade.
(In reply to Allon Mureinik from comment #6) > (In reply to Allon Mureinik from comment #5) > > Could you cherry-pick it to your env, apply the change in the view and > > report if there's any improvement back here? > That was misphrased - the patch also adds a couple indexes - if possible, > just cherry-pick it and run the database upgrade. verified, let merged it ASAP. query response time ~200ms.
(In reply to Eldad Marciano from comment #7) > (In reply to Allon Mureinik from comment #6) > > (In reply to Allon Mureinik from comment #5) > > > Could you cherry-pick it to your env, apply the change in the view and > > > report if there's any improvement back here? > > That was misphrased - the patch also adds a couple indexes - if possible, > > just cherry-pick it and run the database upgrade. > > verified, let merged it ASAP. > query response time ~200ms. Thanks Eldad! I'm retargetting to 4.0.4