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)