Monitoring your PC RAM percentage of use in LabVIEW

[LFBaute]

Does anybody knows how to monitor RAM % of use in a LabVIEW App,

I tried getting the CPU % of use, very similar like CPU% as below

https://forums.ni.com/t5/Example-Code/Performance-Monitor-Using-LabVIEW/ta-p/3501988

but I'm missing the RAM percentage of use, Has anybody done something for the RAM % monitoring?

Thanks

[Andrey_Dmitriev · Accepted solution]

Get Memory Status:

?

[mcduff]

---

@Andrey_Dmitriev wrote:

Get Memory Status:

?

---

My biggest issue with the native memory function in LabVIEW is that it doesn't seem to agree with the values from the Task Manager in Windows. Do you know why there is a discrepancy? I typically use a .NET method(shown below), but don't really like it as the first call is really slow. Is there a way to reconcile the native function and task manger?

Thanks

[LFBaute]

lll give it a try to the 2nd .NET option, and check where the difference is, thanks

[Andrey_Dmitriev]

---

@mcduff wrote: My biggest issue with the native memory function in LabVIEW is that it doesn't seem to agree with the values from the Task Manager in Windows. Do you know why there is a discrepancy?

---

You probably checked different memory metrics. You should not confuse private bytes with working set.

Private Bytes summarize the amount of RAM allocated to the process, referring to the amount of memory that the process executable has asked for - not necessarily the amount it is actually using. They are "private" because they (usually) exclude memory-mapped files (i.e., shared DLLs). Private Bytes are the actual bytes allocated by your app, including pagefile usage. In general, private bytes represent the overall committed memory.

Working Set refers to the amount of physical memory (RAM) the process uses. This value could be smaller than private bytes, but it could also be larger. In general, the measurement is less accurate since it also includes memory-mapped files and other resources, unlike private bytes.

Virtual Bytes represent the total amount of virtual address space that a process occupies. Similar to the working set, this set includes memory-mapped files (shared DLLs), but it also includes data in the standby list, as well as data that has already been paged out and resides on a disk somewhere. When a system is under heavy load, the total virtual memory used by all processes is significantly greater than the actual available memory.

The value reported in Task Manager's "Mem Usage" has been the source of endless confusion in recent years. Memory in the Working Set is "physical" in the sense that it can be addressed without a page fault; however, the standby page list is also still physically in memory but not reported in the Working Set. This is why you might see the "Mem Usage" suddenly drop when you minimize an application.

In my understanding, LabVIEW will show pure Private Data without Heap and Stack, usually slightly smaller (but may be I'm wrong, only NI can explain this).

Anyway, if you need very detailed information about the memory footprint of your app, then I can recommend to download VMMap from Sysinternals:

And for very deep diving, I would recommend to obtain the "Windows Internals, Part 1" book, written by Mark Russinovich & Co, where everything is explained (including tool above) in Chapter 5 — Memory Management.

[mcduff]

Thanks @Andrey_Dmitriev for the detailed response.

Last Question: Are you rolfk’s alter ego? 😁

---