NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory Leak in File Writes?

felipefoz wrote:

We have been using this code to retrieve free memory, as labview node doesn't report the real available memory.

This returns the memory value in kB.

memFree.png

Yes, MemAvailable is OK, although it makes a potentially questionable assumption (IIRC, that half of the page cache can't be evicted). It's not present in 2013/2014 though, since it was only introduced in the 3.14 kernel.

Message 11 of 27
(6,009 Views)

Hi,

I was wondering if anyone has the right data to read from /proc/self/stat to get memory used by the real time application only?

Looking at this link http://brokestream.com/procstat.html is it the vsize I would want to read? And is the output the same amount of lines and the same order as the link?

0 Kudos
Message 12 of 27
(6,011 Views)

Mrmas,

I think it really depends on what you want to get. The SysApi memory reporting has resolved the noted problem that led to the creation of this thread in the first place, but memory reporting in Linux is tricky (as is the case with any multiprocess system with shared, copy-on-write pages that doesn't always account for kernel memory use since that accounting requires memory, etc. etc.).

So, revisiting your actual question, what specifically are you looking for? What do you intend to use this information for or to detect? The answers you give affect the (current) correct answer on what to look for.

As an aside, you probably want to use /proc/$PID/status, a little more complete (includes stat and mstat figures) and is a bit more readable.

0 Kudos
Message 13 of 27
(6,009 Views)

Hi, thanks for the reply.

First if i use /proc/$PID/status does that reference the application or do i need the PID number from somewhere first?

Second my plan when using this reading was to get the memory usage of just the labview RT application. I see a decline in free memory reported over time and wanted to see if it is a memory leak or a memory growth problem with my application.

You say the sysapi memory reporting issue has been solved, does that mean that if my application shows dropping free memory over time in MAX for eksample, that i am eating up memory over time?

Regrads

Mas

0 Kudos
Message 14 of 27
(6,009 Views)

If you want to get the memory use of the LabVIEW RT process, you should use /proc/$(pidof lvrt)/status. This is safe to use for either direct reading or the use of the SystemExec utility VI. Most places will call out the use of /proc/self/status for this, but there will be a different process used for the SystemExec use-case (as is the case anytime you spawn a new process to do something).

The issue where VFS page cache being reported as "used" memory in the sysapi (used by MAX) has been resolved, so a continually dropping free memory could indicate that there is a continual growth of memory use somewhere in your system. It's reasonable to check the LVRT memory use to see if there's something in your application that is continually leaking/using memory.

0 Kudos
Message 15 of 27
(6,009 Views)

This may be fixed in the distibuted system manager, but it is still an issue with the system configuration API property. I have tried in both 2014 and 2015.

Free Physical Memory Property.png

This is a major issue for any applications that are supposed to run 24/7 as monitoring the health of the device (CPU, memory, disk space) is common practice. I have had to use the distributed system manager shared variable to read available memory which involves installing more software to the cRIO (and reducing the available meory to start with).

I would have hoped that NI would fix this properly as from the linked articals and posts its been know about for a while.

Jon Bowers
LabVIEW Architect, TestStand Architect
0 Kudos
Message 16 of 27
(6,009 Views)