cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharat Kumar <>
Subject Re: Incorrect Memory Usage in Dashboard When Overprovisoined
Date Fri, 17 Apr 2015 05:35:35 GMT
Hi ,

This doc should make the memory calculations clear to you.


On 16-Apr-2015, at 3:24 pm, 蔡高扬 <<>>

      When I changed the value of “mem.overprovisioning.factor” in a cluster, i.e. from
1 to 2, the used memory value in dashboard also changed (in this example, doubled) as well
as total momory. After I shut down VMs in the cluster and start them, memory usage became

      I found the code calculating the used momory but couldn’t understand the way to calculating
and updating this value.

usedMemory += ((so.getRamSize() * 1024L * 1024L)/ramOvercommitRatio)*clusterRamOvercommitRatio;

      In the code above, clusterRamOvercommitRatio updates instantly after overprovisioning
factor sets, but ramOvercommitRatio only updates according to clusterRamOvercommitRatio when
VM starts. This leads to inconsistency between the two variables.
      So my question is:

1.      Why calculating usedMemory in such way (devided by ramOvercommitRatio and then multiplied

2.      Why NOT updating ramOvercommitRatio when overprovisioning factor changes, until when
VM starts?

3.      How to fix incorrect memory usage without restarting VMs ?


Kelvin Cai,
Ping An Technology (Shenzhen) Co., Ltd. | Infrastructure.

The information in this email is confidential and may be legally privileged. If you have received
this email in error or are not the intended recipient, please immediately notify the sender
and delete this message from your computer. Any use, distribution, or copying of this email
other than by the intended recipient is strictly prohibited. All messages sent to and from
us may be monitored to ensure compliance with internal policies and to protect our business.
Emails are not secure and cannot be guaranteed to be error free as they can be intercepted,
amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is
taken to accept these risks.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message