abh1sar commented on code in PR #12403:
URL: https://github.com/apache/cloudstack/pull/12403#discussion_r2704423617
##########
server/src/main/java/com/cloud/capacity/CapacityManagerImpl.java:
##########
@@ -704,22 +704,16 @@ public void updateCapacityForHost(final Host host) {
so =
_offeringsDao.findByIdIncludingRemoved(vm.getServiceOfferingId());
}
if (so.isDynamic()) {
- usedMemory +=
-
((Integer.parseInt(vmDetails.get(UsageEventVO.DynamicParameters.memory.name()))
* 1024L * 1024L) / ramOvercommitRatio) *
- clusterRamOvercommitRatio;
+ usedMemory +=
Integer.parseInt(vmDetails.get(UsageEventVO.DynamicParameters.memory.name())) *
1024L * 1024L;
Review Comment:
There seems to be some intentional logic behind the old code:
`ramOvercommitRatio` is saved in VM settings (which is set equal to the
clusterOvercommitRatio whenever the VM is started)
`clusterRamOvercommitRatio` is the current ratio set on the cluster.
The idea behind the old code seems to be that for running VMs the used stats
are kept at the same ratio to the total capacity.
For example, let's say total capacity is 64G and a VM is using 32G (Half of
the total capacity)
Now, the `clusterOvercommitRatio` is changed from 1 to 2.
The VM's used will change to 64G (32/1 * 2). This means the running VM is
still using half of the total capacity of the host.
The logic seems to be a safeguard against a running VM not getting affected
by sudden capacity jumps using the overCommit ratio of the cluster.
Think of a little extreme case when clusterOvercommitRatio is changed from 1
to 5. Without this change, it is bound to affect the running VM which might not
be intended.
When the VM restarts, its `ramOvercommitRatio` will change to 2. The VM used
will then become 32G (32/2 * 2).
Basically the logic seems to be that running VMs should not be affected by
sudden jumps in the clusterOvercommitRatio.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
