Easy Chart with long time frame (days) uses much RAM and CPU

Using Ignition 7.6.7, various versions of Java 7, on various versions of Windows.

If a long time range (especially some number of days) is selected for the data display of the Easy Chart, the memory and CPU usage goes very high. In some cases the system set with a 5 day interval can only run for a few hours before the CPU is at 100%, the RAM is almost at 100% and then the Ignition clients are unresponsive.

My test system has 8GB RAM, maximum Java heap size in ignition.conf was increased from 2GB to 4GB and I have increased the maximum client memory from 1GB to 2GB with same results. 2GB is the maximum selectable client memory size for Ignition 7.6.7. Naturally we would need more than 8GB RAM on the computer to set it higher anyway.

Are there any recommendations that we can do for a customer that would like to see these large time ranges in the Easy Chart but not run into such large resource usage?

Thank you,

You might try reducing the rate of your historical scan classes (for example, if the client can tolerate 3s data instead of 0.03s data, then you reduce the load on your historian significantly).

I am assuming you are querying SQL data (I believe tag history will automatically interpolate).
What I do in this situation is create a custom property (integer) on the root container called “DateRangeSelected.”
Expression Binding: dateDiff({Root Container.Easy Chart.startDate},{Root Container.Easy Chart.endDate},‘day’)/5
This returns a truncated integer equal to the number of 5 day periods in the selected date range on the chart. Decrease the divisor to decrease the number of data points returned by the final query. If you want to get really aggressive with it you could use the datediff to show hours, minutes etc.

In this example, the SQL table called “Table” has the default ID “table_ndx.” Bind the “Where Clause” property of your Easy Chart to the following:
‘(table_ndx % ‘+{Root Container.DateRangeSelected}+’) = 0’

The Easy Chart will return the nth row of the SQL table it is querying based on the size of the daterange. Far from perfect but it is sufficient in most cases for my charts with lots of data.


Thank you for the reply, I did look at this. These systems are pretty busy with lots of tag values, so currently with my historical scan classes at 5s, I still have the issue.


I can see where this could work well for the situation. I will give this a try.

Many thanks.