My company recently purchased Ignition, and I've been converting all the HMI's in our plant over. I recently received some complaints about lag and slowness. I looked at the performance dashboard and found the CPU Usage was indeed very high. This was recent because I've been monitoring the usage as I convert more areas.
I did a fair amount of reading on other forum topics about garbage collection and and some other things to look at with the threads. Restarting the Ignition Server did not resolve the High CPU Usage at all. It came right back.
We're running the old HMI system in parallel, so I can be very aggressive with troubleshooting the new system. I started disabling projects, database connections, and PLC connections until I finally pegged it to the Core Historian I was using for a few Trend Charts. After disabling the historian and re-enabling everything else, I was less than 10% CPU Usage.
I have 30 Historical Tags set up for 1 Second Sampling. For the Core Historian itself, I set the Partition Interval to "Hours" and the Maintenance Age to 6 Hours. I realistically need only 30 minutes of chart.
I played with the Partition Interval and the Maintenance Age but no matter what I changed, the CPU Usage shoots right back up to > 80% when I re-enable it. I configured the Historian probably 2-3 months ago and it had been running fine. The area of use was completed, so I haven't added any tags to that Historian in that last 2-3 months either.
Ignition Version is: 8.3.3 (b2026012009)
Is there something obvious I'm missing or doing wrong?
You might try updating to the latest version. 8.3.7 has an update for the core historian that improves performance. Not sure if it's the same issue you're having, but it's worth a shot to just get to the latest version to fix any bugs.
30 tags in 1 second intervals is very little load, for sure this is unusual CPU usage.
Here are some suggestions to consider:
Are there any other events shown in the log near the same time as the clock drift warnings? Normally you can find clues here.
Is the database sharing a CPU with Ignition, or is it on a separate machine/VM/instance?
Is it possible that you have a script running somewhere that just coincidentally fails when you shut down the historian?
Whats the CPU and how many cores does ignition have access to?
The core historian is built into Ignition, so it always shares the CPU with Ignition. (I think this is the #1 reason to not use it, closely followed by lack of redundancy support.)
Try stopping the trending rather than the historian. If you're refreshing your trends really fast, you may be killing thigns.
Definitely start your troubleshooting after an upgrade to 8.3.7+, as @michael.flagler suggests.
From the 8.3.7 Release Notes @ Core Historian:
Fixed an issue that caused Core Historian query performance to degrade as data accumulated.
During some troubleshooting prior to this update, we observed that an Internal SQLite DB was far more performant than the Core Historian as the database grew larger.
Thanks, for all the suggestions! I had to make some time to do the upgrade, but I took it to 8.3.8. I assume the fix in 8.3.7 did it though since it seems to have resolved the issue. I was able to re-enable the Historian and the CPU Usage has remained reasonably low.
