IMAQ Memory Fragmentation Issues

[szalusky]

I have a relatively large application which does heavy IMAQ image processing.  Many IMAQ buffers are created and destroyed dynamically at runtime based on need (i.e. different system components will create their own temporary images for processing steps and destroy them when their work is finished). While this dynamic creation/destruction reduces the overall memory footprint at a given time, it appears the constant re-sizing or re-creating is causing memory fragmentation over time. When this dynamic creation/destruction is used heavily, we get IMAQ out of memory errors (at different places in the application) after the system has been running for some time. Total memory usage has not increased (and is well below 2GB) so the errors are presumably due to the fact that there are not large enough contiguous blocks available. 

Are there any best practices or “standard” ways for managing lots of image references? Should they all be created initially? One idea is to allocate a pool of resources on startup (of images that will not get resized) that are shared throughout the application using a mechanism to “reserve” and “release” the resources in the pool. Is this a good approach?  Thanks! 

[MikaelH]

I hope you are running LV 64bit to start with, we only run 64 bit here, so we hardly get any out of memory issues.

The easiest way it to stop disposing/destroying the image and see if that helps.
If you create a "new" image with the same name, you'll just get the same reference.

A pool is one way to go as well, but you need a acquire and release images out and into the pool, so if the pool is empty the next user have to wait for his turn.

[smithd]

I'm not totally clear on the concept but I wouldn't expect contiguous memory to be a problem on the desktop (and linux-rt targets) since they have virtual addresses. I know that this was a big nice thing about switching from vxworks to linux-rt, there was no longer any concept of a largest contiguous block.

Are you sure there isn't a (very) temporary spike in memory usage and you're actually running out? I don't know if this works for imaq but under normal circumstances I'd suggest using desktop execution trace to monitor your program and see what is happening when you run out.

[szalusky]

Unfortunately 64-bit LabVIEW isn't an option in the near term (we have some NI motion dependencies which are not 64-bit compatible). In the future we'd like to break this part of the application out (maybe create a proxy application or move to an embedded solution) but in the mean time we are stuck with 32-bit labVIEW. I've thought about allowing some dynamic creation of images in addition to the pool so that during times of high load we do not have parts of the application blocked waiting for resources to be freed elsewhere. In this circumstance when the reference is "released" back to the manager it will be destroyed. Even if this is allowed, it should still cut down on the total number of images created/destroyed in the application (under most circumstances the resources available in the pool will be re-used). 

We are working on putting more memory monitoring in place to better understand the circumstances under which the out-of-memory errors occur.  As of yet, the memory appears to be more or less stabilized (with plenty of total memory available) when the errors occur. Also, once the error occurs initially all subsequent requests to allocate the necessary memory generate out-of-memory errors - we have to re-start the application to fix the problem. 

[MikaelH]

  On 3/1/2017 at 6:26 PM, szalusky said:

Unfortunately 64-bit LabVIEW isn't an option in the near term (we have some NI motion dependencies which are not 64-bit compatible).

Expand  

You are right the NI-motion driver is not working in 64 bit, which is a really bad thing.
But we use the NI motion drivers very successfully on from LV 64 bit....so how do we do that?

We create a LV32 bit server application, that our LC64 bit application starts (if it's not already running).
We then connect and send instructions over localhost-TCIP/IP, to the 32 bit written LV server application.
We use this architecture for several driver components where e.g. the vendor only supplies a 32 bit dll version.

Since we're using a GOOP based HAL inheritance structure the driver layer solves all our problems.

I hope you don't give up yet on the 64 bit solution, since it will solve a lot of your problems.