Any idea what might cause these occasional clock drifts? We didn’t see any during our debug, but when we moved to the final hardware, they started occuring every now and then. Resources seem to all be failry low, Windows puts everything under 50% and the gateway doesn’t even get to half the RAM we have dedicated with roughly 5% CPU usage.
I did replace the CMOS battery this morning. Its a long shot, but figured it was worth trying. Computer was supposedly new, but maybe the customer bought a refurb one for us and that missed being replaced.
Another thing people do is historize the CPU and memory system tags. This lets you throw them into an easy chart or something and see if the drifts correlate with big memory collections or CPU spikes.
No scheduled reports or anything? The spacing on the messages is too much to be a coincidence. Something scheduled, either inside Ignition or out, has got to be running…
You do have a chance every hour, and you know it up to the minute, to monitor your system and see which component is getting a heavy load (CPU, disk, RAM or network), and to check which program it's coming from.
Hi, I am having similar issue but consistently every 15 minutes.
Automatic backups are set to every hour, I have gateway timer scripts at every minute and every hour and they work fine, and I have reports schedule for twice a day and every hour and they also work fine.
I don't have any scheduled activity that happens every 15 minutes.
Any suggestions where could I look for root causes?
Interesting. Something is running every fifteen minutes. Is this a VM? Where something else on the same hardware is bogging the physical hardware every fifteen minutes?
{ This looks a lot like what I've seen elsewhere with hypervisors stealing CPU time from "idle" Ignition VMs. }
Huh. Detailed logging is in order then. You should turn on GC detail logging via additional java parameters in ignition.conf.
Consider also reducing the amount of memory Ignition is allowed. The more there is that is churning, the longer the GC pause time can be. Find the time of day where that memory sawtooth spikes highest, and set the limit ~20% beyond that. Make sure both initial heap memory and max heap memory are set to the same value.