You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kylin.apache.org by "Dayue Gao (JIRA)" <ji...@apache.org> on 2016/10/11 12:30:20 UTC
[jira] [Created] (KYLIN-2083) more RAM estimation test for
MeasureAggregator and GTAggregateScanner
Dayue Gao created KYLIN-2083:
--------------------------------
Summary: more RAM estimation test for MeasureAggregator and GTAggregateScanner
Key: KYLIN-2083
URL: https://issues.apache.org/jira/browse/KYLIN-2083
Project: Kylin
Issue Type: Sub-task
Components: Tools, Build and Test
Affects Versions: v1.5.4.1
Reporter: Dayue Gao
Assignee: Dayue Gao
Fix For: v1.6.0
Current RAM estimations of MeasureAggregator and GTAggregateScanner are based on test results from AggregationCacheMemSizeTest. I'd like to see if there is room for improvement, and if there is, how much.
Points I'm considering are:
# CompressedOops on vs off: when CompressedOops is off on large heap, each reference takes 8 bytes. I was wondering how much it will affect size of AggregationCache.
# variable length aggregator: does the current estimation works well on var-len aggregator like BitmapAggregator
# heap usage count via GC vs Instrumentation: the current approach to obtain the actual heap usage of objects seems fine, however, I was wondering if using Java instrumentation agent will give us more precise number.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)