[
https://issues.apache.org/jira/browse/KUDU-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089152#comment-18089152
]
ASF subversion and git services commented on KUDU-3429:
-------------------------------------------------------
Commit 3396d19fb3cae30ffddb1de1e8c4632645aea710 in kudu's branch
refs/heads/master from Ashwani
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=3396d19fb ]
KUDU-3429 Fix rowset compaction memory accounting (2/n)
The patch fixes the following:
- 'delta_blocks_mem_size()' does double accounting of the CFile block
buffer by adding Slice::val again when it is already accounted for
inside DeltaFileIterator::delta_blocks_mem_size_. The Slice::val field
is a zero-copy view of CFile block buffer and not a separate memory
area where block data is stored. Remove additional buffer sizes.
- Keep memory accounting calculation for prepare_deltas_ separate from
delta_blocks_mem_size_ to avoid scenarios where delta block buffers
are freed (inside FreeDeltaBlocks) while struct overhead for entries
in prepared_deltas_ remain until preparation of next batch starts.
So, even after clearing of delta blocks , memory_footprint() still
reflects surviving PreparedDelta struct overhead.
- 'peak_mem_usage' doesn't show the correct peak of memory usage of a
rowset compaction operation. It leaves out base-data arena and
ApplyMutations arena contributions that the tracker does capture.
MergeCompactionInput::max_memory_usage_ is sampled at FinishBlock()
time when all the DRS delta blocks are not residing in memory
simultaneously. Instead, make use of tracker's peak_consumption() that
takes into consideration all the big consumers of memory during a
rowset merge compaction operation.
- After fixing the double-counting in delta_blocks_mem_size(), tracker
value is lower and the old '3 MB' constant is no longer reliably
exceeded for tests in compaction-highmem-test. Set the threshold
(compaction_mem_usage_approx) to a value that is reliably below the
minimum tracked allocation during compaction run.
- Pre-account for the arena's initial component so that the first
PrepareBlock's Reset() produces a correctly-signed delta.
Change-Id: Icc2133d38ed766f6834392a2e335d9246b511456
Reviewed-on: http://gerrit.cloudera.org:8080/24330
Tested-by: Marton Greber <[email protected]>
Reviewed-by: Zoltan Martonka <[email protected]>
Reviewed-by: Marton Greber <[email protected]>
> Refactor CompactRowSetsOp to run on a pre-determined memory budget
> -------------------------------------------------------------------
>
> Key: KUDU-3429
> URL: https://issues.apache.org/jira/browse/KUDU-3429
> Project: Kudu
> Issue Type: Improvement
> Reporter: Alexey Serbin
> Assignee: Ashwani Raina
> Priority: Major
>
> [KUDU-3406|https://issues.apache.org/jira/browse/KUDU-3406] added memory
> budgeting for running CompactRowSetsOp maintenance operations. On its
> nature, that provides an interim approach adding memory budgeting on top of
> the current CompactRowSetsOp implementation as-is.
> Ideally, the implementation of CompactRowSetsOp should be refactored to merge
> the deltas in participating rowsets sequentially, chunk by chunk, persisting
> the results and allocating memory just for small bunch of processed deltas,
> not loading all the deltas at once.
> This JIRA item is to track the work in the context outlined above.
> Key points to address in this scope:
> * even if it's a merge-like operation by its nature, the current
> implementation of CompactRowSetsOp allocates all the memory necessary to load
> the UNDO deltas at once, and it keeps all the preliminary results in the
> memory as well before persisting the result data to disk
> * the current implementation of CompactRowSetsOp loads all the UNDO deltas
> from the rowsets selected for compaction regardless whether they are ancient
> or not; it discards of the data sourced from the ancient deltas in the very
> end before persisting the result data
> Also, while keeping memory usage on a predetermined budget, the new
> implementation for CompactRowSetsOp should strive to avoid IO multiplication
> as much as possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
