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

Aggressively prune query info after completion #23257

Merged
merged 1 commit into from
Aug 19, 2024

Conversation

ZacBlanco
Copy link
Contributor

@ZacBlanco ZacBlanco commented Jul 19, 2024

Description

This change aggressively prunes query plan metadata before query expiry. It is mostly limited to query plan statistics.

With this change and with histograms enabled in #22365, this cuts the coordinator heap utilization by anywhere between 50% and 75% after running a portion of the TPC-DS benchmark (3-4GiB -> 600-800MiB)

Motivation and Context

Previously, we only pruned information from old queries after the expiration queue filled. With the addition of histograms query statistics can take two orders of magnitude more memory than previous statistics. Without pruning statistics we will much more quickly hit memory limits of the JVM.

Specifically, these are the areas where we try to clear references to save memory:

  • Session: planNodeStatsMap and planCostMapMap
  • QueryStateMachine: clear statistics from inputs and planStatsAndCosts
  • StateMachine: Once final queryInfo reaches a terminal state, we should clear the event listeners to release references to local variables which maintain the SqlQuerySchedule and Stage execution information
  • Prune all histograms from finalQueryInfo's planStatsAndCosts and from the entire StageInfo graph.

Fixes #23254

Impact

  • Results from the QueryInfo API after execution finishes will always return column statistics with empty histograms

Test Plan

  • Added a new test which verifies that a query completed event is generated before all queryInfo pruning is done

Contributor checklist

  • Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
  • PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
  • Documented new properties (with its default value), SQL syntax, functions, or other functionality.
  • If release notes are required, they follow the release notes guidelines.
  • Adequate tests were added if applicable.
  • CI passed.

Release Notes

== NO RELEASE NOTE ==

@ZacBlanco ZacBlanco changed the title Aggressively prune statistics from query info after completion Aggressively prunequery info after completion Jul 19, 2024
@ZacBlanco ZacBlanco changed the title Aggressively prunequery info after completion Aggressively prune query info after completion Jul 19, 2024
@ZacBlanco ZacBlanco force-pushed the upstream-prune-query-info branch 2 times, most recently from 9165744 to 6cfe291 Compare July 19, 2024 07:00
@ZacBlanco ZacBlanco marked this pull request as ready for review July 19, 2024 20:53
@ZacBlanco ZacBlanco requested a review from a team as a code owner July 19, 2024 20:53
Copy link
Contributor

@aaneja aaneja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check (and maybe add/link me to a test that asserts) that the queryCompletedEvent is fired before the query info pruning is done ?

@tdcmeehan tdcmeehan self-assigned this Jul 25, 2024
aaneja
aaneja previously approved these changes Jul 25, 2024
hantangwangd
hantangwangd previously approved these changes Jul 25, 2024
Copy link
Member

@hantangwangd hantangwangd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just one nit.

new RuntimeStats()),
Optional.empty(),
Optional.empty(),
ImmutableMap.of(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tangential and non-blocking, but I'd like to get in the habit of using Collections.emptyMap instead of ImmutableList.of to reduce our dependence on and vulnerability to third party libraries. ImmutableMap.of hasn't been needed for years now.

Copy link
Contributor Author

@ZacBlanco ZacBlanco Jul 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is the case, then we should update the contributing guide to state that:

* Prefer Immutable collections in Guava when possible. For example, instead of using

Optional.empty(),
Optional.empty(),
ImmutableMap.of(),
ImmutableSet.of(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Collections.emptySet

ImmutableSet.of(),
StatsAndCosts.empty(),
ImmutableList.of(),
ImmutableList.of(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Collections.emptyList

Optional.empty(),
null,
EXCEEDED_GLOBAL_MEMORY_LIMIT.toErrorCode(),
ImmutableList.of(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here you can use Arrays.asList
It's just a test so immutability doesn't help

@ZacBlanco ZacBlanco dismissed stale reviews from hantangwangd and aaneja via 394ba9f July 25, 2024 19:39
hantangwangd
hantangwangd previously approved these changes Jul 26, 2024
Copy link
Member

@hantangwangd hantangwangd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix.

@ZacBlanco ZacBlanco force-pushed the upstream-prune-query-info branch 2 times, most recently from d597d84 to e3d09ad Compare August 16, 2024 14:31
@ZacBlanco ZacBlanco force-pushed the upstream-prune-query-info branch 2 times, most recently from 1927346 to e2b9965 Compare August 16, 2024 14:40
Previously, we only pruned information from old queries after
the expiration queue filled. With more the addition of histograms
query statistics can take two orders of magnitude more memory
than previous statistics. Without pruning statistics we will
much more quickly hit memory limits of the JVM.

This change aggressively prunes query plan metadata before query
expiry. This is mostly limited to query plan statistics.
@tdcmeehan tdcmeehan merged commit 56223eb into prestodb:master Aug 19, 2024
56 checks passed
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

Successfully merging this pull request may close these issues.

Histograms can consume significant amounts of memory in query history
6 participants