[OAK-2713] High memory usage of CompactionMap

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.0.15, 1.2.3, 1.3.0, 1.4
• Component/s: segmentmk
• Labels: compaction gc resilience
• Epic Link: SegmentMK revision GC
• Assignee: Michael Dürig
• Reporter: Michael Dürig
• Created: 31/Mar/15 14:26
• Updated: 16/Feb/21 09:52
• Resolved: 05/Jun/15 14:54

Description

In environments with a lot of volatile content the CompactionMap can end up eating a lot of memory. From CompactionStrategyMBean#getCompactionMapStats:

[Estimated Weight: 317,5 MB, Records: 39500094, Segments: 36698], 
[Estimated Weight: 316,4 MB, Records: 39374593, Segments: 36660], 
[Estimated Weight: 315,4 MB, Records: 39253205, Segments: 36620], 
[Estimated Weight: 315,1 MB, Records: 39221882, Segments: 36614], 
[Estimated Weight: 314,9 MB, Records: 39195490, Segments: 36604], 
[Estimated Weight: 315,0 MB, Records: 39182753, Segments: 36602], 
[Estimated Weight: 360 B, Records: 0, Segments: 0],

This causes compaction to be skipped:

2015-03-30:30.03.2015 02:00:00.038 *INFO* [] [TarMK compaction thread [/foo/bar/crx-quickstart/repository/segmentstore], active since Mon Mar 30 02:00:00 CEST 2015, previous max duration 3854982ms] org.apache.jackrabbit.oak.plugins.segment.file.FileStore Not enough available memory 5,5 GB, needed 6,3 GB, last merge delta 1,3 GB, so skipping compaction for now

Issue Links

• is blocked by: OAK-2662 SegmentOverflowException in HeavyWriteIT on Jenkins
• is related to: OAK-2723 FileStore does not scale because of precomputed graph on TarReader
• is related to: OAK-2862 CompactionMap#compress() inefficient for large compaction maps
• is related to: OAK-2967 Merge OAK-2800, OAK-2801, OAK-2692, OAK-2713
• relates to: OAK-2967 Merge OAK-2800, OAK-2801, OAK-2692, OAK-2713