Yes, and the reason is that until you look inside the guest OS to see how its using memory, it's just a guess. So in 6.7 this change means more accurate memory usage numbers because it is looking inside the guest as opposed to just looking from the hypervisor's perspective (which was not very useful).
Unfortunately, I find this change totally bad. Since today's operating systems use RAM for file cache without end, so all VMs in our environment now have 100% RAM Usage. As a result, one can no longer show the difference between real active RAM and the task manager RAM. Especially in the past we were able to find application administrators with errors in applications that do not use the RAM as it is available. As far as performance analysis is concerned, unfortunately, vROps has become a completely useless program. Especially because I can no longer query the active RAM in Metricen.
1 person found this helpful
My experience with this so far (with Windows VMs at-least) is that they missed the mark here. What I am seeing is they are looking at the "Free" memory metric as seen by Windows Task Manager and not the "Available" memory metric.
So a Windows VM that has 4GB RAM shows has having 1.1GB Available; however only 1MB Free. vROps now reports this VM has having no memory free.
I was 100% on-board with this idea but seeing it in-action with using Free and not Available is a big problem.
After upgrading from 6.6 to 6.7, we found that the Memory|Workload (%) metric was reporting abnormally high for almost every VM in our environment. After checking the a few individual VMs, we knew the metric was "wrong".
We replaced the Memory|Workload (%) with Memory|Guest Active Memory (%) as test. The measurement from Memory|Guest Active Memory (%) reported "correctly" (as Memory|Workload (%) used to).
I have always heard that the most important metric about memory, is the " active memory" , because the OS's memory have different algorythm to measure the active memory and how some people said " the OS consume memory in cache" and so on.
I will wait about future release, because this is confuse for us.
There are two trains of thought on this and it is good or bad depending on where you are looking at this from.
Most people will use the active memory when looking to reclaim memory because it makes the story to management believable and easy to have. We all know it is hard to get more hardware so being able to run a report to show your bosses that you can reclaim x TB of memory form VMs because they were never right sized correctly in the first place is the easy conversation.
If you are concerned about the performance of a VM and dont care on capacity then the in-guest stats are king. If you just look at a VM from a pure container using resources POV you dont care about performance.
In reality you need to care about both and you need to know how applications work from not just a capacity perspective but also performance.
Take SQL for example. If you have a DBA that keeps asking for more memory because the VM is running out of memory and crashing and he shows you a perfmon chart with it running at 100% to prove that he needs more he is not a very good DBA for a start he should limit the memory SQL can consume as not to use all the memory and starve windows.
Because SQL and other applications cache to RAM you are now relying on the DBA to know what he is doing and know when he needs more memory due to performance and not the windows perfmon. from a vrops perspective i want it look at the inguest. if the SQL is not using all the memory for cache then it should be reclained. but if it is then it should not.
If you look at a file server then the active and in-guest should be closer.
Do you want vrops to be more accurate and protect you better from resizing a VM to small because it was looking at active but now in-guest or would you rather it be more inaccurate but give you better looking numbers to go back to you bosses with but could cause performance problems
Can someone please advise how to enable the Memory|Guest Active Memory (%) metric? I do not see it even as an available metric to choose from. Thanks!
That did the trick for me. Thank you
I also think the big problem here is that cached memory is seen as used memory. There should be two different counters (used and cached) and maybe one summed up (used+cached).
The calculations should be definitely be derived from used memory without cached!
Iwan Rahabok: Maybe this is something you can internally prioritize inside the vROPS dev team.
I'm with the "this is broken" crowd. Maybe it works ok in "not windows" but since we have a high proportion of Windows guests, it breaks many metrics.
- All of the canned sizing metrics are useless now
- Memory monitoring is basically non-functional. We noticed that all of our SAP app servers are now complaining about high memory utilization and their heatmap is shades of crimson. The date chart is all red now where you used to be able to see exactly when most people got into the office based on the application server's graph, for example.
- Troubleshooting basically has to ignore memory now, because it's always high.
It's all fine and dandy if they change the metric calculation, but it shouldn't break a good portion of the "out of the box" functionality. At this point, it's a bug, whether it's an implementation bug or a design bug, but the service is not working like it's described "on the box."
Has anyone raised this with VMware?
Is there a way to change the Mempry Usage metric to use the Guest Active Memory % metric so that all of the dashboards\alerts become relevant again?
Manually switching to the "Guest Active Memory %" metric on an ad hoc basis was the workaround recommended to me by a VMware consultant (pending an actual patch). I havent seen an official kb for it.
The canned alerts are bothersome. We're simply living with it for now; having informed all consumers of the alerts.
This is also the feedback which I got from GSS:
Would you mind follow recommendation from release notes in VROPS 6.7 and shee how it goes please?
Note: If interested in the older Memory|Usage (%) metric of virtual machines, which was based on active memory, use the Memory|Guest Active Memory (%) replacement metric. This out of the box metric is disabled and first needs to be enabled in the corresponding policy of a virtual machine.