How to monitor total memory occupied by a running project?

[vgbraymond]

Hi

  I have a LV project running, and I expect it to run continuously for a few years. Is there a way that I can keep monitoring the accumulated use of memory of that project? I tried the Performance and Memory, it looks to me that it's showing the total memory usage each time my subVI is called (Is this true, by the way?), however I won't know how much memory is reused and how much is being allocated which is more important to me. If my project keeps growing its memory use, that will be a dead-ended.

  Does anyone get any idea how to monitor this?

  I am now focusing on restricting array sizes and close ref. everytime I finished using it. However I don't know if I miss anything else, it's better to have a tool to monitor it.

Raymond

[Matt_W1]

While not exact the private working set in the task manager (assuming your in windows) gives a decent estimate of memory that LabVIEW has allocated (assuming you not calling dlls that allocate their own memory since that would be in shared and not private memory). LabVIEW tends to reuse allocated memory so the average amount in use shouldn't go down much over time. You would want to check a compiled program since the LabVIEW environment adds a lot of memory use, and should better approximate what you're going to use. Also make sure to exercise all the parts of the program to find possible leaks (it can't leak if it's not being run). If you're working with large files you may want to generate some to see how your program handles them (for instance I believe the tdms format will hold some metadata of an open file in memory, so if that metadata grows over time so does memory use).

DETT (Desktop execution trace toolkit) has support for checking for things like unclosed references, and memory allocations so it can be really helpful (although it doesn't point you at the exact source of the problem it can usaully nail down the VI where the problem is). This only catches stuff that uses LabVIEW to allocate memory so a misbehaving DLL could still be a hidden problem.

I'm not sure if it's still the case but there was a memory leak when opening DAQmx, so try to open those up only once.

But there are a lot of things that could wrong in a year or two (power outage, bad hardware, bad drivers), so I would suggest you plan for something going wrong and have a way a detecting that so it can be fixed before it causes too much damage (a Heartbeat message might be suffienct).

If it you can't afford any interuptions for some reason then it gets far more complicated. Realtime hardware to handle the important parts, and/or having a secondary fallback system, Uninterruptible power supplyies, separate circuits ,etc,etc.

[myle00 · Accepted solution]

Hi,

I suggest you use the windows exported functions GetProcessMemoryInfo (http://msdn.microsoft.com/en-us/library/ms683219%28v=VS.85%29.aspx) in kernel32.dll and Psapi.dll. You'll first have to get the process ID and then you can request to see how much ram this process is using. This is the info returned: http://msdn.microsoft.com/en-us/library/ms684877%28v=VS.85%29.aspx which should provide all the info needed to profile the process memory usage.

You get access to the kerenl32/Psapi.dll exported functions if in the call library function node you type in kerenl32/Psapi.dll. It'll then list all the availible functions.

If you need this much detail and are interested in using this method but don't know how to import the functions let me know and I'll try to make a VI that gets this info (which version of LabVIEW are you using and what version of windows is on the target computer?).

Matt

[vgbraymond]

Hi Matt W,

  All I am looking at is the task manger (I am using server 2003), and yes, the memory use grows when I am working on other labview programs. Also I don't know if windows logs the information at somewhere so even I wanted to check the mem use over night, I couldn't find any luck.

  My program is expected to run continuously for years, I hope this is still realistic provided that all hardware will be fine-- always I have to prepare for the best.. So I was wondering how people examine their program before releasing to use. One thing I observed-- the memory usage listed besides Labview is keep at around 15000-16000KB, however the "PF" page file usage raised from 7XX MB to 920 MB. Though I cannot be sure about the reason of such change, there are actually some dlls being used which are not LV's. I am a little bit worrying of that too.

Raymond

[vgbraymond]

Hi Matt, I am checking out the example provided in the MSDN. However I have no idea how to obtain a process ID of Labview (instead of directly my project, right?).. Can you show me how to obtain that? I am very interested to learn how to use this function to look at my program's status in terms of memory usage!

Thanks,

Raymond

[myle00]

See the attached VI for how you'd get LabVIEW's process ID (basically you call GetCurrentProcessId http://msdn.microsoft.com/en-us/library/windows/desktop/ms683180%28v=vs.85%29.aspx). I saved it for LabVIEW 2009 since I didn't know what version of LabVIEW you have. Let me know if you need any help with GetProcessMemoryInfo .

Matt

[vgbraymond]

Hi Matt,

  I am sorry I forgot to mention the LV I am currently using. I have two PCs one using 2009 and my target PC is using LV8.6. It looks to me before applying the GetProcessMemoryInfo I still have to do other library calling ( http://msdn.microsoft.com/en-us/library/ms682050(v=VS.85).aspx ). Actually I am not familiar with building adaptable data types to feed into these functions... Could you show me how to do them?

Thanks for your help!

Raymond

[vgbraymond]

Also I am using server 2003 in my target PC with LV 8.6

[myle00]

The previous vi returned the process ID, I realized that you need the process handle for GetProcessMemoryInfo. The added VI returns this handle using GetCurrentProcess. I'll try to build the costum data for the GetProcessMemoryInfo function.

[myle00]

The attached VI returns all the memory info returned in GetProcessMemoryInfo. Look here for explanation on the meaning of the cluster items. There's also an extended function which returns a bit more info, let me know if you need that.

I saved the VIs to LabVIEW 8.6 and according to msdn it should work on Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP/2000. It also works on win7.

I'm attaching a 64bit version and a 32 bit version. They shouldn't be mixed. The 64 bit version is only used if LabVIEW is 64 bit and the 32 bit if LabVIEW is 32 bit, even if windows is 64 bit.

Matt