Professional OPC
Development Tools

logos

Possible Memory Growth in Unmanaged Data Client Code

More
06 Dec 2018 18:18 #6893 by support
Hello,
thanks for update.

I think it was #2 that did it - basically what I have (too late maybe) suggested in my previous post as well.

Best regards

Please Log in or Create an account to join the conversation.

More
06 Dec 2018 16:24 #6892 by gkalipershad
Z,

I heard back from the customer and he resolved the issue. Here are the changes he made:

1) The polling thread was calling a method using locally declared variables with C# ref as parameters. I changed the variables to C# Public Properties with Getters/Setters and got rid of the ref parameters on the method call.

2) I moved the creation of the “new EasyOPCclient” to the constructor of a separate class to ensure that only one client exists at any given time.

3) I reinstalled the latest SW Toolbox OPC, licensed and built the solution against those dlls.

The memory usage has held steady for two days now whereas it previously increased by 100MB/day.

Thanks for you efforts on this.

Regards,
GK

Please Log in or Create an account to join the conversation.

More
06 Dec 2018 15:50 #6891 by support
Hello,
I have realized some more bits.

If there is a leak, it might be related to lifetime of EasyDAClient object itself, as the customer have kind of guessed. If so, then a workaround (not a bug fix) might be to simply refrain from creating new instances of EasyDAClient - just use one, or a handful (static set) of them.

Also, while I understand the observed leak appears to affect the unmanaged memory, that can be just an unmanaged memory that we use internally in the *managed* EasyDAClient. Therefore, this unmanaged memory would be, indirectly, also managed by the CLR/garbage collector, and may show indeterministic behavior. In that case, I have seen situations in which observing the memory for one day isn't enough as a proof of a consumption trend/leak. Test duration of 7-10 days is recommended, observing the memory with PerfMon. More info: www.opclabs.com/forum/ua-general/2278-internal-long-running-test-results (that was for UA, but the conclusion still holds).

Regards

Please Log in or Create an account to join the conversation.

More
04 Dec 2018 16:38 #6883 by support
Hello.

Well I need a reproducible scenario - a small project that I can just take, build, and run here (i.e. it needs to connect to our simulation server, or some other OPC server that we can get hands on and does not require additional hardware etc.).

If there is a leak, the pace of it will probably depend on the volume of method calls/items involved, so that can be bumped up or controlled with sample servers as well. The important thing is to get a leak that can be clearly seen by us on our systems (so that I can debug it and use other analysis tools then).

Best regards

Please Log in or Create an account to join the conversation.

More
04 Dec 2018 14:41 #6881 by gkalipershad
Z,

Please see the below email that I received from a customer:

"I have written a number of Windows services in C# running on Server 2012 R2 that use your OpcLabs.BaseLib and OpcLabs.EasyOpcClassic .dlls version 5.50.323.1 to read and write values from and to Automation Direct PLCs under KepServerEx control. The latest service is experiencing memory buildup when polling a dozen PLCs at 60 second intervals in a thread. Indications on Windows Task Manager are that it is growing at about 100MB per day. I have used Ants Memory Profiler and the growth is entirely in Unmanaged Code. The only Unmanaged Code source in this service is the referenced Opc .dlls. There are no C# arrays, lists or objects being constructed in the polling thread, only objects that were constructed at service startup. I have tried disposing of the EasyDAClient by calling the client.Dispose method in the dll interface, nulling the object reference, and calling GC.Collect() all to no avail."

Please let me know what additional details I need to obtain from them, or if you have any questions I should ask.

Thanks,
GK

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.195 seconds

      

 Recommend this on Google