Description of problem: Currently when scheduling, engine use to fetch all VDS (host) objects by cluster. According to profiling tests conducted lately on scheduling process in engine, this query is very time consuming. We should think of making this query more light-weighted, and even reduce the times we call it (maybe to aggregate calls to it while validating).
Barak, what's the plan to handle it?
Please specify: - what exact query are we talking about - what flow? any run VM will reflect this issue ?
(In reply to Barak from comment #3) > Please specify: > - what exact query are we talking about > - what flow? any run VM will reflect this issue ? The query was getVdsForVdsGroupWithStatus, but according to latest testing (bug 1149701) the query is okay. I think we should invest time to understand what happens in large scale.
(In reply to Gilad Chaplik from comment #4) > (In reply to Barak from comment #3) > > Please specify: > > - what exact query are we talking about > > - what flow? any run VM will reflect this issue ? > > The query was getVdsForVdsGroupWithStatus, but according to latest testing > (bug 1149701) the query is okay. > > I think we should invest time to understand what happens in large scale. We investigate what happens in large scales all the time. I'm afraid that if I don't get a real substance for this bug than I'll close it. Unless you come up with a specific problem. Anyway added needinfo on Liran (to keep him in the loop) And leaving needinfo on you to supply the info. If nothing comes up this bug will be closed
We'll revisit it for 3.6, as we're out of capacity for 3.5 cycle.
Eldad, have you seen this query slow-performing? if not then we can close this.
No at all, but there is a open defect for scheduling already see: https://bugzilla.redhat.com/show_bug.cgi?id=1149701
per comments #7 & #8 closing this bug INSUFFICIENT_DATA. If you have a clearer scenario please reopen this bug - or a different more specific bug.