Time Series Chart Memory Leak?

Are there any known memory leaks in the time series chart? We have seen after adding one to our application that the memory usage keeps increasing and eventually the enter Perspective session becomes unusable. Killing chrome and restart appears to resolve the issue.

Is the time series chart using the same amcharts library as the rest of the chart objects?

We haven’t observed any memory leaks yet. The Time Series chart uses the react-timeseries-charts library (specific to time series data) as opposed to the amCharts library. If you’re seeing this happening pretty consistently, would you be willing to share a view that is causing the behavior as well as the version of Ignition and browser you are using?

8.0.10 with Chrome V83. Sorry for all the white out.

One of our engineers was monitoring the heap with Chrome dev tools and found the DOM nodes jumped significantly when navigating to the screen and they don’t appear to drop out.

I can provide a little more information on this issue (same application as above). Leaving the displayed screen open doesn’t appear to cause Chrome’s memory to get too large, but going in and out of the screen (and perhaps other screens) seems to eventually cause the memory to grow very large (over 1.6GB seems to be an issue and we’ve seen it grow over 2.2GB), rendering the application useless until Chrome can be killed and restarted. Therefore this may not be explicitly tied to the Time Series Chart, but considering that is a screen being used a lot that is where people are noticing the major slow down.

I see this bug in 8.0.6. but it seems fixed in 8.0.12 finally.
Please try it in 8.0.12 and tell us if you see this or not.

I will have to wait to try this as 8.0.11+ resulted in poor carousel performance which I need to wait for a resolution on before I can move on from 8.0.10.

I made a handful of updates to the underlying chart library for 8.0.12 that allowed proper propagation of property value changes. For the most part, garbage collection is pretty good with the time series charts. There were some overall performance improvements made in 8.0.12 and 8.0.13 that should result in better browser memory management. This will continue in 8.0.14 as well.

I’ve not had a chance to try the newer versions yet (still on 8.0.10) but just wanted to provide a little more information. It appears the issue gets worse by going in and out of the view with the trend on it. Specifically, what we notice by looking in Chrome Dev Mode is that the DOM Nodes increment up when going in and out of the screen. When the trend is active on the screen the DOM Nodes climb up, then reset back to a lower value. However, when going in and out of the screen the “baseline” DOM Nodes that it resets to end up higher than before. This seems to happen with other views as well, though perhaps not as bad. Sometimes, but not always the JS Heap size will also grow quite large. The end result is that once the overall memory usage by Chrome gets too high the performance is severely degraded and chrome needs to be restarted to work well again.

2 Likes

I was able to upgrade to v 8.0.14 and the problem with Chrome slowing down to a point of being unusable still persists. The hardware being used has 4GB RAM. As I said previously the application becomes pretty slow around 1.6GB or so of usage in Chrome and is definitely an issue above 2GB.

Thanks for the feedback @kyle.demerath. We will set up some tests on our end to isolate the issue.

Were you ever able to isolate the issue on your end?

I have a ticket open (work not started) to scrutinize the fork of underlying library that I maintain. There were no major performance concerns found when we picked this library to use as a rendering layer, but I’ve fixed bugs as I’ve found them.

1 Like