RT Target memory increase and then stop the Web Service

[nopseudo]

Hi everyone,

The purpose is to show the CPU and Memory Usage of the RT on a HTML Web page

By using a Web Service deployed on a sbRIO-9637

(Project in attachments)

The project is divided in 3 parts :

1) LabVIEW RT : Collect informations of the CPU and Memory Usage, and send these informations through Web Service (PUT command)

2) G Web : Read informations of the CPU and Memory Usage stored on the Web Server (GET command) and show them on the web page HMI

3) Web Service : Perform a get/set on a FGV which store the CPU and Memory Usage informations on the Web Server

The problem is :

The Memory usage of the RT increase continuously until 100%

When the Memory is full, the Web Service stops, and there is no more communication between the RT and the Web page (RT and Web page still running).

The memory is then automatically flushed by the RT process (back to approximatively 30%) but the Web Service does not restart

Could anyone explain me why there is this leak of memory and how to solve it please ?

I don't want the Web Service to stop running anymore

Thanks a lot

[MilanR]

Hi nopseudo, the G Web part of the application is very minimal. This sounds more like a LabVIEW development question about debugging RT memory leaks in LabVIEW applications. I asked the moderator to move the question to the LabVIEW board.

[nopseudo]

Hi MilanR,

Maybe you right

I hope it will help to get a solution

Thanks 😉

[nopseudo · Accepted solution]

Hi everyone,

I've found the solution of my topic

In few words :

WHEN YOU ARE CODING ON A RT TARGET, YOUR CODE MUST BE AS PERFECT AS POSSIBLE

INCREASING MEMORY MEANS THAT YOU'RE CONTINUOUSLY ALLOCATING NEW MEMORY BLOCK TO VARIABLES WITHOUT CLOSING/DESTROYING PREVIOUS MEMORY BLOCK

For each scalar, string, array, cluster, reference, etc... you create, the RT will allocate a memory block to it

(The RT will also allocate memory block for the controls and indicators on front panel)

So you better re-use already allocated memory for the array, cluster, reference, etc...

And also close/destroy allocated memory for variables/references as soon as they are not used anymore

(And show controls and indicators on front panel only if really necessary)

For my case,

The memory was increasing because of opened references (in the RT code) which where never closed

Because the "Find Hardware" was called at each loop, it created new references at each call but they were never closed or re-used

When I put the "Find Hardware" out of the while loop, the memory block was allocated for the hardware references only one time at the beginning and then re-used in the while loop.

(I've also hide the useless indicators on the front panel)

My code ran for 5 days now and the memory still at 34% since the first day

The issue was not caused by the Web Service, but the RT stopped the Web Service and the RT Code because it reached 100% of memory usage

I hope this topic will help anyone with the same problem

See you

[Yamaeda]

---

@nopseudo wrote:

Hi everyone,

I've found the solution of my topic

In few words :

WHEN YOU ARE CODING ON A RT TARGET, YOUR CODE MUST BE AS PERFECT AS POSSIBLE

INCREASING MEMORY MEANS THAT YOU'RE CONTINUOUSLY ALLOCATING NEW MEMORY BLOCK TO VARIABLES WITHOUT CLOSING/DESTROYING PREVIOUS MEMORY BLOCK

For each scalar, string, array, cluster, reference, etc... you create, the RT will allocate a memory block to it

(The RT will also allocate memory block for the controls and indicators on front panel)

So you better re-use already allocated memory for the array, cluster, reference, etc...

And also close/destroy allocated memory for variables/references as soon as they are not used anymore

(And show controls and indicators on front panel only if really necessary)

For my case,

The memory was increasing because of opened references (in the RT code) which where never closed

---

Yes. That's true for LV also, but it'll take longer due to more memory (and bigger reference heap). Take that experience with you in all future development. 🙂