[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020868#comment-16020868 ] Hudson commented on HBASE-18056: FAILURE: Integrated in Jenkins build HBase-HBASE-14614 #244 (See [https://builds.apache.org/job/HBase-HBASE-14614/244/]) HBASE-18056 Make the default behavior of CompactionPipeline to merge it (anastas: rev 1520c8fd4dd70206ab1abdf3eed81d6dc302990b) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreCompactor.java > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018964#comment-16018964 ] Anastasia Braginsky commented on HBASE-18056: - Dear [~anoop.hbase], I would like to deeply apologize, as it looks like I disregarded your comments, while I didn't meant to. I saw no answer from you for about 3 days. I have committed this small change, before you raised your last comment. I didn't see your comment on time. I will make a comment next time before commit. I also just completely didn't see this issue as critical. We already had a long discussion and long benchmark and agreed about it on HBASE-16417. So happened that our conclusion there did not yet made it from theory to practice. I was surprised by myself to find this constant being not 1. I was sure it is already 1. I saw it completely as a technical issue that doesn't need a discussion (because we already did all the discussions), so I didn't wait for 2 +1. As it looks like you would like reopen this issue, I would suggest to leave the limit to be 1 for now, but when you finish your tests and present your results, showing any other conclusion than our, we will just change the constant. What do you think? Or you think this need to be reverted? Thanks, Anastasia > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018956#comment-16018956 ] Edward Bortnikov commented on HBASE-18056: -- Friends, I'm having a hard time understanding why this commit became a big deal :) We made a mistake. This parameter change should have been committed together with BASIC compaction becoming the default configuration. BASIC does not make sense without it. We presented a vey extensive perf evaluation exactly with this parameter value. It demonstrated improvement in all the operational metrics, GC included. The parameter should be not accessible to users; it is not documented in the reference manual; its sole purpose is developer flexibility. It is perfectly okay to re-open the discussion (and also revert the setting) once there is solid proof that something is broken. But we didn't see any such proof yet. Delaying without reason jeopardizes the feature, especially in anticipation of release. Just saying it again - we made a technical mistake, and we are fixing it now. There is no new data. What is it that I get wrong? Thanks. > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018926#comment-16018926 ] Anoop Sam John commented on HBASE-18056: Is this committed already? 1. I have raised a concern already (before also) on 1 being the default value for the pipeline threshold for the merge 2. It is a practice to write comment abt the commit and close the issue while committing 3. For this kind of critical changes, it would be better to wait for at least 2 +1s > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018881#comment-16018881 ] Hudson commented on HBASE-18056: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #3051 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3051/]) HBASE-18056 Make the default behavior of CompactionPipeline to merge it (anastas: rev 1520c8fd4dd70206ab1abdf3eed81d6dc302990b) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreCompactor.java > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018807#comment-16018807 ] Anoop Sam John commented on HBASE-18056: This patch changes the threshold to 1 (default value) which is too low. Am not in favor of a change to 1 any way. Will be testing this in coming days. > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018768#comment-16018768 ] Eshcar Hillel commented on HBASE-18056: --- I think we are missing the point here. The original need for merge in the pipeline was the degradation in *read* performance when we didn't use merge. The GC is not the issue here, but for sure we demonstrated in the benchmark that doing merge is not increasing GC and has no negative effect on write performance https://issues.apache.org/jira/browse/HBASE-16417?focusedCommentId=15929565&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15929565 Using/not using MSLABs is also not the issue here since the merge is only at the index level, it doesn't remove duplicates and its affect is the same whether data is stored on MSLABs or not. +1 for this patch, it is only pushing a solution we already agreed on. Without it we have a problem with the high percentiles of reads, and I didn't see any reasonable explanation or evidence that it causes any issues in any other settings. > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[
https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015672#comment-16015672
]
Hadoop QA commented on HBASE-18056:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 47s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 123m 5s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
32s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 169m 14s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12868713/HBASE-18056-V01.patch
|
| JIRA Issue | HBASE-18056 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux b58289cfe46b 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 32d2062 |
| Default Java | 1.8.0_131 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6828/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6828/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
> --
>
> Key: HBASE-18056
> URL: https://issues.apache.org/jira/browse/HBASE-18056
> Project: HBase
> Issue Type: Sub-task
>
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015485#comment-16015485 ] Anastasia Braginsky commented on HBASE-18056: - When 2 segments are merged together only CellArrayMap is rebuilt, all the cells remain in place whether on MSLAB or on JVM heap. Regarding why GC works better with merge, we have a theory, and this theory is supported with performance numbers. Of course we cannot ensure this theory in 100%. So this is the theory: In case of merge, let's say each of old CellArayMaps was of size 1KB and new CellArrayMap has size 2KB. So 2KB are released to GC now. Later the same happens five times again and we release 5KB (1KB at each point in time). Finally, when flushing to disk we release 7KB in one piece. While without merge we release 7 pieces of 1KB. So although in total there is more memory to collect, we believe that it is easier to GC to grasp the situation when memory is released over time and in one piece, in contrast to single release with multiple pieces. I am putting a patch here to see the QA results. > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: HBASE-18056-V01.patch > > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16013855#comment-16013855 ] Anoop Sam John commented on HBASE-18056: bq. It reduces GC because the segments memory is garbage collected gradually and not all together in time of flush. Sorry am not getting this point. Here as per the proposed change, say 2 or more segments in pipeline getting compacted together into a larger one right? So 2 or more segments as such going away but a new bigger one is still there right? What is the memory getting GCed here? I may be missing some thing > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16013797#comment-16013797 ] Anastasia Braginsky commented on HBASE-18056: - [~anoop.hbase], we have already done performance tests and we saw merge makes situation better. What is the JIRA number where you explain the problems you see? Why do you think the merge will make situation worse there? The merge is of CellArrayMaps only and is not related to MSLAB at all. bq. Reduction in GC when there are duplicated data right? PE kind of work load where each of the data is diff key, how come this merge will reduce GC? No, without duplicates. It reduces GC because the segments memory is garbage collected gradually and not all together in time of flush. But the performance numbers speak by themselves. > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012475#comment-16012475 ] Anoop Sam John commented on HBASE-18056: Reduction in GC when there are duplicated data right? PE kind of work load where each of the data is diff key, how come this merge will reduce GC? > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-18056) Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline
[ https://issues.apache.org/jira/browse/HBASE-18056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012473#comment-16012473 ] Anoop Sam John commented on HBASE-18056: Will need many rounds of perf test before doing this. With and with out MSLAB and pool (All possible options that we give).. Already I have an issue with MSLAB pool and high IHOP. (mentioned details and possible cause in another jira). The merge will make the situation worse there. Will do more tests around this. Already doing some. > Change CompactingMemStore in BASIC mode to merge multiple segments in pipeline > -- > > Key: HBASE-18056 > URL: https://issues.apache.org/jira/browse/HBASE-18056 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > > Under HBASE-16417 it was decided that CompactingMemStore in BASIC mode should > merge multiple ImmutableSegments in CompactionPipeline. Basic+Merge actually > demonstrated reduction in GC, alongside improvement in other metrics. > However, the limit on the number of segments in pipeline is still set to 30. > Under this JIRA it should be changed to 1, as it was tested under HBASE-16417. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
