[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091003#comment-14091003 ] stack commented on HBASE-5349: -- [~anoop.hbase] I think we should enable by default, at least in master branch. What you think? A policy that sizes the blockcache so there are no evictions OR we hit maxsize would be sweet. I could add that. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091061#comment-14091061 ] Lars Hofhansl commented on HBASE-5349: -- +1 to always enable. This is important for HBase and that way we'll issues if any. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847621#comment-13847621 ] stack commented on HBASE-5349: -- I think this feature should be on by default. If it is off no one will enable it because they'll be afraid of what it might do. It should be on because it takes away a need to twiddle knobs. Regards what happens to GC'ing profile when there is a seismic shift in size of blockcache/memstore, the point [~xieliang007] raises, its a valid concern; can we flag it as concern in doc (If GC'ing sensitive or If low-latency serving...) and release note it and then spend some time seeing how bad it is in action? Any way we could have a shift in config balance out? i.e. block cache allocations some subset of memstore allocations so no more fragmentation Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846176#comment-13846176 ] Hudson commented on HBASE-5349: --- SUCCESS: Integrated in HBase-TRUNK #4720 (See [https://builds.apache.org/job/HBase-TRUNK/4720/]) HBASE-5349 Automagically tweak global memstore and block cache sizes based on workload (anoopsamjohn: rev 1550059) * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/trunk/hbase-common/src/main/resources/hbase-default.xml * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/DoubleBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/ResizableBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultHeapMemoryTuner.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/FlushRequestListener.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/FlushRequester.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryManager.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryTuner.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreChunkPool.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846393#comment-13846393 ] stack commented on HBASE-5349: -- bq. seems if we tweak block cache dynamically, it's more prone to trigger a gc that moment, right? Makes sense. We will be disturbing whatever equilibrium that may have been in place. But if the workload has changed such that it has us changing configs., would that alone bring on a GC? I suppose we should have a high friction on the tweaks. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846474#comment-13846474 ] Nick Dimiduk commented on HBASE-5349: - [Feedback Control|http://www.amazon.com/Feedback-Control-Computer-Systems-Philipp/dp/1449361692/] seems like good reading. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846947#comment-13846947 ] Andrew Purtell commented on HBASE-5349: --- bq. seems if we tweak block cache dynamically, it's more prone to trigger a gc that moment, right? This is largely out of our control, until and unless the JVM exposes some knobs for GC and early warning signals. Between memstore and blockcache we can't just look at occupancy. We can provide a null tuner to remove this as a factor when getting to the bottom of excessive GCs though. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847058#comment-13847058 ] Liang Xie commented on HBASE-5349: -- bq. We can provide a null tuner to remove this as a factor when getting to the bottom of excessive GCs though. thanks Andrew, i definitely like this feature, and still, if one production cluster has a lower enough 99th latency requirement considering gc factor, a null tuner probably must be provided? :) Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847111#comment-13847111 ] Andrew Purtell commented on HBASE-5349: --- bq. if one production cluster has a lower enough 99th latency requirement considering gc factor, a null tuner probably must be provided? You bet [~xieliang007], see HBASE-10151 Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847167#comment-13847167 ] Anoop Sam John commented on HBASE-5349: --- By default the auto tuning is turned off. One need to give the below 4 configs so as to define the range of heap %. hbase.regionserver.global.memstore.size.max.range and hbase.regionserver.global.memstore.size.min.range using which one can specify the total heap % within which the memstore size can vary. hfile.block.cache.size.max.range and hfile.block.cache.size.min.range using which one can specify the total heap % within which the block cache size can vary. There is no default values for these and so by default there wont be automatic tuning happening. Is that good enough [~xieliang007] Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847196#comment-13847196 ] Liang Xie commented on HBASE-5349: -- Ok, my concern is gone now. thanks all for reply:) I haven't learned the code yet, but the idea/feature is pretty cool absolutely ! Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845495#comment-13845495 ] Andrew Purtell commented on HBASE-5349: --- Nice work Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845832#comment-13845832 ] Hudson commented on HBASE-5349: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-1.1 #4 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/4/]) HBASE-5349 Automagically tweak global memstore and block cache sizes based on workload (anoopsamjohn: rev 1550059) * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/trunk/hbase-common/src/main/resources/hbase-default.xml * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/DoubleBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/ResizableBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultHeapMemoryTuner.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/FlushRequestListener.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/FlushRequester.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryManager.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryTuner.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreChunkPool.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13846111#comment-13846111 ] Liang Xie commented on HBASE-5349: -- seems if we tweak block cache dynamically, it's more prone to trigger a gc that moment, right? Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[
https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844155#comment-13844155
]
Hadoop QA commented on HBASE-5349:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12618009/HBASE-5349_V5.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8119//console
This message is automatically generated.
Automagically tweak global memstore and block cache sizes based on workload
---
Key: HBASE-5349
URL: https://issues.apache.org/jira/browse/HBASE-5349
Project: HBase
Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Anoop Sam John
Fix For: 0.99.0
Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch,
HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch
Hypertable does a neat thing where it changes the size given to the CellCache
(our MemStores) and Block Cache based on the workload. If you need an image,
scroll down at the bottom of this link:
http://www.hypertable.com/documentation/architecture/
That'd be one less thing to configure.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844418#comment-13844418 ] Andrew Purtell commented on HBASE-5349: --- +1 for trunk Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844583#comment-13844583 ] Sergey Shelukhin commented on HBASE-5349: - +1 Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844857#comment-13844857 ] Ted Yu commented on HBASE-5349: --- Anoop: Can you update release notes ? Thanks Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845029#comment-13845029 ] Anoop Sam John commented on HBASE-5349: --- Thanks for the reviews. I have to make a next version addressing few comments from Ram. Sure Ted I will add the release notes. Any more comments [~stack] ? Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845030#comment-13845030 ] Anoop Sam John commented on HBASE-5349: --- The pending comment from Ram is a minor one. I will fix it on commit Ram. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845075#comment-13845075 ] stack commented on HBASE-5349: -- [~anoop.hbase] I am good on commit to trunk. Go for it. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845086#comment-13845086 ] Lars Hofhansl commented on HBASE-5349: -- Nice milestone towards 1.0. :) +1 Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13845130#comment-13845130 ] ramkrishna.s.vasudevan commented on HBASE-5349: --- +1 on commit. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Fix For: 0.99.0 Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch, HBASE-5349_V4.patch, HBASE-5349_V5.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[
https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13842961#comment-13842961
]
Hadoop QA commented on HBASE-5349:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12617789/HBASE-5349_V4.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestSplitLogWorker
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8097//console
This message is automatically generated.
Automagically tweak global memstore and block cache sizes based on workload
---
Key: HBASE-5349
URL: https://issues.apache.org/jira/browse/HBASE-5349
Project: HBase
Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Anoop Sam John
Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch,
HBASE-5349_V4.patch, WIP_HBASE-5349.patch
Hypertable does a neat thing where it changes the size given to the CellCache
(our MemStores) and Block Cache based on the workload. If you need an image,
scroll down at the bottom of this link:
http://www.hypertable.com/documentation/architecture/
That'd be one less thing to configure.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[
https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13842933#comment-13842933
]
Hadoop QA commented on HBASE-5349:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12617779/HBASE-5349_V3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8095//console
This message is automatically generated.
Automagically tweak global memstore and block cache sizes based on workload
---
Key: HBASE-5349
URL: https://issues.apache.org/jira/browse/HBASE-5349
Project: HBase
Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Anoop Sam John
Attachments: HBASE-5349_V2.patch, HBASE-5349_V3.patch,
WIP_HBASE-5349.patch
Hypertable does a neat thing where it changes the size given to the CellCache
(our MemStores) and Block Cache based on the workload. If you need an image,
scroll down at the bottom of this link:
http://www.hypertable.com/documentation/architecture/
That'd be one less thing to configure.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[
https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789131#comment-13789131
]
Anoop Sam John commented on HBASE-5349:
---
{quote}
I can see making the Interface public but do the implementations have to be
public too?
-public class LruBlockCache implements BlockCache, HeapSize {
+public class LruBlockCache implements ResizableBlockCache, HeapSize {
They are not instantiated outside of the hfile package?
{quote}
You mean LruBlockCache to be public or not right? It was already public. I can
see it is being referred in some test cases outside hfile package
bq.Call it DefaultHeapMemoryBalancer instead of DefaultHeapMemoryBalancerImpl I
would say.
Done
bq.Nit: does the context need both blocked and unblocked? + boolean
memstoreSufficient = blockedFlushCount == 0 unblockedFlushCount == 0;
The current impl of the Tuner does not distinguish this. But Why I added it as
2 counts is to support more Tuner impl work (later?) Right now when both
memstore and block cache is under preassure we wont do any tuning. May be there
also some tuning can be done if blockedFlushCount is large. Blocked flush
blocks the writes to memstore.. Just to keep the door open I made this way :)
bq.You have this comment twice '// Increase the block cache size and
corresponding decrease in memstore size' One must be wrong (smile)
Copy paste.. :) Corrected
bq.Reading DefaultHeapMemoryBalancerImpl, we keep stepping w/o regard for a
max. Is max enforced elsewhere? If so, will DefaultHeapMemoryBalancerImpl keep
asking to step though we are against the max? Maybe this is fine. It makes the
implementation 'easier' which is good. Should we log when we want to 'step'? Or
is that done outside of DefaultHeapMemoryBalancerImpl (which would probably be
better... again keep it simple)
Yes I was intended to add check in HeapMemoryTuner#chore(). (The logging also).
Adding it now. Also added check in DefaultHeapMemoryBalancer itself. When the
HeapMemoryBalancer asks for step but the max limit is reached, I am making a
warn log now. May be I can change this to INFO level (?) IMO logging is enough
no other action is needed. Any suggestion? ( This is there in Ted's comment
also)
{quote}
Does the HeapMemoryManager have to have these two members?
+ private final MemStoreFlusher memStoreFlusher;
+ private final HRegionServer hrs;
Can it not take Interface that has just what it needs? Else makes it hard to
test this new code in isolation. At a minimum the HRS can be replaces by
Service or RegionServerService Interface? Is that possible? And FlushRequester
instead of MemStoreFlusher?
{quote}
Good point. Thanks I am making hrs to be of type Server which is enough.
private final Server server;
private final FlushRequester memStoreFlusher;
bq.Perhaps drop the 'Auto' prefix from AutoTunerContext and AutoTunerResult.
The users of these Interfaces don't care if it Auto or not. Ditto here:
HeapMemoryAutoTuner... call it HeapMemoryTuner.
Done
{quote}
These should be private since server side?
+@InterfaceAudience.Public
+@InterfaceStability.Evolving
+public interface HeapMemoryBalancer
{quote}
I wanted the impl of this balancer to be pluggable so that users can impl there
own way like LoadBalancer. LoadBalancer marked as @InterfaceAudience.Public.
Just followed that. As it is server side we need to make private? I am not
sure of the guideline for this. If this is to be private I can change NP.
bq.Should there be a kill switch for the tuner? You pass in absolute values and
once set, it stops balancing (for the case were the tuner turns pathological
and an operator wants to turn it off while the server is online). We could do
that in another issue np.
Yes very much. This is needed. I have identified it as a subtask in my earlier
comment (6. Support turn ON/OFF the memory tuner at run time.) This is not done
yet. May be once this is done, as another issue or sub task this can be done.
bq.These do not need to be public classes + public static final class
AutoTunerContext { and AutoTunerResult?
This Context is passed to the HeapMemoryBalancer impl (which can be pluggable)
and it needs to return the result. Making the class non public will force the
impl can be to in the same package. Is that fine? That is why I kept it public
{quote}
This seems like informational rather than a warn?
+ LOG.warn(Current heap configuration from HeapMemoryBalancer exceeds
+ + the threshold required for successful cluster operation.
+ + The combined value cannot exceed 0.8. + MemStoreFlusher.MEMSTORE_SIZE_KEY
+ + is + memstoreSize + and + HConstants.HFILE_BLOCK_CACHE_SIZE_KEY +
is
+ + blockCacheSize);
{quote}
Fine. INFO
bq.Do you need to shut it down? + startHeapMemoryManager(); Or it doesn't
matter?
It doen't matter as of now as the balancer thread is daemon. But I will add
shutdown also and call from HRS.
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789136#comment-13789136 ] Anoop Sam John commented on HBASE-5349: --- Will put in RB soon. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Attachments: HBASE-5349_V2.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13789268#comment-13789268 ] Anoop Sam John commented on HBASE-5349: --- https://reviews.apache.org/r/14533/ Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Attachments: HBASE-5349_V2.patch, WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761642#comment-13761642 ] Anoop Sam John commented on HBASE-5349: --- Stack Ted thanks for the review.. Working on the comments and also adding tests. Will update the patch soon. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Attachments: WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[
https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760641#comment-13760641
]
Ted Yu commented on HBASE-5349:
---
There're ^M's at the end of each line. Please generate patch on Linux.
For HeapMemoryAutoTuner:
It would be nice to put the patch on review board.
{code}
+ AutoTunerContext context = createTunerContext();^M
{code}
Do we need to create new context for each iteration of the chore ? Can one
instance be reused ?
{code}
+LOG.debug(From HeapMemoryBalancer new memstoreSize: + memstoreSize
+ %. new blockCacheSize: + blockCacheSize + %);^M
{code}
I think the percent sign is not needed.
{code}
+if (1 - (memstoreSize + blockCacheSize)
HConstants.HBASE_CLUSTER_MINIMUM_MEMORY_THRESHOLD) {^M
+ LOG.warn(Current heap configuration from HeapMemoryBalancer exceeds
^M
+ + the threshold required for successful cluster operation. ^M
{code}
Should some action be taken for the above case ? Otherwise tuning is
effectively disabled.
Since memstoreSize and blockCacheSize are local variables, I would expect some
action when result.needsTuning() returns true.
For DefaultHeapMemoryBalancerImpl, please add javadoc and audience annotation.
{code}
+ result.setMemstoreSize(context.getCurMemStoreSize() - step);^M
{code}
Should we check that the decrement would not produce negative result ?
Please add unit tests for the new classes.
Automagically tweak global memstore and block cache sizes based on workload
---
Key: HBASE-5349
URL: https://issues.apache.org/jira/browse/HBASE-5349
Project: HBase
Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Anoop Sam John
Attachments: WIP_HBASE-5349.patch
Hypertable does a neat thing where it changes the size given to the CellCache
(our MemStores) and Block Cache based on the workload. If you need an image,
scroll down at the bottom of this link:
http://www.hypertable.com/documentation/architecture/
That'd be one less thing to configure.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[
https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13760836#comment-13760836
]
stack commented on HBASE-5349:
--
I can see making the Interface public but do the implementations have to be
public too?
-public class LruBlockCache implements BlockCache, HeapSize {
+public class LruBlockCache implements ResizableBlockCache, HeapSize {
They are not instantiated outside of the hfile package?
Call it DefaultHeapMemoryBalancer instead of DefaultHeapMemoryBalancerImpl I
would say.
It looks like you change configuration names but you handle the case where
users still have the old names; that is good.
Nit: does the context need both blocked and unblocked? +boolean
memstoreSufficient = blockedFlushCount == 0 unblockedFlushCount == 0;
You have this comment twice '// Increase the block cache size and corresponding
decrease in memstore size' One must be wrong (smile)
Reading DefaultHeapMemoryBalancerImpl, we keep stepping w/o regard for a max.
Is max enforced elsewhere? If so, will DefaultHeapMemoryBalancerImpl keep
asking to step though we are against the max? Maybe this is fine. It makes
the implementation 'easier' which is good. Should we log when we want to
'step'? Or is that done outside of DefaultHeapMemoryBalancerImpl (which would
probably be better... again keep it simple)
Does the HeapMemoryManager have to have these two members?
+ private final MemStoreFlusher memStoreFlusher;
+ private final HRegionServer hrs;
Can it not take Interface that has just what it needs? Else makes it hard to
test this new code in isolation. At a minimum the HRS can be replaces by
Service or RegionServerService Interface? Is that possible? And
FlushRequester instead of MemStoreFlusher?
Perhaps drop the 'Auto' prefix from AutoTunerContext and AutoTunerResult. The
users of these Interfaces don't care if it Auto or not. Ditto here:
HeapMemoryAutoTuner... call it HeapMemoryTuner.
These should be private since server side?
+@InterfaceAudience.Public
+@InterfaceStability.Evolving
+public interface HeapMemoryBalancer
Should there be a kill switch for the tuner? You pass in absolute values and
once set, it stops balancing (for the case were the tuner turns pathological
and an operator wants to turn it off while the server is online). We could do
that in another issue np.
Should there be a 'damping' facility? That is, should we run the check more
often and only make changes if we have been called ten times and on 8 or the 10
times, we judged we should 'step'? That could be a different implementation I
suppose? Or conversely, do you think there should be an 'emergency' chain that
can be pulled when we need to change the configs now? (This latter is probably
not a good idea -- at least not yet).
We need to get rid of Chore and have one thread only that does all these tasks
-- we have a load of them running now on each server -- or do them via
executor... but that is out of scope of this issue.
These do not need to be public classes + public static final class
AutoTunerContext { and AutoTunerResult?
This seems like informational rather than a warn?
+ LOG.warn(Current heap configuration from HeapMemoryBalancer exceeds
+ + the threshold required for successful cluster operation.
+ + The combined value cannot exceed 0.8. +
MemStoreFlusher.MEMSTORE_SIZE_KEY
+ + is + memstoreSize + and +
HConstants.HFILE_BLOCK_CACHE_SIZE_KEY + is
+ + blockCacheSize);
Make one log rather than two since they change in lockstep:
+ LOG.info(Setting block cache heap size to + newBlockCacheSize);
...
+ LOG.info(Setting memstore heap size to + newMemstoreSize);
Do you need to shut it down? + startHeapMemoryManager(); Or it doesn't
matter?
Does the interface need to be public
+public interface MemstoreFlushListener {
(Lars Francke went through and cleaned the public from all our Interface
methods... etc., so would be nice not to undo his work).
Needs tests. Hopefully you can change the above references to MemstoreFlusher
and RegionServer to be Interfaces so you do not need to spin up a cluster to
test (you are almost there).
I am a big fan of this patch. Good work Anoop. Thanks for doing this.
Automagically tweak global memstore and block cache sizes based on workload
---
Key: HBASE-5349
URL: https://issues.apache.org/jira/browse/HBASE-5349
Project: HBase
Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jean-Daniel Cryans
Assignee: Anoop Sam John
Attachments: WIP_HBASE-5349.patch
Hypertable does a neat thing where it changes the size given to the CellCache
(our
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13753978#comment-13753978 ] Ted Yu commented on HBASE-5349: --- There were 6 subtasks identified above. How many were addressed by the WIP patch ? Thanks Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Attachments: WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754363#comment-13754363 ] Anoop Sam John commented on HBASE-5349: --- Ted 1-5 are addressed. Thanks Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Attachments: WIP_HBASE-5349.patch Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13744064#comment-13744064 ] Anoop Sam John commented on HBASE-5349: --- Configurations -- For on heap block cache there is a config value. ie. what is the max heap space and defaults to 40%. Now we need to have a config item to read a min heap space for block cache. In fact this is not the min heap space which at least will be always reserved for the block cache. This is the min value the auto tuner can turn down the block cache size up to. hfile.block.cache.size - Current config to specify the Percentage of maximum heap (-Xmx setting) to allocate to block cache Now we need 2 more configs to specify a range for this above value. And the above config item will continue to be there. hfile.block.cache.size.max.range hfile.block.cache.size.min.range By default when HBase starts, the block cache will be allocated a size of hfile.block.cache.size (As current way). Later the auto tuner can change this btw the max range and min range values. If hfile.block.cache.size.max.range=hfile.block.cache.size.min.range=hfile.block.cache.size auto tuning for block cache will be turned off. (And thus for memstore also) Memstore having a higher and lower water mark now. Higher water mark is a max heap size now itself. But lower water mark is not. This is the heap size when it reached, we will start flushes to prevent the memstore reaching the higher water mark. Once the memstore size reaches higher water mark, we will block all updates. Now we need a min heap size also The current configs are hbase.regionserver.global.memstore.upperLimit and hbase.regionserver.global.memstore.lowerLimit We need to introduce 2 new configs hbase.regionserver.global.memstore.size.max.range and hbase.regionserver.global.memstore.size.min.range Also we can rename hbase.regionserver.global.memstore.upperLimit to hbase.regionserver.global.memstore.size (?) By default when HBase starts it will allocate a global memstore size = hbase.regionserver.global.memstore.size as now (BC with old config name also will be provided). The auto tuner can change this btw the max and min range. And the lower watermark can no longer be a % of the total heap size. This needs to be a % of the max heap size(Higher water mark ie. hbase.regionserver.global.memstore.size). At any point in time the actual heap space will be having some value btw max and min range. The lower water mark % should result to a heap space lesser than the actual max heap space for global memstore and we should start the flushes at this point of time (as we do today). So we should rename this config name also. - hbase.regionserver.global.memstore.size.lower.limit - % of the hbase.regionserver.global.memstore.size at which we will start flushes to avoid stop the world flushes. For BC we will continue to support hbase.regionserver.global.memstore.lowerLimit which is a % of the total JVM heap space. On init we can convert this value to a % of the hbase.regionserver.global.memstore.size. The default value for this lower limit can be 95% of the global memstore size. (Default values for hbase.regionserver.global.memstore.upperLimit and hbase.regionserver.global.memstore.lowerLimit are 40% and 38% respectively) Init check now is block cache size + higher water mark =80% This should become hbase.regionserver.global.memstore.size + hfile.block.cache.size = 80% AND hbase.regionserver.global.memstore.size.max.range + hfile.block.cache.size.min.range = 80% AND hbase.regionserver.global.memstore.size.min.range + hfile.block.cache.size.max.range = 80% At any time the heap size of the block cache + that of memstore =80% We can have a HeapMemoryManager On HRS start, this also can be started. This Manager can track the block cache evictions (Can get from CacheStats). Also the memstore flushes can be tracked. MemstoreFlusher should support changing the global memstore size. Also the BlockCache can be resizable. This manager should support a pluggable HeapMemoryBalancer using which the new value for memstore and block cache sizes can be determined. When there is a change in the heap size, those can be set on MemstoreFlusher/BlockCache HeapMemoryBalancer A custom implementation for this can be plugged using config param. hbase.regionserver.memory.balancer.class The default impl can do the checks for the memory adjustment by comparing the block cache evictions against the flushes for memstores due to global heap pressure. Normal flushes due to one memstore reaching the flush size is a normal op and should not get accounted in the above checks. Only the flushes because of global heap pressure (blocked or no blocked) should get accounted Also a configurable time interval in which this tuner will
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13744072#comment-13744072 ] Anoop Sam John commented on HBASE-5349: --- Subtask identified as of now 1. Support MemstoreFLush listener Listeners should be able to be registered. When the flush happens, the listeners should get notified. The notification may include on which region the flush happened and the flush type. The types can be like whether a normal flush or a flush due to global pressure (unblocked or blocked) 2. Support resizable BlockCache Resizing can be supported for all BlockCache types which are on heap cache. LRUBlockCache is onheap type. Also DoubleBlockCache having onheap LRUCache along with off heap cache. So DoubleBlockCache also can be resizable. 3. Support specifying global memstore lower watermark as a % of global memstore upper limit Now memstore lower watermark is specified as a % of the max heap size and defaults to 38%.(Default upper water mark memstore size is 40%) We need to change this behavior so as to specify lower water mark as a % of the upper water mark limit. (The default can be 95% (ie. 0.38/0.4 * 100) 4. Support size range for memstore size and block cache size Support min and max values for memstore size and block cache size. The auto tuner can adjust the cache size to a value in btw these ranges. 5. Support pluggable auto tuner There should be an interface based auto tuner impl. Configuring the FQCN of the impl in hbase-site.xml allows user to provide a custom impl for the auto tuner. Also provide a default impl which will decide the cache sizes based on the memstore flushes (due to global heap pressure) and block cache evictions 6. Support turn ON/OFF the memory tuner at run time. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13738522#comment-13738522 ] Anoop Sam John commented on HBASE-5349: --- Working on a proto type now. Will come up with the low level impl details soon. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662819#comment-13662819 ] Anoop Sam John commented on HBASE-5349: --- Looks to be great for us. Will start working on this. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Assignee: Anoop Sam John Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13648756#comment-13648756 ] Jean-Daniel Cryans commented on HBASE-5349: --- If anyone is looking for a good jira to solve, this is one. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257085#comment-13257085 ] Enis Soztutar commented on HBASE-5349: -- I have been thinking about this, and I think we can have a shot at a simple implementation. Let me summarize what I have in mind before starting the implementation: Goals: - Provide min - max heap percentages for block cache (memstore kind of has it). I think we should keep max-min sanity bounds, and if they are equal, disable auto-tuning. - enable optimizing the available memory for adaptive workloads (mostly writes during the day, a lot of reads once MR job starts, etc). For example, when a large write job is started after ~10 minutes, region servers should tune for write workload. Non-goals: - find the optimum mem-utilization algorithm - introduce a bunch of other parameters, to get rid of the current ones - make it very experimental so that nobody enables it in production. Ideally, to optimize the usage of the available memory, we should predict the future workload (possibly from past workload), and devise a model capturing all the costs associated with block cache hits / misses, flushes, compactions, etc. But this model will be very complex to do it properly. I have checked Hypertable's implementation, and it seems that they check whether the load is read/write heavy by some hard coded values for the counters, and increment/decrement the mem limits, much like what Zhihong proposes above. I also want to start with something similar. Implementation layer: - Currently global memstore limit is a soft limit, we may have to make it a hard limit (blocking writes) - we should enable incrementing / decrementing and setting global memstore and block cache maximum limits. We do not have live configuration changes, but regardless of auto-tuning, we should be able to manually set those online. - Periodically we should check past workload (like past 10 min), and depending on whether it is write heavy or read heavy (from metrics), adjust the mem limits in small intervals. What do you guys think? Still worth pursuing? Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.96.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257103#comment-13257103 ] Zhihong Yu commented on HBASE-5349: --- This is a plan worth pursuing. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.96.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257219#comment-13257219 ] stack commented on HBASE-5349: -- I wouldn't mind more detail. Can our LRU be resized? Memstore upper bound can vary but there are interesting effects like if its too big, flushing can take so long, the memstore fills before we get around to flushing it again so we block. Nit: 10 minutes seems like too coarse a granularity? Good stuff Enis. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.96.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214944#comment-13214944 ] Jean-Daniel Cryans commented on HBASE-5349: --- @Mubarak We already have that through HeapSize, it's really just a matter of knowing what to auto-tune and when. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215220#comment-13215220 ] stack commented on HBASE-5349: -- Chatting w/ J-D about a phenomenon where we do not use memory when we are taking on a bunch of writes w/ a low region count. The few regions we have grow to their max of 128M or so and then we flush but in his case he had gigs of free memory still. The notion is that we should let memstores grow to fill all available space and then flush when they hit the low-water global mem mark for the memstore. The problem then becomes we'll flush lots of massive files and will overwhelm compactions. We'll need a push-back, something like a flush-merge where we flush by rewriting an existing store file interleaving the contents of memory or some such to slow down the flush but also to make for less compaction to do. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204740#comment-13204740 ] Mubarak Seyed commented on HBASE-5349: -- For reference: Cassandra 1.0.0 supports self-tunes memtable sizes ([CASSANDRA-2787|https://issues.apache.org/jira/browse/CASSANDRA-2787]). It uses Java agent ([Jamm|https://github.com/jbellis/jamm]) Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204070#comment-13204070 ] Zhihong Yu commented on HBASE-5349: --- We currently don't maintain moving average of read/write requests per region server. What should be an effective measure for determining read vs. write heavy workload ? Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204078#comment-13204078 ] Zhihong Yu commented on HBASE-5349: --- w.r.t. the measure for determining workload, should the measure be computed solely based on one region server ? Or should this measure be relative to the workload on other region servers ? Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204087#comment-13204087 ] Jean-Daniel Cryans commented on HBASE-5349: --- Good question, I don't think looking at requests is good enough... instead we could look at how both are used and if there's adjustment to be made. For example, if you have a read heavy workload then the memstores would not see a lot of usage... same with write heavy, the block cache would be close to empty. Those two are clear cuts, now for those workloads in between it gets a bit harder. Maybe at first we shouldn't even try to optimize them. I think it should also be done incrementally, move like 3-5% of the heap from one place to the other every few minutes until it settles. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5349) Automagically tweak global memstore and block cache sizes based on workload
[ https://issues.apache.org/jira/browse/HBASE-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204325#comment-13204325 ] Zhihong Yu commented on HBASE-5349: --- I am thinking of introducing rolling counters (using circular buffer) for both MemStore and LruBlockCache. We record the number of flushes (for MemStore) and evictions (for LruBlockCache), respectively. Every 1 (configurable) minute, we roll the counters. It should be straight forward to observe whether MemStore or LruBlockCache is under pressure by looking at the trend of the rolling counters. Once we determine the one under pressure, we can utilize what J-D described above to shift heap among the two. We can also introduce weights between MemStore and LruBlockCache for the rolling counters. Automagically tweak global memstore and block cache sizes based on workload --- Key: HBASE-5349 URL: https://issues.apache.org/jira/browse/HBASE-5349 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0 Reporter: Jean-Daniel Cryans Fix For: 0.94.0 Hypertable does a neat thing where it changes the size given to the CellCache (our MemStores) and Block Cache based on the workload. If you need an image, scroll down at the bottom of this link: http://www.hypertable.com/documentation/architecture/ That'd be one less thing to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
