Engineering Product

Getting memory info for linux machines in device auto discovery

Finding out total memory in linux seems to be quite simple task, but getting the exact total memory from different flavors could be little tricky. There are 3 ways(roundabout, more shown below) that we know of, can give you memory info. Here we would discuss what worked best for us in the testing and what did we use in the code.

dmesg | grep Memory:

wpid694-dmesg__grep_Memory.png

To get exact total memory, this dmesg seems to be the best available command.
Problem: dmesg is used to examine or control the kernel ring buffer and hence the output is cyclic in nature. Meaning, as more logs comes in and buffer limit is reached, the earlier messages would be overwritten. Hence, not all systems would show memory output in dmesg command.
While this is the easiest method and gives exact amount, it cannot be relied upon and was not used.

dmidecode

command: sudo dmidecode –type memory
Synopsis: Good command to run manually to see memory bank details.
Problem: Not a consistent format across different OS and SMBIOS versions. Parsing different formats to add to get the real amount becomes cumbersome programming wise. This was not used either.

/proc/meminfo

command: grep MemTotal /proc/meminfo
Similar variants: free -m, vmstat, top
Synopsis: Outputs the total memory available to system after reserved etc.
Problem: Memory reported is always less than actual total memory. It becomes a guess work to get exact amount.

Workaround: We ended up sticking to /proc/meminfo to estimate total memory.

In earlier versions of auto discovery client, we were just going to next power of 2 based on the MemTotal value. This was an issue when memory amount increased and was not a power of 2 #(e.g. 12GB was being reported as 16GB).

Starting with v203 of device42 auto-discovery client, we are doing memory estimation based on following formula and hopefully would get a closer # to real value:

If memory is less than 512, we are using 128MB increments to determine the total memory. For example, if system reports 507536, that gives 507536/1024 = 496MB. We would use 128MB increments to estimate: 496/128 = 3.87. We take the ceiling value of 3.8, which is 4 multiply by 128 and get to 512MB.

Increments(used in the software) go up as memory goes up:
512 to 1023: 256MB
1024 to 4095: 512MB
4096 to 8191: 1024MB
>8191: 2048MB

Now again, these are just estimates and might get the wrong value in following circumstances(and may be more):
1. If the system is reserving more memory than the increments.
2. If you do have lesser size memory chips than the increments. e.g. 1280MB would always be reported as 1536MB.(because of 512MB increments)

Option "dont change via api" can be used in the device details if you are manually overriding the discovered memory value.

Your suggestions are most welcome on how we can get exact total memory in a better way or improve the current process.
Also, source code for auto-discovery client is available upon request, if you wish to play around with it and make any changes as per your environment/requirements.

 

Share this post

About the author