Obtain Queue memory leak?

[AristosQueue (NI)]

---

@Ben wrote:

It can be prooved by writing a VI that repeatedly opens and closes a VISA ref. Let it run as fast as possible, mark the memory useage. Let it run over the week-end and Monday morning will show increased memory usage. It wll be released when the app is stopped and closed.

---

Are you sure this isn't an artifact of the operating system? My understanding is that Windows (and probably other modern OSes) often keeps pages reserved for an EXE unless the system runs low on available space, so if you get many allocations scattered around through many pages, you can end up with an app that looks large in memory when actually the space is free if the system actually decides to go collect it, which it avoids doing unless space runs low.

[Ben]

---

@Aristos Queue wrote:

---

@Ben wrote:

It can be prooved by writing a VI that repeatedly opens and closes a VISA ref. Let it run as fast as possible, mark the memory useage. Let it run over the week-end and Monday morning will show increased memory usage. It wll be released when the app is stopped and closed.

---

Are you sure this isn't an artifact of the operating system? My understanding is that Windows (and probably other modern OSes) often keeps pages reserved for an EXE unless the system runs low on available space, so if you get many allocations scattered around through many pages, you can end up with an app that looks large in memory when actually the space is free if the system actually decides to go collect it, which it avoids doing unless space runs low.

---

Excellent point!

Since the the memory was realeased (as shown in Task Manager) when the VI was closed (Project and LV still open) I had attributed to the LV run-time environment.

I understand LV works with the OS services and if the context for the VI is freed via the OS then I stand corrected in attributing it to LV.

The next time I have my hands on a RT target and time to play to see  how this behaves in RT.

Re: OS and memory management.

Yes, when memory runs low the memory manager will mark pages as invalid. This marking works to allow infrequnetly accessed info to be paged out and is nullified if the page is accessed again by the app (requiring only flipping a bit to page the data back in. It seems silly but it's really a sublime way of keeping memory managed).

But the page will only get paged out if more memory is demanded and tha page is on the top of the list to be over-written (has bubbled to the top due not being accesed). that happens when all of the physical memory is used and the OS has to go virtual9as long as there is physical memory, use it). My observation apply to fresh reboot machines with plenty of memory remaining. I don't see how that applies to the memory allocated to LV in the Task Manager gradually climbing as the app repeatedly open/closes resources and then releasing that memory when the VI is closed.

I had always thought of it as LV clean-up routine keeping a minimal amout of info around to protect me from myself.

Spoiler

My appologies for those times you had to point out to me that I had shot myeslf in the foot.

Ben

[altenbach]

On a side note, you also seeem to have misconceptions about the "request deallocation" tool.

It is sufficient to be called exactly once, and not over and over (10x per second in your case).

As the help states, request deallocation deallocates memory after the VI that contains this function runs. Since the deallocation happens after the VI is finished, requesting it over and over serves no purpose.

Once is enough!!! (Are we there yet? Are we there yet? Are we there yet? Are we...)

Typically, it should only be used in very rare cases. Read the help for more details. The help also states that it applies to subVIs. It is not clear if it does anything for your toplevel VI at all.

[cmteuffel]

---

@Aristos Queue wrote:

 If the problem was CPU usage then *of course* you're using CPU cycles every time you create a new refnum.

---

Hi Aristos,

Thanks for your comments and hints. As I stated in my introductory post: "I have an application that calls "Obtain Queue" at least 30 times per second and runs for several days. After 24h it likely holds more than 2,5 Mio unused memory references. [..] cpu usage go up from 15% to 100%." This problem vanished by the time I had rewritten the program to use cached references instead of calling "Obtain Queue" and "Release Queue - force destroy" in two loops.

Let me stress the fact that the CPU usage rose gradually and was low, right after the program started. I suppose the impact on CPU usage was from memory management.

Your recommendation to have a queue reference outside the main loop and call obtain and release inside the same loop seems to me equivalent to using cached references and avoiding "Obtain Queue" at all. Moreover there are certainly serveral scenarios where the "same loop" approach is impossible e.g the producer -consumer pattern using a queue for exchanging data.

[dre99gsx]

I realized the same phenomenon when I started using "Obtain Queue" all over the place thinking that just giving it a name and having Labview manage the reference would make things simpler.  I ended up probing the Reference output of the Obtain queue (which was used inside many loops) and noticed the reference kept changing.

I've since converted to using a Global to store all of my Queue references.  I create them once in an initialization vi, grab them anytime I need a specific queue, and kill them all once I end my Vi.  This solved my "memory leak" issue.