shared variable engine memory problem

[cosmin]

Hello,

I have a lot of problems with DSC 8. The server that worked very well in DSC 7, in DSC 8 is creating a lot of problems starting with memory leaks in tagsrv process. I have over 5000 shared variables and when I publish them the tagsrv is around 90Mb of memory. After approx. 30 min is around 130Mb and so on until the computer becomes useless. If I restart the computer the process is the same, even if I don't start the VI that updates the shared variables. I tried to uncheck different things in the variables definition like: no alarming, no buffering, no scaling, with no improvement.

Is there a way to undeploy the shared variables or processes manually, not from the labview project, or Variable Manager. To undeploy the mentioned library with the Variable Manager takes more that an hour (just to enumerate all the shared variables).

Any suggestion is welcomed,

cosmin

[cosmin]

Another thing that I forgot to mention: can anyone explain how come I see the process but not the items (the message is "no items") in the "Monitor Variables" but the process and the items appears in the Variable Manager, or in the Server Explorer ,I can't see any items for the same process in the LookoutOPCServer but I can see the process and the items in the Variable Engine.

thanks

cosmin

[JamesTJ]

cosmin,

Can you post your machine specs?

[cosmin]

Hi,

The machine is a P4 , 2.4GHz with 512 Mb RAM, Windows 2000 Professional.

[nickf]

cosmin,

  I have several thoughts for you.  First, I recommend splitting up your 5000 variable library into a set of smaller libraries.  In contrast with the LabVIEW DSC 7 engine, the LabVIEW 8 Shared Variable Engine is optimized for multiple smaller libraries.  I would recommend having at most about 1000 variables per library.  You'll see some different recommendations from different people at NI, but in my personal experience I think 1000 is about as many Shared Variables that can be easily managed at once.  For your case this would mean having 1000 variables in 5 different libraries.   --Splitting up your library gives you the added benefit of being able to undeploy/disable individual libraries without affecting the other libraries.  Unfortunately, the SCF migration tool will not do this for you manually so it may take a little time to get everything organized.

  Your comment about ever-increasing memory usage is concerning.  Do you see this while deploying your library, or while writing values?  If you write to values very fast (like in an untimed loop) for an extended period of time memory usage will increase as the variable buffers increase.  Please elaborate more on this topic and let me know what happens if you separate your variables into multiple libraries.  I was not able to reproduce this on a similarly spec'd computer using 10 libraries of 500 variables each.

  You can programmatically undeploy libraries using the delete process VI on the DSC Engine Control palette in LabVIEW.  Use this VI in combination with the get process list VI to quickly remove all currently deployed libraries.

  Also, regarding your question about why variables sometimes show up the Published Variable Monitor window; the different utilities you described may use different methods to get that variable list.  These methods behave differently depending on how stressed the Shared Variable Engine is.  If you're in the middle of loading a library with 5000 variables I'm not surprised that the list won't get populated immediately in the Published Variable Monitor window.  After the library successfully loads though, you should be able to refresh the view and see all the variables. 

Regards,
Nick F
LabVIEW R&D

[cosmin]

Hi Nick, and thanks for the reply.

I will try splitting the library in smaller parts (actually are 5048 tags) and see how it will behave.

For the memory issue, the memory usage is increasing when the library is deployed even if the VI-server is running or not!, even after I restart the computer, (I'm actually thinking about reinstalling the DSC). Also sometimes when I try to connect with a client like Variable monitor, sometimes I get an error like "tagsrv has creating an error and It will be closed by Windows".

The different items enumeration between clients it appears after deploying the library of course and is the same allways : Variable monitor is enumerating the processes but not the items, the LookoutOPCClient is enumerating some processes (not all of them) with all the coresponding items.

Something else that is curios, in the VI-server is connecting with no error to the items but when I try to write to item the VI hangs and cannot be stopped at "DataSocket Write".

Regards,

Cosmin

[nickf]

Cosmin,
 
  What do you mean by VI-server?  DSC 8 components include the Shared Variable Engine, IO Servers, and simple VIs.  Can you elaborate a little more?

Regards,
Nick F
LabVIEW R&D

[cosmin]

Hello Nick,

Maybe I confuse you with the VI server term, I meant the VI that updates the shared variables (like the VI servers in DSC 7 that updates the tags), sorry about the confusion.

cosmin

[Prashanth]

Hi cosmin,

Were you able to split your 5000 tags into multiple libraries? How did the system behave? If I understand you right, you are saying that the tagsrv increases in size even if you are not updating it with values from your vi. Does this 'memory leak' stop if you reduce the number of deployed variables (to say about 2500, 1000, 100)?

Regards,
Prashanth

[cosmin]

Hi,

for now I didn't split the library because the server addressing of the variables is little to complex to present here (there are many types of shared variables and the server is updating them differently). I moved the library to a different computer and put the server in simulation mode. In the first few days all went pretty well and I decided to put buffering in the variables definition. After that I experienced the same memory issue. So it seems that I should split the library which I avoided so far because i have a lot of work in the diagram.

thanks and keep you posted

cosmin