- Posts: 22
- Thank you received: 0
Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
Unmanaged memory leak?
13 Sep 2010 17:43 #74
by Shea
Replied by Shea on topic Re: Unmanaged memory leak?
I upgraded to the new version; the memory profile looks good. Thank you for the prompt response and quick fix - great customer service.
Please Log in or Create an account to join the conversation.
12 Sep 2010 13:01 #73
by support
Replied by support on topic Re: Unmanaged memory leak?
The memory leak is now fixed, in QuickOPC.NET build 5.00.1377.1 which is now in the download area (www.opclabs.com/Downloads.aspx). Thank you for discovering this problem.
Internal note: All previous QuickOPC.NET 5.00 builds were affected. The bug does not affect QuickOPC-COM.
Internal note: All previous QuickOPC.NET 5.00 builds were affected. The bug does not affect QuickOPC-COM.
Please Log in or Create an account to join the conversation.
11 Sep 2010 18:48 #72
by support
Replied by support on topic Re: Unmanaged memory leak?
I have identified the cause of the problem. Please allow 1-3 days for the fix to be implemented and verified.
Please Log in or Create an account to join the conversation.
08 Sep 2010 10:25 #55
by support
Replied by support on topic Re: Unmanaged memory leak?
It seems that I have been able to reproduce the problem, or at least something very similar. As such, no further action is required on your side right now. I will investigate into what could be the cause.
Please Log in or Create an account to join the conversation.
07 Sep 2010 16:55 #54
by Shea
Replied by Shea on topic Re: Unmanaged memory leak?
The OPC Server we are connecting to is RSLinx - I am not sure how to stop it from sending updates to our program, but will try and figure it out.
With each tag I am now displaying the TimeStamp from the VTQ object, which will let us know if we start lagging behind.
As it stands I have to log into my customer's system and restart our program once a day so it does not run out of memory. Have you been able to reproduce the issue?
With each tag I am now displaying the TimeStamp from the VTQ object, which will let us know if we start lagging behind.
As it stands I have to log into my customer's system and restart our program once a day so it does not run out of memory. Have you been able to reproduce the issue?
Please Log in or Create an account to join the conversation.
03 Sep 2010 16:39 #53
by Shea
Replied by Shea on topic Re: Unmanaged memory leak?
Thanks for the prompt response.
I had a typo in my post - should say 500ms and 1000ms, not 500ms and 100ms.
We notice that eventually the EasyOPCDANet driver will stop sending updates (or sending the same old value over and over, I'm not sure, but I would suspect the former).
I will put in some logging to determine whether the timestamps start lagging behind the current time.
The system we're running on is a Windows Server 2k3 box with 4 GB of RAM and 4 processors with the overall CPU percentage usually around 10-15%.
I'm attaching a screenshot of the memory profile. I had to restart the program twice in the shown interval (indicated by the sudden drop in memory). You can see the steady increase of the dark blue line (private bytes). The light blue line is process elapsed time. The green line is managed memory usage in all heaps (ranges between 46 megs and 57 megs)
I had a typo in my post - should say 500ms and 1000ms, not 500ms and 100ms.
We notice that eventually the EasyOPCDANet driver will stop sending updates (or sending the same old value over and over, I'm not sure, but I would suspect the former).
I will put in some logging to determine whether the timestamps start lagging behind the current time.
The system we're running on is a Windows Server 2k3 box with 4 GB of RAM and 4 processors with the overall CPU percentage usually around 10-15%.
I'm attaching a screenshot of the memory profile. I had to restart the program twice in the shown interval (indicated by the sudden drop in memory). You can see the steady increase of the dark blue line (private bytes). The light blue line is process elapsed time. The green line is managed memory usage in all heaps (ranges between 46 megs and 57 megs)
Please Log in or Create an account to join the conversation.
03 Sep 2010 15:53 #52
by support
Replied by support on topic Re: Unmanaged memory leak?
Thank you for your post.
There should be no need to do anything explicitly for the unmanaged memory used by EasyOpcDANet be released. In some situations, the constant memory grow is "normal" - it can be caused by the application not being able to cope with the influx of the data changes; the internal queues that consume memory will grow to a set limit, and the default is quite high (100,000 events) - if you are in such situation, you would know by symptoms such as that you will not receive the expected number of updates per certain period, and the timestamps of incoming data will become increaasingly delayed behind the current time. Pausing the updates (somehow) on the server side would cause the remaining queued events be dispatched to the application, and the memory would eventually shrink back to normal. I assume you do not have such symptoms - please confirm.
I will set up a test similar to yours, and attempt to reproduce the problem.
Best regards,
Zbynek Zahradnik
There should be no need to do anything explicitly for the unmanaged memory used by EasyOpcDANet be released. In some situations, the constant memory grow is "normal" - it can be caused by the application not being able to cope with the influx of the data changes; the internal queues that consume memory will grow to a set limit, and the default is quite high (100,000 events) - if you are in such situation, you would know by symptoms such as that you will not receive the expected number of updates per certain period, and the timestamps of incoming data will become increaasingly delayed behind the current time. Pausing the updates (somehow) on the server side would cause the remaining queued events be dispatched to the application, and the memory would eventually shrink back to normal. I assume you do not have such symptoms - please confirm.
I will set up a test similar to yours, and attempt to reproduce the problem.
Best regards,
Zbynek Zahradnik
Please Log in or Create an account to join the conversation.
03 Sep 2010 15:37 #51
by Shea
Unmanaged memory leak? was created by Shea
I am using version 5.0.1321.1 of EasyOpcDANet.dll to poll ~ 1800 tags from an OPC server, some at a rate of 500 ms and some at a rate of 100 ms, and I think I'm experiencing a memory leak in the driver.
I use the SubscribeMultipleItems method to subscribe to the 1800 tags at program start. After about a day, the program is using well over a gig of virtual memory. We log both the private bytes (unmanaged) and the .NET CLR bytes in all heaps. The .NET CLR bytes in all heaps flututates up and down as you would expect over normally GC cycles, but on average remains relatively constant. The private bytes, however, increase linearly at a rate of about 50 megabytes/hour. We are not using any unmanaged code from our application, which leads me to believe it is an issue with the EasyOpcDANet.dll.
Is there anything we have to do to release unmanged memory?
Please advise, thanks.
I use the SubscribeMultipleItems method to subscribe to the 1800 tags at program start. After about a day, the program is using well over a gig of virtual memory. We log both the private bytes (unmanaged) and the .NET CLR bytes in all heaps. The .NET CLR bytes in all heaps flututates up and down as you would expect over normally GC cycles, but on average remains relatively constant. The private bytes, however, increase linearly at a rate of about 50 megabytes/hour. We are not using any unmanaged code from our application, which leads me to believe it is an issue with the EasyOpcDANet.dll.
Is there anything we have to do to release unmanged memory?
Please advise, thanks.
Please Log in or Create an account to join the conversation.
Moderators: support
Time to create page: 0.064 seconds