[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14985608#comment-14985608 ] Elliott Clark commented on HBASE-13876: --- The test fixes in here make the memstore tests less flakey ( see also HBASE-14742). I'm going to pull this into branch-1.2 in order to try and get that branch stable. > Improving performance of HeapMemoryManager > -- > > Key: HBASE-13876 > URL: https://issues.apache.org/jira/browse/HBASE-13876 > Project: HBase > Issue Type: Improvement > Components: hbase, regionserver >Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 >Reporter: Abhilash >Assignee: Abhilash >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, > HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, > HBASE-13876-v7.patch, HBASE-13876.patch > > > I am trying to improve the performance of DefaultHeapMemoryTuner by > introducing some more checks. The current checks under which the > DefaultHeapMemoryTuner works are very rare so I am trying to weaken these > checks to improve its performance. > Check current memstore size and current block cache size. For say if we are > using less than 50% of currently available block cache size we say block > cache is sufficient and same for memstore. This check will be very effective > when server is either load heavy or write heavy. Earlier version just waited > for number of evictions / number of flushes to be zero which are very rare. > Otherwise based on percent change in number of cache misses and number of > flushes we increase / decrease memory provided for caching / memstore. After > doing so, on next call of HeapMemoryTuner we verify that last change has > indeed decreased number of evictions / flush either of which it was expected > to do. We also check that it does not make the other (evictions / flush) > increase much. I am doing this analysis by comparing percent change (which is > basically nothing but normalized derivative) of number of evictions and > number of flushes during last two periods. The main motive for doing this was > that if we have random reads then we will be having a lot of cache misses. > But even after increasing block cache we wont be able to decrease number of > cache misses and we will revert back and eventually we will not waste memory > on block caches. This will also help us ignore random short term spikes in > reads / writes. I have also tried to take care not to tune memory if do do > not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986054#comment-14986054 ] Hudson commented on HBASE-13876: SUCCESS: Integrated in HBase-1.2-IT #258 (See [https://builds.apache.org/job/HBase-1.2-IT/258/]) HBASE-13876 Improving performance of HeapMemoryManager (eclark: rev b7ef854fed3dd147b70395a3b296e1a64ad25ac6) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/RollingStatCalculator.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultHeapMemoryTuner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java > Improving performance of HeapMemoryManager > -- > > Key: HBASE-13876 > URL: https://issues.apache.org/jira/browse/HBASE-13876 > Project: HBase > Issue Type: Improvement > Components: hbase, regionserver >Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 >Reporter: Abhilash >Assignee: Abhilash >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, > HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, > HBASE-13876-v7.patch, HBASE-13876.patch > > > I am trying to improve the performance of DefaultHeapMemoryTuner by > introducing some more checks. The current checks under which the > DefaultHeapMemoryTuner works are very rare so I am trying to weaken these > checks to improve its performance. > Check current memstore size and current block cache size. For say if we are > using less than 50% of currently available block cache size we say block > cache is sufficient and same for memstore. This check will be very effective > when server is either load heavy or write heavy. Earlier version just waited > for number of evictions / number of flushes to be zero which are very rare. > Otherwise based on percent change in number of cache misses and number of > flushes we increase / decrease memory provided for caching / memstore. After > doing so, on next call of HeapMemoryTuner we verify that last change has > indeed decreased number of evictions / flush either of which it was expected > to do. We also check that it does not make the other (evictions / flush) > increase much. I am doing this analysis by comparing percent change (which is > basically nothing but normalized derivative) of number of evictions and > number of flushes during last two periods. The main motive for doing this was > that if we have random reads then we will be having a lot of cache misses. > But even after increasing block cache we wont be able to decrease number of > cache misses and we will revert back and eventually we will not waste memory > on block caches. This will also help us ignore random short term spikes in > reads / writes. I have also tried to take care not to tune memory if do do > not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14986213#comment-14986213 ] Hudson commented on HBASE-13876: SUCCESS: Integrated in HBase-1.2 #339 (See [https://builds.apache.org/job/HBase-1.2/339/]) HBASE-13876 Improving performance of HeapMemoryManager (eclark: rev b7ef854fed3dd147b70395a3b296e1a64ad25ac6) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/RollingStatCalculator.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultHeapMemoryTuner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java > Improving performance of HeapMemoryManager > -- > > Key: HBASE-13876 > URL: https://issues.apache.org/jira/browse/HBASE-13876 > Project: HBase > Issue Type: Improvement > Components: hbase, regionserver >Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 >Reporter: Abhilash >Assignee: Abhilash >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, > HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, > HBASE-13876-v7.patch, HBASE-13876.patch > > > I am trying to improve the performance of DefaultHeapMemoryTuner by > introducing some more checks. The current checks under which the > DefaultHeapMemoryTuner works are very rare so I am trying to weaken these > checks to improve its performance. > Check current memstore size and current block cache size. For say if we are > using less than 50% of currently available block cache size we say block > cache is sufficient and same for memstore. This check will be very effective > when server is either load heavy or write heavy. Earlier version just waited > for number of evictions / number of flushes to be zero which are very rare. > Otherwise based on percent change in number of cache misses and number of > flushes we increase / decrease memory provided for caching / memstore. After > doing so, on next call of HeapMemoryTuner we verify that last change has > indeed decreased number of evictions / flush either of which it was expected > to do. We also check that it does not make the other (evictions / flush) > increase much. I am doing this analysis by comparing percent change (which is > basically nothing but normalized derivative) of number of evictions and > number of flushes during last two periods. The main motive for doing this was > that if we have random reads then we will be having a lot of cache misses. > But even after increasing block cache we wont be able to decrease number of > cache misses and we will revert back and eventually we will not waste memory > on block caches. This will also help us ignore random short term spikes in > reads / writes. I have also tried to take care not to tune memory if do do > not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603890#comment-14603890 ] Ted Yu commented on HBASE-13876: Logged HBASE-13980. Let's continue discussion there. Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Fix For: 2.0.0, 1.3.0 Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876-v7.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603789#comment-14603789 ] Abhilash commented on HBASE-13876: -- I was thinking about that too. Rather than giving more weightage to blockedFlushCount, can we just directly increase(if favorable) memstore size when we observe blocked flushes ? As even a single blockedFlushCount very strongly indicates that current upper limit for memstore is not sufficient and its highly undesirable ? Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Fix For: 2.0.0, 1.3.0 Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876-v7.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603748#comment-14603748 ] Ted Yu commented on HBASE-13876: Currently DefaultHeapMemoryTuner doesn't distinguish blockedFlushCount vs unblockedFlushCount. Should more weight be given to blockedFlushCount ? Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Fix For: 2.0.0, 1.3.0 Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876-v7.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14590777#comment-14590777 ] Hudson commented on HBASE-13876: FAILURE: Integrated in HBase-1.3 #5 (See [https://builds.apache.org/job/HBase-1.3/5/]) HBASE-13876 Improving performance of HeapMemoryManager (eclark: rev 212cbf8f5c3e26cc002088a118f9e99158b276bb) * hbase-server/src/main/java/org/apache/hadoop/hbase/util/RollingStatCalculator.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultHeapMemoryTuner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Fix For: 2.0.0, 1.3.0 Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876-v7.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14590545#comment-14590545 ] Hudson commented on HBASE-13876: SUCCESS: Integrated in HBase-TRUNK #6580 (See [https://builds.apache.org/job/HBase-TRUNK/6580/]) HBASE-13876 Improving performance of HeapMemoryManager (eclark: rev 623fd63827b2953c150597f24c7205737119bebe) * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HeapMemoryManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultHeapMemoryTuner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/RollingStatCalculator.java Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Fix For: 2.0.0, 1.3.0 Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876-v7.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588552#comment-14588552 ] Elliott Clark commented on HBASE-13876: --- +1. lgtm Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876-v7.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581710#comment-14581710
]
Hadoop QA commented on HBASE-13876:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12738995/HBASE-13876-v5.patch
against master branch at commit 349cbe102a130b50852201e84dc7ac3bea4fc1f5.
ATTACHMENT ID: 12738995
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestRegionRebalancing
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14378//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14378//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14378//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14378//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v5.patch,
HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. For say if we are
using less than 50% of currently available block cache size we say block
cache is sufficient and same for memstore. This check will be very effective
when server is either load heavy or write heavy. Earlier version just waited
for number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush either of which it was expected
to do. We also check that it does not make the other (evictions / flush)
increase much. I am doing this analysis by comparing percent change (which is
basically nothing but normalized derivative) of number of evictions and
number of flushes during last two periods. The main motive for doing this was
that if we have random reads then we will be having a lot of cache misses.
But even after increasing block cache we wont be able to decrease number of
cache misses and we will revert back and eventually we will not waste memory
on block caches. This will also help us ignore random short term spikes in
reads / writes. I have also tried to take care not to tune memory if do do
not have enough hints as unnecessary tuning my slow down the system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581503#comment-14581503 ] Abhilash commented on HBASE-13876: -- Reattached the patch because it passes that failed test on my machine. Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v5.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. If we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush ( combined). I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582893#comment-14582893
]
Hadoop QA commented on HBASE-13876:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12739151/HBASE-13876-v6.patch
against master branch at commit 9d3422ed16004da1b0f9a874a98bd140b46b7a6f.
ATTACHMENT ID: 12739151
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14385//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14385//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14385//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14385//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v5.patch,
HBASE-13876-v6.patch, HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. For say if we are
using less than 50% of currently available block cache size we say block
cache is sufficient and same for memstore. This check will be very effective
when server is either load heavy or write heavy. Earlier version just waited
for number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush either of which it was expected
to do. We also check that it does not make the other (evictions / flush)
increase much. I am doing this analysis by comparing percent change (which is
basically nothing but normalized derivative) of number of evictions and
number of flushes during last two periods. The main motive for doing this was
that if we have random reads then we will be having a lot of cache misses.
But even after increasing block cache we wont be able to decrease number of
cache misses and we will revert back and eventually we will not waste memory
on block caches. This will also help us ignore random short term spikes in
reads / writes. I have also tried to take care not to tune memory if do do
not have enough hints as unnecessary tuning my slow down the system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582778#comment-14582778 ] Abhilash commented on HBASE-13876: -- Using stats from few past lookup periods(configurable) to decide tuner step. Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876-v5.patch, HBASE-13876-v6.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. For say if we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush either of which it was expected to do. We also check that it does not make the other (evictions / flush) increase much. I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. I have also tried to take care not to tune memory if do do not have enough hints as unnecessary tuning my slow down the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580394#comment-14580394
]
Hadoop QA commented on HBASE-13876:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12738766/HBASE-13876-v3.patch
against master branch at commit 4713fc6407450825b1907c833ca60d0cc604b5be.
ATTACHMENT ID: 12738766
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1914 checkstyle errors (more than the master's current 1912 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14364//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14364//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14364//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14364//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580173#comment-14580173
]
Hadoop QA commented on HBASE-13876:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12738758/HBASE-13876-v2.patch
against master branch at commit 4713fc6407450825b1907c833ca60d0cc604b5be.
ATTACHMENT ID: 12738758
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:red}-1 javac{color}. The patch appears to cause mvn compile goal to
fail with Hadoop version 2.4.1.
Compilation errors resume:
[ERROR] COMPILATION ERROR :
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java:[1381,41]
method create in class org.apache.hadoop.hbase.regionserver.HeapMemoryManager
cannot be applied to given types;
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on
project hbase-server: Compilation failure
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java:[1381,41]
method create in class org.apache.hadoop.hbase.regionserver.HeapMemoryManager
cannot be applied to given types;
[ERROR] required:
org.apache.hadoop.conf.Configuration,org.apache.hadoop.hbase.regionserver.FlushRequester,org.apache.hadoop.hbase.Server,org.apache.hadoop.hbase.regionserver.RegionServerAccounting
[ERROR] found:
org.apache.hadoop.conf.Configuration,org.apache.hadoop.hbase.regionserver.MemStoreFlusher,org.apache.hadoop.hbase.regionserver.HRegionServer
[ERROR] reason: actual and formal argument lists differ in length
[ERROR] - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn goals -rf :hbase-server
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14362//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v1.patch, HBASE-13876-v2.patch,
HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580793#comment-14580793
]
Ted Yu commented on HBASE-13876:
{code}
76 || context.getCurMemStoreUsed()*2
context.getCurMemStoreSize();
{code}
How is 50% determined ? In other words, if 51% of memstore is used, why would
we consider memstore size insufficient ?
When stepDirectionIndicator is true, block cache size is to be increased. Would
using an enum make the code more readable ?
{code}
94float percentChangeInEvictCount =
(float)(evictCount-prevEvictCount)/(float)(evictCount);
{code}
Should the right hand side be
'(float)(evictCount-prevEvictCount)/(float)(prevEvictCount)' ?
Similar comment applies to the calculation of percentChangeInFlushes and
percentChangeInMisses.
{code}
110 // try to balance changes in number of cache misses and
flushes
111 stepDirectionIndicator = percentChangeInMisses
percentChangeInFlushes;
{code}
What if percentChangeInMisses and percentChangeInFlushes are both negative ? In
that case there is no need to change direction, right ?
Would it make sense to introduce NEUTRAL direction which doesn't require tuning
for the current iteration ?
Putting the patch on review board would make reviewing easier.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580846#comment-14580846 ] Abhilash commented on HBASE-13876: -- Thanks a lot for the reviews. Going to use ENUM and introducing NEUTRAL step to remove unnecessary tuning. Which will have better use of the final variable tolerance. Thinking about how to remove constants like 50%. Possibly provide a static final member to adjust the range when we say memstore/block cache is sufficient or not. I was using current value of number of evictCount and number of flushes because they are non zero if program enter that block but previous evictCount and flushes may be zero. Thinking about how to use previous values without introducing lots of checks. Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. If we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush ( combined). I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581176#comment-14581176
]
Elliott Clark commented on HBASE-13876:
---
* tolerance should be configurable and I don't think that 0 is going to be the
correct value.
* line 141 compare them to tolerance.
* For line 140 - 154 It would be easier to reason about the percent if you
don't add them but rather compare them to tolerance
so instead of something like:
{code}if (percentChangeInEvictCount + percentChangeInFlushes tolerance){code}
something like
{code}if ( precentChanceInEvictCount 0 percentChangeInEvictCount
tolerance precentChangeInFlushes 0 Math.abs(percentChangeInFlushes)
tolerance){code}
* Need to make sure that no two calls to tune will ever run concurrently.
* Probably easier to have a variable like prevTuneDirection rather than using
the same variable for both meanings.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876-v4.patch, HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581219#comment-14581219 ] Elliott Clark commented on HBASE-13876: --- bq.Point of adding up percent changes was that in most of cases when we try to decrease evictCounts by increasing blockCache size the number of flushes increases so that would help to create balance But it's possible that both increase. Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. If we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush ( combined). I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581260#comment-14581260
]
Hadoop QA commented on HBASE-13876:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12738923/HBASE-13876-v4.patch
against master branch at commit 0f93986015122a517e1a0c949e159bf8fb218092.
ATTACHMENT ID: 12738923
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1913 checkstyle errors (more than the master's current 1912 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 4 zombie test(s):
at
org.apache.hadoop.hbase.coprocessor.TestCoprocessorInterface.testSharedData(TestCoprocessorInterface.java:290)
at
org.apache.hadoop.hbase.replication.regionserver.TestReplicationWALReaderManager.test(TestReplicationWALReaderManager.java:181)
at
org.apache.hadoop.hbase.wal.TestWALSplit.testLogsGetArchivedAfterSplit(TestWALSplit.java:654)
at
org.apache.hadoop.hbase.wal.TestWALSplit.testSplitLogFileFirstLineCorruptionLog(TestWALSplit.java:1056)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14373//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14373//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14373//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14373//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876-v4.patch, HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581207#comment-14581207 ] Abhilash commented on HBASE-13876: -- Thanks a lot for the reviews. Point of adding up percent changes was that in most of cases when we try to decrease evictCounts by increasing blockCache size the number of flushes increases so that would help to create balance. For example suppose after increasing block cache size we have significant increase in number of flushes ( more than tolerance level ) but at the same time we have very huge decrease in cache misses ( maybe we were using cache size just less than working set size ) separating them would lead to no tuner operation in such cases. Trying to implement other suggestions. Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch, HBASE-13876-v4.patch, HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. If we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited for number of evictions / number of flushes to be zero which are very rare. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush ( combined). I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then we will be having a lot of cache misses. But even after increasing block cache we wont be able to decrease number of cache misses and we will revert back and eventually we will not waste memory on block caches. This will also help us ignore random short term spikes in reads / writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581217#comment-14581217
]
Ted Yu commented on HBASE-13876:
bq. but at the same time we have very huge decrease in cache misses
Two percentages are maintained: change in eviction count and change in cache
misses.
{code}
+if (percentChangeInEvictCount + percentChangeInFlushes tolerance) {
{code}
Did you intend to use percentChangeInMisses in the above check ?
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876-v4.patch, HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581450#comment-14581450
]
Hadoop QA commented on HBASE-13876:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12738974/HBASE-13876-v5.patch
against master branch at commit 399fc34802aa755e28806548e10181e5fb92.
ATTACHMENT ID: 12738974
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14377//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14377//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14377//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14377//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876-v2.patch, HBASE-13876-v3.patch,
HBASE-13876-v4.patch, HBASE-13876-v5.patch, HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[
https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579739#comment-14579739
]
Hadoop QA commented on HBASE-13876:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12738662/HBASE-13876.patch
against master branch at commit 14fe23254a78c52bdaef0da819268c8b405059cb.
ATTACHMENT ID: 12738662
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1913 checkstyle errors (more than the master's current 1912 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestHeapMemoryManager
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14350//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14350//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14350//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14350//console
This message is automatically generated.
Improving performance of HeapMemoryManager
--
Key: HBASE-13876
URL: https://issues.apache.org/jira/browse/HBASE-13876
Project: HBase
Issue Type: Improvement
Components: hbase, regionserver
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1
Reporter: Abhilash
Assignee: Abhilash
Priority: Minor
Attachments: HBASE-13876.patch
I am trying to improve the performance of DefaultHeapMemoryTuner by
introducing some more checks. The current checks under which the
DefaultHeapMemoryTuner works are very rare so I am trying to weaken these
checks to improve its performance.
Check current memstore size and current block cache size. If we are using
less than 50% of currently available block cache size we say block cache is
sufficient and same for memstore. This check will be very effective when
server is either load heavy or write heavy. Earlier version just waited for
number of evictions / number of flushes to be zero which are very rare.
Otherwise based on percent change in number of cache misses and number of
flushes we increase / decrease memory provided for caching / memstore. After
doing so, on next call of HeapMemoryTuner we verify that last change has
indeed decreased number of evictions / flush ( combined). I am doing this
analysis by comparing percent change (which is basically nothing but
normalized derivative) of number of evictions and number of flushes during
last two periods. The main motive for doing this was that if we have random
reads then we will be having a lot of cache misses. But even after increasing
block cache we wont be able to decrease number of cache misses and we will
revert back and eventually we will not waste memory on block caches. This
will also help us ignore random short term spikes in reads / writes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13876) Improving performance of HeapMemoryManager
[ https://issues.apache.org/jira/browse/HBASE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579645#comment-14579645 ] Elliott Clark commented on HBASE-13876: --- stepDirection is pretty weirdly named for a boolean. If you aren't using RegionServerStub delete it. Is it possible to make TestHeapMemoryManager still only used mock'd HRegionServer? If possible it would be good to not use HRegionServer, and instead break that out into a different interface. Or use an already existing interface. Needs tests for the new cases. Nits: * Indention is off. * Spaces after // Improving performance of HeapMemoryManager -- Key: HBASE-13876 URL: https://issues.apache.org/jira/browse/HBASE-13876 Project: HBase Issue Type: Improvement Components: hbase, regionserver Affects Versions: 2.0.0, 1.0.1, 1.1.0, 1.1.1 Reporter: Abhilash Assignee: Abhilash Priority: Minor Attachments: HBASE-13876.patch I am trying to improve the performance of DefaultHeapMemoryTuner by introducing some more checks. The current checks under which the DefaultHeapMemoryTuner works are very rare so I am trying to weaken these checks to improve its performance. Check current memstore size and current block cache size. If we are using less than 50% of currently available block cache size we say block cache is sufficient and same for memstore. This check will be very effective when server is either load heavy or write heavy. Earlier version just waited to for number of evictions / number of flushes to be zero which is very rare to happen. Otherwise based on percent change in number of cache misses and number of flushes we increase / decrease memory provided for caching / memstore. After doing so, on next call of HeapMemoryTuner we verify that last change has indeed decreased number of evictions / flush ( combined). I am doing this analysis by comparing percent change (which is basically nothing but normalized derivative) of number of evictions and number of flushes during last two periods. The main motive for doing this was that if we have random reads then even after increasing block cache we wont be able to decrease number of cache misses and eventually we will not waste memory on block caches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
