-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
colexec: fix memory leak in simpleProjectOp
This commit fixes a bounded memory leak in `simpleProjectOp` that has been present since 20.2 version. The leak was introduced via the combination of - 57eb4f8 in which we began tracking all batches seen by the operator so that we could decide whether we need to allocate a fresh projecting batch or not - 895125b in which we started using the dynamic sizing for batches (where we'd start with size 1 and grow exponentially until 1024 while previously we would always use 1024). Both changes combined made it so that the `simpleProjectOp` would keep _all_ batches with different sizes alive until the query shutdown. The problem later got more exacerbated when we introduced dynamic batch sizing all over the place (for example, in the spilling queue). Let's discuss the reasoning for why we needed something like the tracking we did in the first change mentioned above. The simple project op works by putting a small wrapper (a "lense") `projectingBatch` over the batch coming from the input. That wrapper can be modified later by other operators (for example, a new vector might be appended), which would also modify the original batch coming from the input, so we need to allow for the wrapper to be mutated accordingly. At the same time, the input operator might decide to produce a fresh batch (for example, because of the dynamically growing size) which wouldn't have the same "upstream" mutation applied to it, so we need to allocate a fresh projecting batch and let the upstream do its modifications. In the first change we solved it by keeping a map from the input batch to the projecting batch. This commit addresses the same issue by only checking whether the input batch is the same one as was seen by the `simpleProjectOp` on the previous call. If they are the same, then we can reuse the last projecting batch; otherwise, we need to allocate a fresh one and memoize it. In other words, we effectively reduce the map to have at most one entry. This means that with dynamic batch size growth we'd create a few `projectingBatch` wrappers, but that is ok given that we expect the dynamic size heuristics to quickly settle on the size. This commit adjusts the contract of `Operator.Next` to explicitly mention that implementations should reuse the same batch whenever possible. This is already the case pretty much everywhere, except when the dynamic batch size grows or shrinks. Before we introduced the dynamic batch sizing, different batches could only be produced by the unordered synchronizers, so that's another place this commit adjusts. If we didn't do anything, then the simplistic mapping with at most one entry could result in "thrashing" - i.e. in the extreme case where the inputs to the synchronizer would produce batches in round-robin fashion, we'd end up creating a new `projectingBatch` every time which would be quite wasteful. In this commit we modify both the parallel and the serial unordered synchronizers to always emit the same output batch which is populated by manually inserting vectors from the input batch. I did some manual testing on the impact of this change. I used a table and a query (with some window functions) from the customer cluster that has been seeing some OOMs. I had one node cluster running locally with `--max-go-memory=256MiB` (so that the memory needed by the query was forcing GC all the time since it exceeded the soft memory limit) and `distsql_workmem=128MiB` (since we cannot spill to disk some state in the row-by-row window functions). Before this patch I observed the max RAM usage at 1.42GB, and after this patch 0.56GB (the latter is pretty close to what we report on EXPLAIN ANALYZE). Release note (bug fix): Bounded memory leak that could previously occur when evaluating some memory-intensive queries via the vectorized engine in CockroachDB has now been fixed. The leak has been present since 20.2 version.
- Loading branch information
1 parent
0f54637
commit 7026921
Showing
10 changed files
with
78 additions
and
42 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters