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:35:20 UTC
[jira] [Updated] (KYLIN-2083) more RAM estimation test for
MeasureAggregator and GTAggregateScanner
[ https://issues.apache.org/jira/browse/KYLIN-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dayue Gao updated KYLIN-2083:
-----------------------------
Description:
Current RAM estimations for 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 we can improve.
Points I'm interested in are:
# *CompressedOops ON v.s OFF*: when CompressedOops is off on large heap, each reference takes 8 bytes. I was wondering how much it will affect the RAM of AggregationCache.
# *Variable Length Aggregator*: does the current estimation works well on varlen aggregator like BitmapAggregator?
# *Real Heap Usage Count via Instrumentation*: the current approach to obtain the actual heap usage of objects looks fine, however, I was wondering if using Java instrumentation agent will give us a more precise number.
was:
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.
> 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 for 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 we can improve.
> Points I'm interested in are:
> # *CompressedOops ON v.s OFF*: when CompressedOops is off on large heap, each reference takes 8 bytes. I was wondering how much it will affect the RAM of AggregationCache.
> # *Variable Length Aggregator*: does the current estimation works well on varlen aggregator like BitmapAggregator?
> # *Real Heap Usage Count via Instrumentation*: the current approach to obtain the actual heap usage of objects looks fine, however, I was wondering if using Java instrumentation agent will give us a more precise number.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)