Can anybody tell me the difference between retrieving a cRIO's available free memory from the System Resource reference versus using NI Distributed System Manager and viewing the "NI_SystemState > Memory> Available" variable?
When viewing these, the values are different, and show different trends over time.
For example, when my cRIO monitors its own SystemResources.Memory.FreePhysical property, the value begins at 384 MB and slowly and continuously decreases with time at a rate of about 500kB/min. However, when viewing the NI Distributed System Manager shared variable NI_SystemState for the same cRIO over the same time, the value is 445 MB and fluctuates gently around this constant value by a few kB, neither decreasing nor increasing over time (several hours).
Also, one can monitor the SystemResources.Memory.FreeVirtual property on the cRIO instead of FreePhysical and this one holds constant at around 583MB, like the NI_SystemState shared variable, but it doesn't match the actual value (the difference being about 140MB).
At the moment I'm simply attempting to ensure my code has no memory leak. However, which variable should I trust, and why do they all differ so much and why does one of them show ever decreasing available memory and the other two show a flat trend?
Final point - if I leave this running overnight, the amount of available memory according to SystemResources.Memory.FreePhysical drops to near zero, but the NI Distributed System Manager still shows that the device has plenty of RAM free.
cRIO monitoring RAM with property nodes:
versus external monitoring through Distributed System Manager:
Solved! Go to Solution.
I left the cRIO running overnight.
The local SystemResources.Memory.FreePhysical value has dropped from 384MB yesterday to 255MB.
The local SystemResources.Memory.FreeVirtual value pretty much stayed the same, now 589MB when it was 583MB yesterday.
And NI Distributed System Manager running on my PC is showing Available Memory on the cRIO at 451MB. Again, approximately the same as yesterday's 445MB.
Any ideas from anyone on why the local values are different to the remotely monitored values, and why one of them shows a decreasing trend?
Are you using a Linux based cRIO?
- the System Ressource free physical property node is using the /proc/meminfo command to report the free memory, which does not take disk buffers and caches into account. Especially with logging applications it could look like a memory leak/
See also this KB: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9usSAC
I couldn't find how the DSM and FreeVirtMem are calculating the memory, but those look like a better representation of the actual free memory, or you could use the technique from the KB.
Thank you for your reply. The article is interesting, but it doesn't entirely help me and it raises more questions.
It confirms that NI Distributed System Manager will report an incorrect value for Free Memory on my Linux cRIO. It doesn't say why. Are NI intending to put this right?
It confirms that the System Resources Free Physical Memory Property Node will also report an incorrect value for free memory. Again, why? NI are responsible for the underlying code and seem happy to allow this node to report misleading information, instead of removing it, or reporting NaN or otherwise. Not cool.
The article then goes on to suggest calling the Linux shell will a command that will report on the amount of memory used by the lvrt process. That's interesting, and I can use this information to look for memory leaks in my app, but ultimately I care about how much memory is remaining so that I can decide if my app needs to enforce a system restart before it locks up/freezes due to complete memory unavailability (obviously, I'm hoping this never happens, but the code should check and manage for robustness).
I'll give the article's system comms interrogation idea a trial...
Thanks for spending your time assisting me Andreas!
I should also have mentioned that there is already a CAR filed against this behavior and this article is meant as a work-around for the meantime.
The underlying problem is, that the concept of "free memory" on a Linux system is more difficult. The "free memory" property is giving you exactly the free memory. However, there is quite some additional memory which the kernel can make available very quickly if necessary (the cached and buffers), but is technically not free because it is used in the cache to speed up data access.
IMHO, if you would like to make sure the cRIO can do file access with the highest possible speed, use the free memory from the property node as a guideline. If you just want to make sure it doesn't crash/lock up, you should add the cache and the buffer values when evaluating.
I hope that makes sense,
In a recent project I ran into the same problem with the free memory on a cRIO. After some research, googling and helpful discussions with some great LabVIEW friends I solved the problem by reading direct the Linux memory informations in /proc/meminfo. This file provides a long list with details about the memory. The most is very complicated Linux stuff that I don't understand, but the first three lines are the important ones:
For more information about this values see https://access.redhat.com/solutions/406773