Degraded Scanclass Performance - UaTcpClientAcknowledgeHandler?

[bfuson]

I’m experiencing a deluge of these warnings the past couple of weeks that I assumed were the cause of my degraded tag scanclass performance. Finally found the related logger, or so I think, since the events are paired:

For context: only a single designer session is open, all database connections are disabled, all UA Server connections are disabled. Not sure what to make of this, or if it’s related to my scanclass issue. Due to some non-compliance in the UA Servers all tags are setup in a single scanclass using OPC Read Mode. Also thinking there could simply be too many tags to poll in a single scanclass?

The worst evaluation time on the SC has clocked in at over 3 minutes. Any changes to the tags take very long to actually process and hang up the Designer GUI.

[bfuson]

Possible similar issue:

High CPU Usage for Thread

Hey all, Can someone tell me what this thread is? It’s constantly using a very high amount of CPU, if I restart the server it calms down for a week or two and then starts doing it again. I’m guessing it’s something for the UA server? How do I go about figuring out why it’s using so much CPU resources? Thread [ua-netty-event-loop-0] id=153, (RUNNABLE) sun.misc.Unsafe.unpark(Native Method) java.util.concurrent.locks.LockSupport.unpark(LockSupport.java:141) java.util.concurrent.SynchronousQ…

Previous thread covering these peculiar UA servers:

OPC-UA Server Connections and Tag Issues

Disabling the OPC UA server connection does stop the warnings Strangely when re-enabling the connection all the tag values report correctly, but the Bad_ServiceUnsupported messages resume and the values/timestamps no longer update after the initial read. The sequence of UaSubscriptionChangeListener logs: [D] Synchronizing subscriptions… [D] Creating/deleting items on subscription ‘Scanclass ‘Default[default]’’ [D] nodesToAdd.size()=0 [D] nodesToRemove.size()=0 [D] Setting MonitoringMode to R…

[bfuson]

I’ve been slowly adding UA connections back with no ill effects yet.
However the above nuisance errors never stopped logging.

[Kevin.Herron]

If you click that “+” button to expand is there any more detail?

I suppose anythings possible, but I’d expect these errors to mean you have a few UA connections that aren’t connected.

The only way that would effect scan class execution times is if you had scripts doing system.opc.read and system.opc.write against UA connections that weren’t connected and they were being delayed for some reason.

edit: to be clear, it would have to be tags with runScript expression calling code that used those functions…

[bfuson]

The DefaultChannelPipeline logger warnings ends in:
java.io.IOException: An Existing connection was forcibly closed by the remote host.

The server IP is the one ending in .17, the device is the .41:8085.
Apparently that was a soft controller that did not have a UA Server deployed to it yet. Deploying a server to the device stopped the errors! Oddly enough that UA Server connection was disabled the entire time…

Still debugging scanclass issue, which appears unrelated.

[Kevin.Herron]

The most common causes for slow scanclass execution are slow expressions (due to usages of runScript) and slow DB query tags.

If your scan classes are in OPC Read Mode that can play into it as well.

[bfuson]

Thankfully I learned that lesson before, so no runScript in these tags.

I’ve re-enabled all UA servers we’re concerned with and the SC execution remains stable and fast.
Wondering if the above errors were indeed related… I assumed not since they were still accumulating after disabling all servers, but the scanclass execution sped up. A real test would be to deploy again without a server. Will try to follow up with the control logic integrator.