Wrong memory value reported by OMI

[johanburati]

We are having a problem with a VM where SCX is reporting wrong values for the memory.
Please see the free and omnicli command output below and let me know if you need more information.

OS is Centos 7.2
kernel: 3.10.0-514.26.2.el7.x86_64

$ rpm -q scx omi
scx-1.6.3-274.x86_64
omi-1.2.0-35.x86_64

$ free -m
               total        used        free      shared  buff/cache   available
Mem:           3440         309         180          39        2949        2782
Swap:          6499           0        6499

$ /opt/omi/bin/omicli ei root/scx SCx_MemoryStatisticalInformation
instance of SCX_MemoryStatisticalInformation
{
     Caption=Memory information
     Description=Memory usage and performance statistics
     [Key] Name=Memory
     IsAggregate=true
     AvailableMemory=498
     PercentAvailableMemory=14
     UsedMemory=2942
     PercentUsedMemory=86
     PercentUsedByCache=0
     PagesPerSec=8
     PagesReadPerSec=0
     PagesWrittenPerSec=8
     AvailableSwap=6499
     PercentAvailableSwap=100
     UsedSwap=0
     PercentUsedSwap=0
}

[jeffaco]

This sort of issue comes up regularly.

The problem is that there are a lot of ways to "compute" available memory, depending on how you look at the numbers. Indeed, different programs on the same operating system will often report conflicting numbers for memory usage (i.e. ps vs. free).

On Linux, we look at the /proc/meminfo file, see implementation if interested. But roughly speaking, we consider free memory to be what's reported as "free" from the O/S + disk buffers + page cache. We consider this as "free" since the O/S will routinely go to these areas first for memory as it's "cheap", and doesn't result in further swapping (at least directly).

This comes up often enough, vendors post their own analysis, like Redhat, due to frequent customer questions.

In short, we believe we compute memory in a "reasonable" way (i.e. a way that makes sense when explained, and is logical when considering how the O/S deals with memory usage). If you have a specific case where you think our analysis is incorrect, please let us know.

[johanburati]

hi @jeffaco

I understand there are different ways to "compute" available memory, however the graph in the portal show 14% available memory while the free command shows like 80% available memory, there is quite a gap.

free

total=3440
used=309
free=180
share=39
buff/cache=2949
available=2782

SCX_MemoryStatisticalInformation

AvailableMemory=498
PercentAvailableMemory=14
UsedMemory=2942
PercentUsedMemory=86

consider free memory to be what's reported as "free" from the O/S + disk buffers + page cache

I do not quite understand how SCX_MemoryStatisticalInformation is reporting the AvailableMemory has being only 498, if you look at the free command output the buff/cache is already 2949, am I missing something, could you explain how the above values match ?

[jeffaco]

Following up with @johanburati directly, will respond here when we have more data.

[nirsingh]

With the linux kernel 3.14+ MemAvailable: is available in /proc/meminfo provides a better way of getting the Available Memory instead of calculating it as MemFree: + Cached: + Buffers:

Check-in : microsoft/pal@24da02b