OPC UA Client and high CPU|OPC UA Standard|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
OPC UA Client and high CPU
Avatar
Simon
Member
Members
Forum Posts: 5
Member Since:
08/31/2016
sp_UserOfflineSmall Offline
1
11/07/2018 - 14:17
sp_Permalink sp_Print

Hi people,

We are currently running tests with our OPC UA client application that talks to remotes PLCs that contains roughly 3000 tags. In our client app, all 3000 monitored are distributed over 4 subscriptions and their values moves a lot and we expect some CPU activity. But we read actually like 75-80% constant CPU usage on the Client PC (in fact it take all remaining system CPU that rise in the task manager at 100) and we try to figure out what is going wrong. The sampling interval is at 1000 ms (for subscription and monitored items) but has we increase the subscription sampling to 10000 ms, then we can see the CPU drop to 1% and peak at 30-35% every 9-10 seconds. The value updates seems also inconsistent, probably due to the CPU usage.

I have no clue at all what can cause this behavior. At one subscription with 1000 tags, the CPU is at 4-5% and it works a bit better. And most important, if I subscribe all 3000 tags but I skip the notification += event on all monitored items, then I notice the same High CPU behavior.

configurations (items):

MonitoredItem monitoredItem = new MonitoredItem(subscription.DefaultItem)
{
StartNodeId = nodeId,
AttributeId = Attributes.Value,
DisplayName = (string)nodeId.Identifier,
MonitoringMode = MonitoringMode.Reporting,
SamplingInterval = 1000,
QueueSize = 1,
DiscardOldest = true
};
monitoredItem.Handle = new ItemInfo(tag);  // our custom object linked to

// add the callback notification event
monitoredItem.Notification += MonitoredItemEvents;

 

configurations (subscription):

subscription = new Subscription(m_session.DefaultSubscription)
{
PublishingEnabled = true,
PublishingInterval = 1000,
MaxMessageCount = 1000,
MaxNotificationsPerPublish = 1000
};
subscription.KeepAliveCount = 10;
subscription.LifetimeCount = 10;
subscription.Priority = 0;

m_session.AddSubscription(subscription);
subscription.Create();

 

configurations (xml config file):

<TransportQuotas>
<OperationTimeout>600000</OperationTimeout>
<MaxStringLength>1048576</MaxStringLength>
<MaxByteStringLength>1048576</MaxByteStringLength>
<MaxArrayLength>65535</MaxArrayLength>
<MaxMessageSize>4194304</MaxMessageSize>
<MaxBufferSize>65535</MaxBufferSize>
<ChannelLifetime>300000</ChannelLifetime>
<SecurityTokenLifetime>3600000</SecurityTokenLifetime>
</TransportQuotas>

<ClientConfiguration>
<DefaultSessionTimeout>60000</DefaultSessionTimeout>
<WellKnownDiscoveryUrls>
<ua:String>opc.tcp://{0}:4840</ua:String>
<ua:String>http://{0}:52601/UADiscovery</ua:String>
<ua:String>http://{0}/UADiscovery/Default.svc</ua:String>
</WellKnownDiscoveryUrls>
<DiscoveryServers></DiscoveryServers>
<EndpointCacheFilePath>Endpoints.xml</EndpointCacheFilePath>
<MinSubscriptionLifetime>10000</MinSubscriptionLifetime>
</ClientConfiguration>

So if you have any information regarding this subject, it would be very helpful.

Thank you,

Avatar
Randy Armstrong
Admin
Forum Posts: 1451
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
11/08/2018 - 05:07
sp_Permalink sp_Print

You can reduce network I/O at the cost of some latency by increasing PublishingInterval and MaxNotificationsPerPublish.

You may be able to reduce message volumes with deadband filters on the MonitoredItems.

The client library has a watchdog thread that is used to detect server failures.
You can slow this down at the cost of increasing the time to detect failures.

Avatar
Simon
Member
Members
Forum Posts: 5
Member Since:
08/31/2016
sp_UserOfflineSmall Offline
3
11/08/2018 - 07:07
sp_Permalink sp_Print

Hi,

I have tested several PublishingInterval and MaxNotificationsPerPublish settings (high and low) and it is actually not solving the issue when the new values are processes. On the other hand, I still want to receive all new values at max 1 second so I want to keep my PublishingInterval at 1000. I also do not want to skip any values and, so I don`t want to deadband my monitored items.

But the fact that you mention about watchdog activity is interesting, because one of my assumption was that maybe there is a log activity going on (even though, there is no setup to get those logs) because of issues and I would like to check for this. 

Is there a way in the code to turn off any watchdog activities or logs activities in any of the OPC Foundation dlls (client, configuration and/or core)? Does it need to be setup in a config file or is it a property in the session or the subscription?

Thank you.

nb: I have done a test with a Client from an OPC vendor and I could import all the tags with the subscription and settings mentioned above (1 seconds) and read a CPU usage around 1%, so I know this high CPU is not a normal behavior and I assume it is something about a specific configuration but can`t figure it at this time.

Avatar
Paul Hunkar
Cleveland, Ohio, USA
Moderator
Members

Moderators-Specifications

Moderators-Companion

Moderators-Implementation

Moderators-Certification

Moderators-COM
Forum Posts: 109
Member Since:
02/24/2014
sp_UserOfflineSmall Offline
4
11/08/2018 - 12:39
sp_Permalink sp_Print

One thought is that this might be better posted to Github, since that is the target for programming issues.

Also why do you have a limit of 1000 on the MaxNotificationsPerPublish (3000 tag / 1 second, but a single publish is only 1000 values- so you can not get them all in one publish)

 

Paul

Paul Hunkar - DSInteroperability

Avatar
Simon
Member
Members
Forum Posts: 5
Member Since:
08/31/2016
sp_UserOfflineSmall Offline
5
11/08/2018 - 13:46
sp_Permalink sp_Print

I could finally found how to solve this issue.Smile

I had a good assumption and Randy was also on the right track. It is indeed because of the trace logs that the CPU of our client application and test was on the rise. By a CPU profile session in debug with Visual Studio, I could see this was called as many times has the monitored items changes and since there was no trace file output set from my client, who knows how the Opc.Ua.Core dll can handle this (I haven't check the core code and not planning to do it).

By disabling the trace and logs by adding this line of code before creating a session :   

Opc.Ua.Utils.SetTraceOutput(Utils.TraceOutput.Off);  // this function is in the Opc.Ua.Core.dll

, it solved the CPU issue.

 

To answer your question Paul, I have 3000 tags but separated over 3-4 subscriptions (since our PLC support a max of 1000 items per subscription) and each subscriptions support a MaxNotificationsPerPublish of 1000, so technically it should be enough to receive all changes and in fact this is what I can observe in my test.

 

Best regards,

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 21
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1349
Posts: 4577