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

Hello all, I wanted to circle back on this to post my findings after digging into the issue reported here:

TL;DR: No memory leaks were detected in the Time Series Chart or the underlying chart library components. Check any browser add-ons for known memory leaks and update/remove them (you can run a session in an incognito window as well).

Against the latest 8.1.1 codebase, I ran 2 different main tests (as well as multiple small sub tests), each totaling ~3 hours:

Test 1 - A Moderate Use Case Testing Resource Consumption Over Duration

  • Testing window opened in an incognito window to remove any add-ons that might influence the test results.
  • 3 tag history pens, each returning 1000 data points for the given time range (last 5 mins with 3 second polling).
  • Displaying just the series that is bound to the tag history data (showing 3 pens total).
  • Default axis built from data.
  • Chart date range displaying below the chart.

Test 1.1 - A Moderate Use Case Testing Momentary Memory Spikes (run multiple times over 3 hours)

  • All bullets listed in Test 1 above…
  • Started a performance profile.
  • Navigated back and forth between a view that displayed the chart mentioned above and a view displaying a simple icon (series of 6 roundtrip navigations w/o refreshing the browser).
  • Waited ~15 seconds for JS garbage collection. Repeated the previous step.
  • Waited ~15 seconds for JS garbage collection.
  • Captured the performance profile.

Test 2 - A Heavy Use Case Testing Resource Consumption Over Duration (run multiple times over 3 hours)

  • Testing window opened in an incognito window to remove any add-ons that might influence the test results.
  • 6 tag history pens, each returning 1000 data points for the given time range (last 5 mins with 3 second polling).
  • Displaying 4 total trends. The first 3 each contained 2 of the 6 pens, and displayed the tag history pens as line, area, and scatter charts (respectively). The final trend displayed all 6 tag history pens as bar charts. This totaled 12 displaying pens.
  • 2 defined axes and a single default axis were built and assigned to the trends.
  • Baselines and markers were added to each trend.
  • The chart legend was displaying.
  • The chart title was displaying.
  • Chart date range displaying below the chart

Test 2.1 - A Heavy Use Case Testing Momentary Memory Spikes

  • All bullets listed in Test 2 above…
  • Started a performance profile.
  • Navigated back and forth between a view that displayed the chart mentioned above and a view displaying a simple icon (series of 6 roundtrip navigations w/o refreshing the browser).
  • Waited ~15 seconds for JS garbage collection. Repeated the previous step.
  • Waited ~15 seconds for JS garbage collection.
  • Captured the performance profile.

Results of Test 1

For the duration part of the test, there was no additional JS memory consumption noticed. The JS memory in use remained at ~48MB with small changes accounting for the data being displayed within the chart at the time of the snapshot:

For the momentary memory spike part of the test, there was a stepping-up effect in both DOM node and JS memory heap allocation that did return back to a baseline level once the navigation between pages had stopped and garbage collection had run.

Results of Test 2

With this test, the data in the chart was not readable, but this was an attempt to cause the error noted in this bug. For the duration part of the test, there was no additional JS memory consumption noticed. The JS memory in use remained at ~75MB with small changes accounting for the data being displayed within the chart at the time of the snapshot:

For the momentary memory spike part of the test, there was a stepping-up effect in both DOM node and JS memory heap allocation that did return back to a baseline level once the navigation between pages had stopped and garbage collection had run. It’s worth noting that navigation between views took significantly longer because of the number of DOM nodes being displayed by the chart:

General Observations

  • I typically will trigger garbage collection about 7 times between taking snapshots as a way to baseline a JS memory heap or performance profile between snapshots, and that wasn’t necessary for these tests. The inner chart components clean themselves up quite efficiently.
  • I always search for detached DOM nodes across heap snapshots to see if any components maintain a reference to DOM nodes that have been removed, and the only observed change was from a component internal to React (FiberNode). Also a sign that the inner chart components clean themselves up quite efficiently.
3 Likes