Roy Golan has posted comments on this change.
Change subject: core: throttle running of VMs (#843058)
......................................................................
Patch Set 1: (4 inline comments)
....................................................
File
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommandBase.java
Line 430:
Line 431: decreaseLock.lock();
Line 432: try {
Line 433: // wait for the run-time refresh to decrease any current
powering-up VMs
Line 434: decreased.await(Config.<Integer>
GetValue(ConfigValues.VdsRefreshRate), TimeUnit.SECONDS);
I think that instead of using the refreshRate maybe I should use the elapsed
time it took for the VdsUpdate to run. on a large scale system the VdsUpdate
can take a more time to run so even though the refresh rate is 2 seconds the
whole cycle can take 10. if the update is very fast i.e < VdsRefreshRate then
we can use the higher
between the two But to have a configurable limit
so the await can be:
long vdsUpdateElapsed // will expse a method for that
long vdsRefreshRate // config value
long maxWait // new config value
long await
await = vdsRefreshRate > vdsUpdateElapsed ? vdsRefreshRate : vdsUpdateElapsed
await = await > maxWait ? maxWait : await
Line 435: } catch (InterruptedException e) {
Line 436: // ignore
Line 437: } finally {
Line 438: decreaseLock.unlock();
....................................................
Commit Message
Line 7: core: throttle running of VMs (#843058)
Line 8:
Line 9: https://bugzilla.redhat.com/show_bug.cgi?id=843058
Line 10:
Line 11: Bulk running of VMs reguallary fail short in running all VMs. The
reason is
Done
Line 12: The VdsSelector counts and reserve memory using
Line 13: a) host commited memory: # of VMs * each VM static mem
Line 14: b) pending VM count memory : # of VMs to run * thier memory count - a
shared state variable
Line 15:
Line 13: a) host commited memory: # of VMs * each VM static mem
Line 14: b) pending VM count memory : # of VMs to run * thier memory count - a
shared state variable
Line 15:
Line 16: pending VM count is increased by the end of RUnVm and decreased by
VdsUpdateRunTimeInfo
Line 17: i.e two independent proccesses.
Done
Line 18:
Line 19: As long as the VdsUpdateRunTimeInfo don't run, theres an overflow in
the calculation
Line 20: of the free memory to run VM which causes a host to be falsely not
selected to run the VM.
Line 21:
Line 27:
Line 28: setup: Host with 8Gb mem, 3.0 pool, cluster, 10Vms
Line 29: 2 Host with 4Gb mem, 3.1 pool, cluster 5VMs
Line 30:
Line 31: muliple run 10 VMs - prior to the fix the 9th and 10th can locate a
host to run on
Done
Line 32: after the fix all 10 VMs complete the run. In the 9th VM run the
selector waits for the update to decrease memory
Line 33: and continue after less than a second.
Line 34:
Line 35: migrate VMs back and forth of 5Vms with no issues.
--
To view, visit http://gerrit.ovirt.org/7204
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I076ede6cba919bc61f7546d7b29ef436eb6d3375
Gerrit-PatchSet: 1
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Roy Golan <rgo...@redhat.com>
Gerrit-Reviewer: Allon Mureinik <amure...@redhat.com>
Gerrit-Reviewer: Moti Asayag <masa...@redhat.com>
Gerrit-Reviewer: Omer Frenkel <ofren...@redhat.com>
Gerrit-Reviewer: Roy Golan <rgo...@redhat.com>
Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com>
Gerrit-Reviewer: oVirt Jenkins CI Server
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
