Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LQP and/or PQP caches take up GBs #2178

Closed
5 tasks
mrks opened this issue Jun 30, 2020 · 5 comments
Closed
5 tasks

LQP and/or PQP caches take up GBs #2178

mrks opened this issue Jun 30, 2020 · 5 comments

Comments

@mrks
Copy link
Member

mrks commented Jun 30, 2020

I was investigating why the memory consumption was increasing constantly and not dropping to idle levels between different TPC-H items:

Screenshot 2020-06-30 at 17 45 59

The biggest jump in the orange line is TPC-H 15. I then ran ./hyriseBenchmarkTPCH -q 14,15,16 --metrics -o bothcaches.json on the current master:

bothcaches

For Q15, you can see the point where all query variations are cached. As there are only 58 of them, it seems as if each takes 13 MB.

Here it is with the PQP cache disabled:

lqponly

And here without any plan caching:

nocaches

Thoughts:

  • Check why the LQP cache entries are that big in the first place.
  • Evict more aggressively?
  • Track actual cache size to help with eviction decisions?
  • Does query parametrization help?
  • How to detect these issues in the future?
@mrks
Copy link
Member Author

mrks commented Jul 8, 2020

More thoughts:

  • Some operators (Delete, Insert, UnionPositions?) store their input tables. Operators should not do that, as it prevents tables from being released. If they do, they should at least implement _on_cleanup. Not sure how to enforce this.
  • This gets aggravated when these operators are cached. Should we move to a model where a deep copy of the PQP is stored in the PQP cache? That would prevent operators that do not properly clean up after themselves from wasting memory once they are in the cache and only used for reproduction (hihi). However, it might make @Bouncner and @Bensk1 sad.
  • The last operator's output is cached indefinitely as OperatorTask only calls clear_output on predecessors.
  • Work done so far can be found in mrks/caching_explosion

@mrks
Copy link
Member Author

mrks commented Nov 11, 2020

Should ~SQLPipelineStatement call clear_output on the top operator? @julianmenzler

@julianmenzler
Copy link
Member

For Q15, you can see the point where all query variations are cached. As there are only 58 of them, it seems as if each takes 13 MB.

The current changes of #2254 seem to have reduced the memory consumption for Q15. Per query variation, from 13 MB down to ~1.5 MB.

metrics

@mrks
Copy link
Member Author

mrks commented Mar 9, 2021

@julianmenzler Fixed in #2254?

@julianmenzler
Copy link
Member

julianmenzler commented Mar 10, 2021

@julianmenzler Fixed in #2254?

I think so:

bothcaches_master

(TPC-H SF 1, 7cfa1a5)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants