Labview Web Server Memory Usage

[p-dub]

I'm posting to find out if anyone else has had issues with memory usage when using the LV Webserver to publish their front panels (only for viewing, not remote control).  I have about 40 front panels that I am monitoring through a single webpage (after some editing, since the Web Publishing tool won't help you do that automatically). At first, I had it set up using the "Monitor" option to refresh the snap shot every 5 seconds, but noticed that the memory used by Labview was constantly increasing when viewing the webpage either on the server machine or remotely on a client machine.

Even after disabling the webserver and terminating all HTTP connections, the memory which had been allocated while I was running the monitor webpage never returned to the resource pool. I tried changing the webpage to only provide a "snapshot," which is only updated when the page is refreshed in the web browser but it still causes LV to consume another 2MB EACH TIME the page is refreshed.

Now, it would take quite a few clients refreshing quite a number of times before the machine would have to start paging from the HD (or worse...), but its conceivable since the server machine is running 40+ tests for several months at a time without the opportunity to free up Labview's memory usage by rebooting.

Has anyone run into this before, where memory availability became an issue due to the use of the Labview Webserver to publish their front panels?

Does anyone know why Labview does not return the memory used when caching front panel images for publication?

Thank you all inadvance for your continued support.

[G-Money]

pwarden,

           First off, the issue could be that you stitched together 40 front panels into one html file but if you are seeing the same behavior when you try just one instead of 40 then it could be a known issue. There is an issue that we are aware of the remote panels in monitor viewing mode. The memory leak is small but will build up over time but I think that since you are using considerable amount more data than normal use cases that the leak is coming up quicker. The workaround at the moment while R&D continues to investigate the error is to use embedded view mode. I apologize for the inconvenience but hopefully using embedded viewing mode or splitting your remote panel up into smaller chunks will help out.

[p-dub]

Grant,

Thanks for your reply. Actually, I had this issue on a previous occasion, but didn't get into it so as not to "muddy the water."  I was only running one VI which was monitoring remotely using the same method, except that I had it updating every 5 seconds or so.  I let it run over a weekend, and came in Monday to find the VI on the server machine had crashed and was giving me a "Not enough memory to perform operation" dialog. At the time, I suspected it might be due to other issues as the system was still under development, so I disabled the webserver and decided not to mess with again until recently.  It should be noted that the image was much larger than the images I'm publishing now.

To your point about the VI snapshots though, the 40 images are not very large. Actually about 30 will fit on a 22" 16:9 monitor at once.  It seemed to be a little more elegant than having 40 webpages to flip through. 😉

My short term solution will probably be to add more RAM. Slightly longer term would be a write a VI to capture the front panel images, save them to disk periodically, then run a non-LV webserver to make the images available online.  It would be a lot nicer if i could kill the webserver process manually (disabling it under Options... doesn't free up the resources), but this isn't possible at the moment since it runs (I assume) as a thread under the (much) larger Labview process, or be able to start and stop the web server under Windows Computer Management.

I'll also give embedded mode a try.

Thanks for your help, Grant.

Patrick

[mtru]

I had the exact same problem you are talking about, only I was loosing ~72K of memory each time the URL using .snap was refreshed pointing to the front panel of a single LabVIEW EXE.  I did however find a work-around to this memory leak.  When I mininized the front panel of the EXE that the URL was referencing, I found out it reallocated all additional memory the the URL reference used up back to the OS.  What I decided to do was have the LabVIEW EXE programmatically minimize the front panel and then wait for ~30 seconds while memory was re-allocated back to the OS, the standardize (opened) the front panel back up.  The program is just a monitor for other programs that sends it "dashboard" data using STM so this was not an issue for me to impliment and, so far, it has taken care of the memory leak for me.

[p-dub]

Kudos, mtru! Since its a workaround, I can't go so far as "Solution," but way to go on some non-linear thinking there.  I'm sure your comment could probably give some insight to the R&D guys as they track down the source of the leak.  I'll have to try that next time we reach a stopping point in the test, because the screen minimizing once a day (and I could do it in the middle of the night since no one is around anyway) to free up the memory is a minor inconvenience compared with the potential of hanging Labview (or worse).

Ironically, I had just removed the ability for the user to manually minimize the front panels, otherwise I'd go do it right now. .  We had a run-in with a bug (which is apparently be fixed in LV2009 SP1) where Labview would crash when restoring front panels from a minimized state.

Thanks, again.

[hecmar.arreola]

This is all good information to keep in mind.  I use remote panels in almost all of my projects (embedded, however) so this is good information for me.

[Michael_N.]

Greetings gentlemen,

I'm glad to hear that you now have a workaround to this Remote Panels issue. In case you're interested, I wanted to let know about some exciting new tools NI R&D is working on that will allow users like you to create thin client applications comparable to those created with JavaScript or Adobe Flash. These applications won't require the LabVIEW Run-Time Engine and will communicate across the network using standard HTTP (two disadvantages of Remote Panels).

Since demos usually paint a much clearer picture, here's a video from NIWeek:

NIWeek 2009 Thin Client Demo

If you're interested in being a beta tester and getting access to this software, here's the link for the beta form:

Beta Application

Best regards,

Mike Neal

LabVIEW Product Manager

[hecmar.arreola]

Hi Michael!  That sounds very exciting and I look forward to participate in the beta testing.  Quick question, does NI plan to sell this as a seperate LabVIEW module or will it be included in the Full Development System?

[mtru]

I wanted to provide a follow-up on my work-around for the memory leak of the .snap function.  I made my last posting after testing this on my PC.  When I deployed it, it worked fine at first, but over a short period of time, (just over one day), the minimizing of the window programmatically no longer worked correctly.  I had to MANUALLY minimize the window to deallocated the memory.  Then, after another couple days I started getting the error "Running low on virtual memory" from the PC...I found out that the memory being de-allcocated, even when manually minimizing the window, was not going back to the OS, it was just lost all together!  I apologize for posting the information before without completing some more in-depth testing.  I'm still working out a solution and will keep you posted on this thread.

[mtru]

The lastest workaround that I tried was re-writing my program in LabVIEW 7.1 (which does not have the known memory leak issues with the Web Publishing as identified by Known Issue #156479).  This corrected the memory leak but then I had a new problem with the system crashing after running for about an hour.  Instead of trying to figure out this problem as well, I decided to go back to LabVIEW 8.6 and implement another work-around that I thought of over the weekend.  I will make a daemon program that will monitor my web monitoring program.  I will then have my web monitoring program self-terminate once every 24 hours to clear the memory leak.  The daemon program will then restart my web monitoring program automatically.  This work-around is not ideal but is the best option I believe I have until NI can fix this known issue.