Performance of trends after run time of 17+ hours - Large Client Tag History Cache?


During a soak testing of our trend displays we encountered performance issues.

On two monitors we ran a trend screen (realtime mode) that contained 4 pens each. In addition we had three pop-up trends. In total we had the 12 pens trending at once.

After 17 hours of runtime the client became slow (any navigation took more then a few seconds) and the trend was not plotting correctly. It was only after clearing the Tag history Cache did the client start to function properly and the trend plotted correctly.

Should we have the Tag History Cache enabled for the project or the ‘easy chart’ component?
(The manual does mention it improves performance. )

Is there way to refresh the cache on a regular schedule?



The cache does offer quite an improvement (assuming it works correctly!) for realtime charts in that it allows the client to only query for the most recent data from the gateway, instead of querying the full realtime range each time.

The cache should manage itself, though perhaps it’s allowing itself to grow too large compared to your client’s available memory. It roughly tries to keep itself under 20mb, but perhaps there’s an issue with the bookkeeping in your case.

On one hand, this cache has existed more or less unchanged for 6 years, so there must be something about your particular use case that triggering something we don’t see often. On the other hand, I will say that we just ran a multi-day profiling test specifically because another customer is reporting something very similar. That test showed no memory growth, but something is definitely going on… we just need to figure out what it is.

Since you said you were doing testing, I’ll just through this out there- if you can, and would be willing, to get me access to launch the client remotely, I could run some more advanced profiling on it. If that’s not possible, there are a few other options: we could just turn the logger “Tags.History.Cache” to debug in the client (from Help>Diagnostics) and see if it says anything interesting as it starts to get slow, or you could use a tool like jmap to get a memory dump as it gets slow and then get that to us.

Feel free to PM me if you want to hash this out further.




I encounter quite the same problem on one of my project. It runs fine for a time but becomes slower and slower with time.

When the client gets slow, The diagnostic window show a hich memory consumption (~800 Mb) . As soon as I clear the tag cache through this window, speed comes back to normal.

The Tag cache is disabled in the Project properties.

Is there a method ( that could be used to automatically clear the tag cache (at least for the time I find where the problem comes from) ?

from com.inductiveautomation.ignition.common.sqltags.history.cache import TagHistoryCache