Jump to content

IMAQ Memory Fragmentation Issues


Recommended Posts

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! 

Link to comment

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.

Link to comment

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.

Link to comment

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. 

Link to comment
7 hours ago, 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).

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.

 

 

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.