NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Monitoring memory usage

Hello,

This article (http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2 ) suggests that the System Property Node API does not provide an accurate view of memory usage on Linux RT.

Questions:

  1. Does that mean the RAM usage reported by the Distributed System Manager is inaccurate too?
  2. This article (http://www.linuxatemyram.com/ ) explains how Linux treats RAM. If the System Property Node use the values reported under "-/+ buffers/cache", would that be enough to resolve the issue described in http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2 ?
Certified LabVIEW Developer
0 Kudos
Message 1 of 6
(4,425 Views)

Hello,

I don't know if it answers all of your questions but there is a thread about memory issues and how to get real memory in LabVIEW.

https://decibel.ni.com/content/message/130747#130747

Message 2 of 6
(3,486 Views)

JKSH wrote:

Hello,

This article (http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2 ) suggests that the System Property Node API does not provide an accurate view of memory usage on Linux RT.

Questions:

  1. Does that mean the RAM usage reported by the Distributed System Manager is inaccurate too?
  2. This article (http://www.linuxatemyram.com/ ) explains how Linux treats RAM. If the System Property Node use the values reported under "-/+ buffers/cache", would that be enough to resolve the issue described in http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2 ?

This was an issue for 2013 that was resolved in 2014 onward.

If you are using an affected system, the DSM would also show bogus usage. I believe this component may have missed the fix in 2014, but I'd have to check.

Memory reporting in Linux is a bit more complex, at the lowest levels, than what the link you provided covers. However, the base issue was precisely that: not excluding caches and otherwise usable memory from the in-use memory reports.

The link that felipefoz provided covers a possible solution that unfortunately is not available for the releases that were the most problematic (the SysAPI and DSM issues were present in 2013, 2013 and 2014 used a 3.2 kernel that did not expose the needed entry in /proc/meminfo)

Message 3 of 6
(3,486 Views)

felipefoz wrote:

Hello,

I don't know if it answers all of your questions but there is a thread about memory issues and how to get real memory in LabVIEW.

https://decibel.ni.com/content/message/130747#130747

Very enlightening read; thanks! Reading /proc/`pidof lvrt`/status looks like a good way to check if my code leaks memory (which is one of the things I'm interested in checking)

Certified LabVIEW Developer
0 Kudos
Message 4 of 6
(3,486 Views)

BradM wrote:

This was an issue for 2013 that was resolved in 2014 onward.

Ooh, good to know. I was thrown off track because http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2 shows 2015 screenshots/snippets, and because the article's "Primary Software Fixed Version" is still blank. I presume the field should be updated to say that it was resolved in 2014?

BradM wrote:

If you are using an affected system, the DSM would also show bogus usage. I believe this component may have missed the fix in 2014, but I'd have to check.

Memory reporting in Linux is a bit more complex, at the lowest levels, than what the link you provided covers. However, the base issue was precisely that: not excluding caches and otherwise usable memory from the in-use memory reports.

The link that felipefoz provided covers a possible solution that unfortunately is not available for the releases that were the most problematic (the SysAPI and DSM issues were present in 2013, 2013 and 2014 used a 3.2 kernel that did not expose the needed entry in /proc/meminfo)

Yes please, I'd appreciate that. My company relies heavily on the DSM, and we need to know if we should use a different tool for now.

BradM wrote:

Memory reporting in Linux is a bit more complex, at the lowest levels, than what the link you provided covers. However, the base issue was precisely that: not excluding caches and otherwise usable memory from the in-use memory reports.

The link that felipefoz provided covers a possible solution that unfortunately is not available for the releases that were the most problematic (the SysAPI and DSM issues were present in 2013, 2013 and 2014 used a 3.2 kernel that did not expose the needed entry in /proc/meminfo)

Understood

Certified LabVIEW Developer
0 Kudos
Message 5 of 6
(3,486 Views)

Reading /proc/`pidof lvrt`/status looks like a good way to check if my code leaks memory (which is one of the things I'm interested in checking)

Good to know. This has been  fairly consistent feedback: one of the main reasons people want to look at memory usage is to check for memory leaks in their LabVIEW RT application. Linux allows us to query that on a per-process basis with tools like the /proc/<pid> data and we don't expose that OS feature very well in the LabVIEW API. It would be an easier and more reliable indicator of memory leaks than just looking at system-wide free RAM. Something for the NI team to think about...

0 Kudos
Message 6 of 6
(3,486 Views)