Kibana: [Search] Memory leaks caused by AbortController

Created on 4 May 2020  路  3Comments  路  Source: elastic/kibana

While digging into search code noticed potential improvements around requests cancelation:

  1. When firing search requests we subscribe to abort signal
abort.signal.addEventListener('abort', () => {
cancel()
}) 

But it could happen that client already asked to abort request and it seems to handle that case we have to handle it separately:

e.g.:

const { abortSignal = null } = requestOptionsMap.get(request) || {};
if (abortSignal) {
  if (abortSignal.aborted) {
    abort();
  } else {
    abortSignal.addEventListener('abort', abort);
  }
}

Such scenario happened to me in dashboard.

  1. I guess that every time we manually subscribe to abort event, we have to unsubscribe also? otherwise it is a memory leak. abortSignal.addEventListener('abort', abort);. note: RxJS fromEvent handle unsubscribe when we unsubscribe from observable.

To confirm this is needed, for example, fetch polyfill does this: https://github.com/github/fetch/blob/master/fetch.js#L534

Search AppServices bug high days triaged v7.9.0

Most helpful comment

While I was looking into https://github.com/elastic/kibana/issues/79498 I noticed that this memory leak issue is more significant than it could have seemed. (this issue is not related to #79498)

Every single search slowly leaks memory because of AbortController usage.

Most of leaks are a closure leak from abort utils

This is what I saw for a dashboard with a bunch of panels with a frequent refresh interval open for couple minutes:

Screenshot 2020-10-23 at 00 29 44

  • '>8500 AbortSignals left in memory
  • '>3263 AbortControllers left in memory

In general they retained 43mb in memory
This grows with every single search request, so I imagine this could crash large Kibana dashboards with frequent refresh intervals opened for a long time.

@lizozom @lukasolson, I think makes sense to prioritise this and tackle in this cycle.

All 3 comments

Pinging @elastic/kibana-app-arch (Team:AppArch)

Please note:
removing even listener inside 'abort' event callback won't be enough to fix memory leak issue.
Event listener also should be removed when request finishes: see

While I was looking into https://github.com/elastic/kibana/issues/79498 I noticed that this memory leak issue is more significant than it could have seemed. (this issue is not related to #79498)

Every single search slowly leaks memory because of AbortController usage.

Most of leaks are a closure leak from abort utils

This is what I saw for a dashboard with a bunch of panels with a frequent refresh interval open for couple minutes:

Screenshot 2020-10-23 at 00 29 44

  • '>8500 AbortSignals left in memory
  • '>3263 AbortControllers left in memory

In general they retained 43mb in memory
This grows with every single search request, so I imagine this could crash large Kibana dashboards with frequent refresh intervals opened for a long time.

@lizozom @lukasolson, I think makes sense to prioritise this and tackle in this cycle.

Was this page helpful?
0 / 5 - 0 ratings