[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Resolution: Fixed Status: Resolved (was: Patch Available) Re-re-resolving. Fixed checkstyle on commit. javac complaint is an intentional. > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 0001-HBASE-20564-addendum.txt, 0001-HBASE-20564-addendum2.branch-2.0.patch, > 0002-HBASE-20564-addendum.branch-2.0.patch, 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Status: Patch Available (was: Reopened) > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 0001-HBASE-20564-addendum.txt, 0001-HBASE-20564-addendum2.branch-2.0.patch, > 0002-HBASE-20564-addendum.branch-2.0.patch, 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 0001-HBASE-20564-addendum2.branch-2.0.patch > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 0001-HBASE-20564-addendum.txt, 0001-HBASE-20564-addendum2.branch-2.0.patch, > 0002-HBASE-20564-addendum.branch-2.0.patch, 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Resolution: Fixed Status: Resolved (was: Patch Available) Pushed addendum. Re-resolving. > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 0001-HBASE-20564-addendum.txt, 0002-HBASE-20564-addendum.branch-2.0.patch, > 1.4.pe.write.0510.96203.cpu.svg, 2.p3.write2.0514.104236.cpu.svg, > 2.pe.write.135142.cpu.svg, 20564.addendum, HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.0.002.patch, HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 0002-HBASE-20564-addendum.branch-2.0.patch > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 0001-HBASE-20564-addendum.txt, 0002-HBASE-20564-addendum.branch-2.0.patch, > 1.4.pe.write.0510.96203.cpu.svg, 2.p3.write2.0514.104236.cpu.svg, > 2.pe.write.135142.cpu.svg, 20564.addendum, HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.0.002.patch, HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 0001-HBASE-20564-addendum.txt > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 0001-HBASE-20564-addendum.txt, 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Status: Patch Available (was: Reopened) > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 1.4.pe.write.0510.96203.cpu.svg, 2.p3.write2.0514.104236.cpu.svg, > 2.pe.write.135142.cpu.svg, 20564.addendum, HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.0.002.patch, HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 0001-HBASE-20564-addendum.txt > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 0001-HBASE-20564-addendum.txt, > 1.4.pe.write.0510.96203.cpu.svg, 2.p3.write2.0514.104236.cpu.svg, > 2.pe.write.135142.cpu.svg, 20564.addendum, HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.0.002.patch, HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20564: --- Attachment: 20564.addendum > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to 2.0+. Thanks for review [~ram_krish]. More to do in here but cashing in on this winnings. Hopefully more to be had here. > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: hits.png > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 2.p3.write2.0514.104236.cpu.svg > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 2.pe.write.135142.cpu.svg > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.pe.write.135142.cpu.svg, HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.0.002.patch, HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: 1.4.pe.write.0510.96203.cpu.svg > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: HBASE-20564.branch-2.0.002.patch > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.0.002.patch, HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: HBASE-20564.branch-2.0.001.patch > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: HBASE-20564.branch-2.0.001.patch, > HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Attachment: HBASE-20564.branch-2.patch > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Assignee: stack Fix Version/s: 2.0.1 Status: Patch Available (was: Open) > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: HBASE-20564.branch-2.patch > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20564: -- Summary: Tighter ByteBufferKeyValue Cell Comparator (was: Tighter BB Cell Comparator) > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Priority: Major > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
