I am currently dealing with some high latency issues and clock drift errors that happen in succession. We are using one server over multiple clients and PLC's. There is a particular set of clients which are only connected to a certain PLC that are having high latency issues. All of our client screens are standardized as well as the UDTs, tags and logic they are referencing. The only difference is how many stations, types of stations we have on each PLC but for the most part are similar. We are running 7.9.17. Java is 8. 220K tags. Garbage collection is set to G1GC. We were autobacking up which seemed to coincide with the clock drift errors. Although it would be inconsistent in terms timing after. Sometimes could be an hour or 2. I have changed the back up frequency to once per day. But still have high latency and occasional clock drift. Each client is a windows based touchscreen running a client launcher shortcut.
Update to 7.9.21 (the last published version in the 7.9 series)
Add java GC logging options to ignition.conf so you can see if GC pauses coincide with your warnings. (You'll have to look up the java8 options--they changed in the last several years.)
Consider disabling autobackups entirely. Don't develop on the production system. Only take backups when deploying from dev/qa to production. (Backups lock the single-threaded config DB and can themselves be a problem.)
Consider upgrading to v8.1--the list of bugs not fixed in v7.9 is very large.
Thank you for getting back to me so quickly. I do agree that it should be upgraded and we are currently in talks about doing so but I'm still confused as this is the only client section with issues which every other server and device has the same settings, tag structures, design. So it's something related to this particular section. I will add the gc logging. should I add max pause and initiating heap frequency percentage as well?
We did have some high load schedules on that PLC. We have since added some slower leased classes which has spread out the load quite a bit. It unfortunately did not help with performance. Some of our other servers have devices with 200% + load and are operating normally. We've also increased the concurrent requests which seemed to help a little but nothing game changing. I've also removed a lot of bad quality tags that we we're not using with no success.
That's a contradiction. 200% load means that tag group pace is not running at the target update rate.
If you have any bad OPC tags in an OPC connection, that connection (like the entire native IA loopback connection) will have pathological subscription delays on every lease change. That might be your whole problem. See this topic:
