[jira] [Commented] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17121511#comment-17121511 ] chenxu commented on HBASE-23296: bq. Why don't use bigger heap as L1, because gc problem? Do you mean BucketCache with heap ioEngine? seems this is not supported now. If use LruBlockCache there may be some gc problems. > Add CompositeBucketCache to support tiered BC > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: New Feature > Components: BlockCache >Reporter: chenxu >Assignee: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118849#comment-17118849 ] chenxu commented on HBASE-23296: bq. So the key point is a bigger L1 cache to cache all index/bloom blocks and the heap size is not enough? yes, we need a bigger L1, it's not suitable to keep it on the heap > Add CompositeBucketCache to support tiered BC > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: New Feature > Components: BlockCache >Reporter: chenxu >Assignee: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[
https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116670#comment-17116670
]
chenxu commented on HBASE-23296:
{quote}So when user config L1 and L2 tiers at the BucketCache level, the on
heap LRU cache will not get used at all?
{quote}
yes as you said.
{quote}We can say all these clearly in the doc pls.
{quote}
OK, will improve the doc soon
> Add CompositeBucketCache to support tiered BC
> -
>
> Key: HBASE-23296
> URL: https://issues.apache.org/jira/browse/HBASE-23296
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> LruBlockCache is not suitable in the following scenarios:
> (1) cache size too large (will take too much heap memory, and
> evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned)
> (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are
> enabled.
> Since block‘s data is reclaimed by GC, this may affect GC performance.
> So how about enabling a Bucket based L1 Cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[
https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116573#comment-17116573
]
chenxu edited comment on HBASE-23296 at 5/26/20, 9:48 AM:
--
Hi, [~anoop.hbase] [~ram_krish], thanks for your review about the doc.
{quote}Are we proposing doing this? Or just the above one?
{quote}
Currently, we implement the above only. Not sure if it’s valuable for the below
diagram.
{quote}Or should we even allow this model to act like today's CombinedCache
model?
{quote}
I’d like this model, in our case we want warmup all the index and blooms, even
the data cache miss, just one seek is enough.
But if the index and bloom miss, we may need three seeks. So only index/bloom
go to L1 may be suitable. The current patch do things like this.
was (Author: javaman_chen):
Hi, [~anoop.hbase] [~ram_krish], thanks for your review about the doc.
{quote}Are we proposing doing this? Or just the above one?
{quote}
Currently, we implement the above only. Not sure if it’s valuable for the below
diagram.
{quote}Or should we even allow this model to act like today's CombinedCache
model?
{quote}
I’d like this model, in our case we want warmup all the index and blooms, even
the data cache miss, just one seek is enough.
But if the index and bloom miss, we may need three seeks. So only index/bloom
go to L1 may be suitable. The current path do things like this.
> Add CompositeBucketCache to support tiered BC
> -
>
> Key: HBASE-23296
> URL: https://issues.apache.org/jira/browse/HBASE-23296
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> LruBlockCache is not suitable in the following scenarios:
> (1) cache size too large (will take too much heap memory, and
> evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned)
> (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are
> enabled.
> Since block‘s data is reclaimed by GC, this may affect GC performance.
> So how about enabling a Bucket based L1 Cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[
https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116573#comment-17116573
]
chenxu commented on HBASE-23296:
Hi, [~anoop.hbase] [~ram_krish], thanks for your review about the doc.
{quote}Are we proposing doing this? Or just the above one?
{quote}
Currently, we implement the above only. Not sure if it’s valuable for the below
diagram.
{quote}Or should we even allow this model to act like today's CombinedCache
model?
{quote}
I’d like this model, in our case we want warmup all the index and blooms, even
the data cache miss, just one seek is enough.
But if the index and bloom miss, we may need three seeks. So only index/bloom
go to L1 may be suitable. The current path do things like this.
> Add CompositeBucketCache to support tiered BC
> -
>
> Key: HBASE-23296
> URL: https://issues.apache.org/jira/browse/HBASE-23296
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> LruBlockCache is not suitable in the following scenarios:
> (1) cache size too large (will take too much heap memory, and
> evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned)
> (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are
> enabled.
> Since block‘s data is reclaimed by GC, this may affect GC performance.
> So how about enabling a Bucket based L1 Cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116335#comment-17116335 ] chenxu commented on HBASE-23296: sorry，make it as public already [~anoop.hbase] > Add CompositeBucketCache to support tiered BC > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: New Feature > Components: BlockCache >Reporter: chenxu >Assignee: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23917) [SimpleRpcServer] Subsequent requests will have no response in case of request IO mess up
[
https://issues.apache.org/jira/browse/HBASE-23917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048791#comment-17048791
]
chenxu commented on HBASE-23917:
Not so easy to reproduce this, occasional happens.
After branch 2.0, NettyRpcServer is enabled by default, and KeyValueCodec has
some refactoring
but how it works with SimpleRpcServer maybe untested
Serializing the KV by PB (not CellBlock) has no problem, so suspected the
problem is KeyValueCodec
> [SimpleRpcServer] Subsequent requests will have no response in case of
> request IO mess up
> -
>
> Key: HBASE-23917
> URL: https://issues.apache.org/jira/browse/HBASE-23917
> Project: HBase
> Issue Type: Bug
> Components: rpc
>Affects Versions: master
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Code in SimpleServerRpcConnection#readAndProcess work like this
> {code:java}
> public int readAndProcess() throws IOException, InterruptedException {
> …
> if (data == null) {
> …
> initByteBuffToReadInto(dataLength);
> …
> }
> count = channelDataRead(channel, data);
> if (count >= 0 && data.remaining() == 0) { // count==0 if dataLength == 0
> process();
> }
> return count;
> }
> {code}
> In case of request IO mess up, _data.remaining()_ may be greater than 0, so
> _process()_ method will not be executed.
> There are some cleanup operations in _process()_
> {code:java}
> private void process() throws IOException, InterruptedException {
> data.rewind();
> try {
> ..
> } finally {
> dataLengthBuffer.clear(); // Clean for the next call
> data = null; // For the GC
> this.callCleanup = null;
> }
> }
> {code}
> If _process()_ not executed, variable _data_ will always not null, and
> _data.remaining()_ will always be greater than 0, so _process()_ will never
> be executed again, and subsequent requests will have no response, this has
> been occured in our product env.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23917) [SimpleRpcServer] Subsequent requests will have no response in case of request IO mess up
chenxu created HBASE-23917:
--
Summary: [SimpleRpcServer] Subsequent requests will have no
response in case of request IO mess up
Key: HBASE-23917
URL: https://issues.apache.org/jira/browse/HBASE-23917
Project: HBase
Issue Type: Bug
Components: rpc
Affects Versions: master
Reporter: chenxu
Assignee: chenxu
Code in SimpleServerRpcConnection#readAndProcess work like this
{code:java}
public int readAndProcess() throws IOException, InterruptedException {
…
if (data == null) {
…
initByteBuffToReadInto(dataLength);
…
}
count = channelDataRead(channel, data);
if (count >= 0 && data.remaining() == 0) { // count==0 if dataLength == 0
process();
}
return count;
}
{code}
In case of request IO mess up, _data.remaining()_ may be greater than 0, so
_process()_ method will not be executed.
There are some cleanup operations in _process()_
{code:java}
private void process() throws IOException, InterruptedException {
data.rewind();
try {
..
} finally {
dataLengthBuffer.clear(); // Clean for the next call
data = null; // For the GC
this.callCleanup = null;
}
}
{code}
If _process()_ not executed, variable _data_ will always not null, and
_data.remaining()_ will always be greater than 0, so _process()_ will never be
executed again, and subsequent requests will have no response, this has been
occured in our product env.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23699) ByteBuff may not recycle correctly when NettyRpcServer enabled and client disconnect
chenxu created HBASE-23699:
--
Summary: ByteBuff may not recycle correctly when NettyRpcServer
enabled and client disconnect
Key: HBASE-23699
URL: https://issues.apache.org/jira/browse/HBASE-23699
Project: HBase
Issue Type: Bug
Components: rpc
Reporter: chenxu
Assignee: chenxu
Code in NettyRpcServerResponseEncoder
{code:java}
@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise
promise) throws Exception {
if (msg instanceof RpcResponse) {
RpcResponse resp = (RpcResponse) msg;
BufferChain buf = resp.getResponse();
ctx.write(Unpooled.wrappedBuffer(buf.getBuffers()), promise).addListener(f
-> {
resp.done();
if (f.isSuccess()) {
metrics.sentBytes(buf.size());
}
});
} else {
ctx.write(msg, promise);
}
}
{code}
If exception occurs during ChannelHandlerContext#write (such as Client
disconnected), ByteBuff may not be recycled correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23374) ExclusiveMemHFileBlock’s allocator should not be hardcoded as ByteBuffAllocator.HEAP
[
https://issues.apache.org/jira/browse/HBASE-23374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-23374:
---
Fix Version/s: 2.3.0
3.0.0
> ExclusiveMemHFileBlock’s allocator should not be hardcoded as
> ByteBuffAllocator.HEAP
>
>
> Key: HBASE-23374
> URL: https://issues.apache.org/jira/browse/HBASE-23374
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
> Fix For: 3.0.0, 2.3.0
>
>
> ExclusiveMemHFileBlock's constructor looks like this:
> {code:java}
> ExclusiveMemHFileBlock(BlockType blockType, int onDiskSizeWithoutHeader,
> int uncompressedSizeWithoutHeader, long prevBlockOffset, ByteBuff buf,
> boolean fillHeader,
> long offset, int nextBlockOnDiskSize, int onDiskDataSizeWithHeader,
> HFileContext fileContext) {
> super(blockType, onDiskSizeWithoutHeader, uncompressedSizeWithoutHeader,
> prevBlockOffset, buf,
> fillHeader, offset, nextBlockOnDiskSize, onDiskDataSizeWithHeader,
> fileContext,
> ByteBuffAllocator.HEAP);
> }
> {code}
> After HBASE-22802, ExclusiveMemHFileBlock’s data may be allocated through the
> BB pool, so it’s allocator should not be hard coded as ByteBuffAllocator.HEAP
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23286) Improve MTTR: Split WAL to HFile
[ https://issues.apache.org/jira/browse/HBASE-23286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995352#comment-16995352 ] chenxu commented on HBASE-23286: Nice number > Improve MTTR: Split WAL to HFile > > > Key: HBASE-23286 > URL: https://issues.apache.org/jira/browse/HBASE-23286 > Project: HBase > Issue Type: Improvement > Components: MTTR >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Major > > After HBASE-20724, the compaction event marker is not used anymore when > failover. So our new proposal is split WAL to HFile to imporve MTTR. It has 3 > steps: > # Read WAL and write HFile to region’s column family’s recovered.hfiles > directory. > # Open region. > # Bulkload the recovered.hfiles for every column family. > The design doc was attathed by a google doc. Any suggestions are welcomed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23355) Bypass the prefetch operation if HFiles are generated through flush or compaction
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989628#comment-16989628
]
chenxu commented on HBASE-23355:
A initial patch was attached, ignore the flush and compaction case when do
prefetch.
> Bypass the prefetch operation if HFiles are generated through flush or
> compaction
> -
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23355) Bypass the prefetch operation if HFiles are generated through flush or compaction
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-23355:
---
Summary: Bypass the prefetch operation if HFiles are generated through
flush or compaction (was: Bypass the prefetch operation if HFiles are
generated through flush or compaction when cacheOnWrite features are enabled)
> Bypass the prefetch operation if HFiles are generated through flush or
> compaction
> -
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23355) Bypass the prefetch operation if HFiles are generated through flush or compaction when cacheOnWrite features are enabled
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-23355:
---
Summary: Bypass the prefetch operation if HFiles are generated through
flush or compaction when cacheOnWrite features are enabled (was: Add a conf
key to decide which operations can trigger prefetch)
> Bypass the prefetch operation if HFiles are generated through flush or
> compaction when cacheOnWrite features are enabled
>
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23374) ExclusiveMemHFileBlock’s allocator should not be hardcoded as ByteBuffAllocator.HEAP
[
https://issues.apache.org/jira/browse/HBASE-23374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989364#comment-16989364
]
chenxu commented on HBASE-23374:
FYI [~anoopjohnson], [~ramkrishna.s.vasude...@gmail.com], [~openinx]，this can
avoid allocate from heap when doing HFileBlock#cloneOnDiskBufferWithHeader or
HFileBlock#cloneUncompressedBufferWithHeader, has a little improvement.
> ExclusiveMemHFileBlock’s allocator should not be hardcoded as
> ByteBuffAllocator.HEAP
>
>
> Key: HBASE-23374
> URL: https://issues.apache.org/jira/browse/HBASE-23374
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
>
> ExclusiveMemHFileBlock's constructor looks like this:
> {code:java}
> ExclusiveMemHFileBlock(BlockType blockType, int onDiskSizeWithoutHeader,
> int uncompressedSizeWithoutHeader, long prevBlockOffset, ByteBuff buf,
> boolean fillHeader,
> long offset, int nextBlockOnDiskSize, int onDiskDataSizeWithHeader,
> HFileContext fileContext) {
> super(blockType, onDiskSizeWithoutHeader, uncompressedSizeWithoutHeader,
> prevBlockOffset, buf,
> fillHeader, offset, nextBlockOnDiskSize, onDiskDataSizeWithHeader,
> fileContext,
> ByteBuffAllocator.HEAP);
> }
> {code}
> After HBASE-22802, ExclusiveMemHFileBlock’s data may be allocated through the
> BB pool, so it’s allocator should not be hard coded as ByteBuffAllocator.HEAP
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23374) ExclusiveMemHFileBlock’s allocator should not be hardcoded as ByteBuffAllocator.HEAP
[
https://issues.apache.org/jira/browse/HBASE-23374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-23374:
---
Description:
ExclusiveMemHFileBlock's constructor looks like this:
{code:java}
ExclusiveMemHFileBlock(BlockType blockType, int onDiskSizeWithoutHeader,
int uncompressedSizeWithoutHeader, long prevBlockOffset, ByteBuff buf,
boolean fillHeader,
long offset, int nextBlockOnDiskSize, int onDiskDataSizeWithHeader,
HFileContext fileContext) {
super(blockType, onDiskSizeWithoutHeader, uncompressedSizeWithoutHeader,
prevBlockOffset, buf,
fillHeader, offset, nextBlockOnDiskSize, onDiskDataSizeWithHeader,
fileContext,
ByteBuffAllocator.HEAP);
}
{code}
After HBASE-22802, ExclusiveMemHFileBlock’s data may be allocated through the
BB pool, so it’s allocator should not be hard coded as ByteBuffAllocator.HEAP
was:After HBASE-22802, ExclusiveMemHFileBlock’s data may be allocated through
the BB pool, so it’s allocator should not be hard coded as
ByteBuffAllocator.HEAP
> ExclusiveMemHFileBlock’s allocator should not be hardcoded as
> ByteBuffAllocator.HEAP
>
>
> Key: HBASE-23374
> URL: https://issues.apache.org/jira/browse/HBASE-23374
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
>
> ExclusiveMemHFileBlock's constructor looks like this:
> {code:java}
> ExclusiveMemHFileBlock(BlockType blockType, int onDiskSizeWithoutHeader,
> int uncompressedSizeWithoutHeader, long prevBlockOffset, ByteBuff buf,
> boolean fillHeader,
> long offset, int nextBlockOnDiskSize, int onDiskDataSizeWithHeader,
> HFileContext fileContext) {
> super(blockType, onDiskSizeWithoutHeader, uncompressedSizeWithoutHeader,
> prevBlockOffset, buf,
> fillHeader, offset, nextBlockOnDiskSize, onDiskDataSizeWithHeader,
> fileContext,
> ByteBuffAllocator.HEAP);
> }
> {code}
> After HBASE-22802, ExclusiveMemHFileBlock’s data may be allocated through the
> BB pool, so it’s allocator should not be hard coded as ByteBuffAllocator.HEAP
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23374) ExclusiveMemHFileBlock’s allocator should not be hardcoded as ByteBuffAllocator.HEAP
chenxu created HBASE-23374: -- Summary: ExclusiveMemHFileBlock’s allocator should not be hardcoded as ByteBuffAllocator.HEAP Key: HBASE-23374 URL: https://issues.apache.org/jira/browse/HBASE-23374 Project: HBase Issue Type: Improvement Reporter: chenxu Assignee: chenxu After HBASE-22802, ExclusiveMemHFileBlock’s data may be allocated through the BB pool, so it’s allocator should not be hard coded as ByteBuffAllocator.HEAP -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23355) Add a conf key to decide which operations can trigger prefetch
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986576#comment-16986576
]
chenxu commented on HBASE-23355:
So here we should ignore the flush and compaction case when do prefetch, and
only consider open and bulkload?
> Add a conf key to decide which operations can trigger prefetch
> --
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (HBASE-23355) Add a conf key to decide which operations can trigger prefetch
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985876#comment-16985876
]
chenxu edited comment on HBASE-23355 at 12/2/19 7:52 AM:
-
There also may be a scenario that we don't need cacheOnWrite and
prefetchOnFlush, but prefetchOnRegionOpen is needed.
So how about consider both case?
{code:java}
if (cacheOnWrite || ! prefetchOnFlush) {
// bypass prefetch operations
}
{code}
was (Author: javaman_chen):
There also may be a scenario that we don't need cacheOnWrite and
prefetchOnFlush, but prefetchOnRegionOpen is needed.
So how about consider both case?
if (cacheOnWrite || ! prefetchOnFlush) {
// bypass prefetch operations
}
> Add a conf key to decide which operations can trigger prefetch
> --
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23355) Add a conf key to decide which operations can trigger prefetch
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985876#comment-16985876
]
chenxu commented on HBASE-23355:
There also may be a scenario that we don't need cacheOnWrite and
prefetchOnFlush, but prefetchOnRegionOpen is needed.
So how about consider both case?
if (cacheOnWrite || ! prefetchOnFlush) {
// bypass prefetch operations
}
> Add a conf key to decide which operations can trigger prefetch
> --
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23355) Add a conf key to decide which operations can trigger prefetch
[
https://issues.apache.org/jira/browse/HBASE-23355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985841#comment-16985841
]
chenxu commented on HBASE-23355:
I think it is necessary to control whether bulkload should bypass the prefetch
operation, so a conf key may be more suitable?
> Add a conf key to decide which operations can trigger prefetch
> --
>
> Key: HBASE-23355
> URL: https://issues.apache.org/jira/browse/HBASE-23355
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Copy the comment from anoop under
> https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
> {quote}On a side note, (Not related to this issue) when we have cache on
> write ON as well as prefetch also On, do we do the caching part for the
> flushed files twice? When it is written, its already been added to cache.
> Later as part of HFile reader open, the prefetch threads will again do a read
> and add to cache!
> {quote}
> It's better to have a conf key to decide which operations(flush, compaction,
> regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite
> is enabled, we can exclude the flush and compaction operations when doing
> prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23355) Add a conf key to decide which operations can trigger prefetch
chenxu created HBASE-23355:
--
Summary: Add a conf key to decide which operations can trigger
prefetch
Key: HBASE-23355
URL: https://issues.apache.org/jira/browse/HBASE-23355
Project: HBase
Issue Type: Improvement
Reporter: chenxu
Assignee: chenxu
Copy the comment from anoop under
https://issues.apache.org/jira/browse/HBASE-23066?focusedCommentId=16984140=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16984140
{quote}On a side note, (Not related to this issue) when we have cache on write
ON as well as prefetch also On, do we do the caching part for the flushed files
twice? When it is written, its already been added to cache. Later as part of
HFile reader open, the prefetch threads will again do a read and add to cache!
{quote}
It's better to have a conf key to decide which operations(flush, compaction,
regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite is
enabled, we can exclude the flush and compaction operations when doing prefetch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23066) Allow cache on write during compactions when prefetching is enabled
[ https://issues.apache.org/jira/browse/HBASE-23066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984145#comment-16984145 ] chenxu commented on HBASE-23066: bq. On a side note, (Not related to this issue) when we have cache on write ON as well as prefetch also On, do we do the caching part for the flushed files twice? When it is written, its already been added to cache. Later as part of HFile reader open, the prefetch threads will again do a read and add to cache! Has thought about this recently, maybe there need a conf key to decide which operations(flush, compaction, regionOpen, bulkload) can trigger the prefetch. In this way, if cacheonwrite is enabled, we can exclude the flush and compaction operations when doing prefetch, I can do this in another JIRA. > Allow cache on write during compactions when prefetching is enabled > --- > > Key: HBASE-23066 > URL: https://issues.apache.org/jira/browse/HBASE-23066 > Project: HBase > Issue Type: Improvement > Components: Compaction, regionserver >Affects Versions: 1.4.10 >Reporter: Jacob LeBlanc >Assignee: Jacob LeBlanc >Priority: Minor > Fix For: 2.3.0, 1.6.0 > > Attachments: HBASE-23066.patch, performance_results.png, > prefetchCompactedBlocksOnWrite.patch > > > In cases where users care a lot about read performance for tables that are > small enough to fit into a cache (or the cache is large enough), > prefetchOnOpen can be enabled to make the entire table available in cache > after the initial region opening is completed. Any new data can also be > guaranteed to be in cache with the cacheBlocksOnWrite setting. > However, the missing piece is when all blocks are evicted after a compaction. > We found very poor performance after compactions for tables under heavy read > load and a slower backing filesystem (S3). After a compaction the prefetching > threads need to compete with threads servicing read requests and get > constantly blocked as a result. > This is a proposal to introduce a new cache configuration option that would > cache blocks on write during compaction for any column family that has > prefetch enabled. This would virtually guarantee all blocks are kept in cache > after the initial prefetch on open is completed allowing for guaranteed > steady read performance despite a slow backing file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
[ https://issues.apache.org/jira/browse/HBASE-23293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-23293: --- Release Note: The default rpc timeout for ReplicationSourceShipper#shipEdits is 60s, when bulkload replication enabled, timeout exception may be occurred. Now we can conf the timeout value through replication.source.shipedits.timeout, and it’s adaptive. > [REPLICATION] make ship edits timeout configurable > -- > > Key: HBASE-23293 > URL: https://issues.apache.org/jira/browse/HBASE-23293 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: chenxu >Assignee: chenxu >Priority: Minor > > ReplicationSourceShipper#shipEdits may take a while if bulkload replication > enabled, since we should copy HFile from the source cluster, so i think there > is a need to make the timeout value configurable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
[ https://issues.apache.org/jira/browse/HBASE-23293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982552#comment-16982552 ] chenxu commented on HBASE-23293: OK, will do this later > [REPLICATION] make ship edits timeout configurable > -- > > Key: HBASE-23293 > URL: https://issues.apache.org/jira/browse/HBASE-23293 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: chenxu >Assignee: chenxu >Priority: Minor > > ReplicationSourceShipper#shipEdits may take a while if bulkload replication > enabled, since we should copy HFile from the source cluster, so i think there > is a need to make the timeout value configurable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980043#comment-16980043 ] chenxu commented on HBASE-23296: A initial patch and an simple design doc was attached. > Add CompositeBucketCache to support tiered BC > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: New Feature > Components: BlockCache >Reporter: chenxu >Assignee: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu reassigned HBASE-23296: -- Assignee: chenxu > Add CompositeBucketCache to support tiered BC > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Reporter: chenxu >Assignee: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-23296) Add CompositeBucketCache to support tiered BC
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-23296: --- Summary: Add CompositeBucketCache to support tiered BC (was: Support Bucket based L1 Cache) > Add CompositeBucketCache to support tiered BC > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Reporter: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23297) [RSGROUP] build RegionPlan per group not per table
[ https://issues.apache.org/jira/browse/HBASE-23297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975941#comment-16975941 ] chenxu commented on HBASE-23297: ya, it's an improvement, the orginal balanceRSGroup will have a final balance, but will take too long time > [RSGROUP] build RegionPlan per group not per table > -- > > Key: HBASE-23297 > URL: https://issues.apache.org/jira/browse/HBASE-23297 > Project: HBase > Issue Type: Improvement > Components: Balancer, rsgroup >Reporter: chenxu >Assignee: chenxu >Priority: Major > > RSGroupAdminServer#balanceRSGroup will take too long time, if the target > group has thousands of tables, because we will build RegionPlan for each > table, I think it’s better to balance per group instead of per table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Support Bucket based L1 Cache
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974869#comment-16974869 ] chenxu commented on HBASE-23296: bq. There should be tiered BC. Yes, actually what I need is a tiered BC. maybe we can name it CompositeBucketCache, do the same thing like what CombinedBlockCache doing, except L1 is BucketCache. > Support Bucket based L1 Cache > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Reporter: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23297) [RSGROUP] build RegionPlan per group not per table
[ https://issues.apache.org/jira/browse/HBASE-23297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974840#comment-16974840 ] chenxu commented on HBASE-23297: OK, will reuse the config > [RSGROUP] build RegionPlan per group not per table > -- > > Key: HBASE-23297 > URL: https://issues.apache.org/jira/browse/HBASE-23297 > Project: HBase > Issue Type: Improvement > Components: Balancer, rsgroup >Reporter: chenxu >Assignee: chenxu >Priority: Major > > RSGroupAdminServer#balanceRSGroup will take too long time, if the target > group has thousands of tables, because we will build RegionPlan for each > table, I think it’s better to balance per group instead of per table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Support Bucket based L1 Cache
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974839#comment-16974839 ] chenxu commented on HBASE-23296: bq. Any specific reason why u can not use the off heap Bucket Cache instead of on heap LRU cache? In our own env, each machine have 12 HDDs and one SSD, about 60TB of storage, we wan't cache all the index & bloom data in L1Cache(about 100G), and HOT data block in L2Cache(SSD), so an Bucket based L1Cache is wanted, it can be offheap. > Support Bucket based L1 Cache > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Reporter: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HBASE-23297) [RSGROUP] build RegionPlan per group not per table
[ https://issues.apache.org/jira/browse/HBASE-23297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu reassigned HBASE-23297: -- Assignee: chenxu > [RSGROUP] build RegionPlan per group not per table > -- > > Key: HBASE-23297 > URL: https://issues.apache.org/jira/browse/HBASE-23297 > Project: HBase > Issue Type: Improvement > Components: Balancer, rsgroup >Reporter: chenxu >Assignee: chenxu >Priority: Major > > RSGroupAdminServer#balanceRSGroup will take too long time, if the target > group has thousands of tables, because we will build RegionPlan for each > table, I think it’s better to balance per group instead of per table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-23297) [RSGROUP] build RegionPlan per group not per table
chenxu created HBASE-23297: -- Summary: [RSGROUP] build RegionPlan per group not per table Key: HBASE-23297 URL: https://issues.apache.org/jira/browse/HBASE-23297 Project: HBase Issue Type: Improvement Components: Balancer, rsgroup Reporter: chenxu RSGroupAdminServer#balanceRSGroup will take too long time, if the target group has thousands of tables, because we will build RegionPlan for each table, I think it’s better to balance per group instead of per table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23296) Support Bucket based L1 Cache
[ https://issues.apache.org/jira/browse/HBASE-23296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974760#comment-16974760 ] chenxu commented on HBASE-23296: FYI [~anoop.hbase], [~ramkrishna], [~openinx] > Support Bucket based L1 Cache > - > > Key: HBASE-23296 > URL: https://issues.apache.org/jira/browse/HBASE-23296 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Reporter: chenxu >Priority: Major > > LruBlockCache is not suitable in the following scenarios: > (1) cache size too large (will take too much heap memory, and > evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) > (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are > enabled. > Since block‘s data is reclaimed by GC, this may affect GC performance. > So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-23296) Support Bucket based L1 Cache
chenxu created HBASE-23296: -- Summary: Support Bucket based L1 Cache Key: HBASE-23296 URL: https://issues.apache.org/jira/browse/HBASE-23296 Project: HBase Issue Type: Improvement Components: BlockCache Reporter: chenxu LruBlockCache is not suitable in the following scenarios: (1) cache size too large (will take too much heap memory, and evictBlocksByHfileName is not so efficient, as HBASE-23277 mentioned) (2) block evicted frequently, especially cacheOnWrite & prefetchOnOpen are enabled. Since block‘s data is reclaimed by GC, this may affect GC performance. So how about enabling a Bucket based L1 Cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
[
https://issues.apache.org/jira/browse/HBASE-23293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974193#comment-16974193
]
chenxu edited comment on HBASE-23293 at 11/14/19 12:32 PM:
---
bq. Then main goal of this change is providing an alternative valve for
increasing the timeout
yes
was (Author: javaman_chen):
Code in AbstractRpcChannel#configureRpcController like this
{code:java}
protected HBaseRpcController configureRpcController(RpcController controller) {
...
if (controller != null && controller instanceof HBaseRpcController) {
hrc = (HBaseRpcController) controller;
if (!hrc.hasCallTimeout()) {
hrc.setCallTimeout(rpcTimeout);
}
} else {
hrc = new HBaseRpcControllerImpl();
hrc.setCallTimeout(rpcTimeout);
}
return hrc;
}
{code}
Seems rpcTimeout will be used as the default value, if we don't specify a
timeout. [~wchevreuil]
> [REPLICATION] make ship edits timeout configurable
> --
>
> Key: HBASE-23293
> URL: https://issues.apache.org/jira/browse/HBASE-23293
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
>
> ReplicationSourceShipper#shipEdits may take a while if bulkload replication
> enabled, since we should copy HFile from the source cluster, so i think there
> is a need to make the timeout value configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
[
https://issues.apache.org/jira/browse/HBASE-23293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974193#comment-16974193
]
chenxu commented on HBASE-23293:
Code in AbstractRpcChannel#configureRpcController like this
{code:java}
protected HBaseRpcController configureRpcController(RpcController controller) {
...
if (controller != null && controller instanceof HBaseRpcController) {
hrc = (HBaseRpcController) controller;
if (!hrc.hasCallTimeout()) {
hrc.setCallTimeout(rpcTimeout);
}
} else {
hrc = new HBaseRpcControllerImpl();
hrc.setCallTimeout(rpcTimeout);
}
return hrc;
}
{code}
Seems rpcTimeout will be used as the default value, if we don't specify a
timeout. [~wchevreuil]
> [REPLICATION] make ship edits timeout configurable
> --
>
> Key: HBASE-23293
> URL: https://issues.apache.org/jira/browse/HBASE-23293
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
>
> ReplicationSourceShipper#shipEdits may take a while if bulkload replication
> enabled, since we should copy HFile from the source cluster, so i think there
> is a need to make the timeout value configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
[ https://issues.apache.org/jira/browse/HBASE-23293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974163#comment-16974163 ] chenxu commented on HBASE-23293: Hi [~wchevreuil], you mean the original timeout is infinite ? I have encounted timeout exceptions recently, thanks for your comments, will dig it more. > [REPLICATION] make ship edits timeout configurable > -- > > Key: HBASE-23293 > URL: https://issues.apache.org/jira/browse/HBASE-23293 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: chenxu >Assignee: chenxu >Priority: Minor > > ReplicationSourceShipper#shipEdits may take a while if bulkload replication > enabled, since we should copy HFile from the source cluster, so i think there > is a need to make the timeout value configurable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
[
https://issues.apache.org/jira/browse/HBASE-23293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974099#comment-16974099
]
chenxu commented on HBASE-23293:
{quote}can we make it adaptive rather than making it fix timedout
{quote}
good suggestion, will do this later
> [REPLICATION] make ship edits timeout configurable
> --
>
> Key: HBASE-23293
> URL: https://issues.apache.org/jira/browse/HBASE-23293
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
>
> ReplicationSourceShipper#shipEdits may take a while if bulkload replication
> enabled, since we should copy HFile from the source cluster, so i think there
> is a need to make the timeout value configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23293) [REPLICATION] make ship edits timeout configurable
chenxu created HBASE-23293: -- Summary: [REPLICATION] make ship edits timeout configurable Key: HBASE-23293 URL: https://issues.apache.org/jira/browse/HBASE-23293 Project: HBase Issue Type: Improvement Components: Replication Reporter: chenxu Assignee: chenxu ReplicationSourceShipper#shipEdits may take a while if bulkload replication enabled, since we should copy HFile from the source cluster, so i think there is a need to make the timeout value configurable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23286) Improve MTTR: Split WAL to HFile
[ https://issues.apache.org/jira/browse/HBASE-23286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973896#comment-16973896 ] chenxu commented on HBASE-23286: Can we write HFile to target CF dir directly instead of recovered.hfiles, when opening region no need to do bulkload any more. If doing bulkload we should bypass the BulkLoadMarker write? or bulkload replication will have a side effect. > Improve MTTR: Split WAL to HFile > > > Key: HBASE-23286 > URL: https://issues.apache.org/jira/browse/HBASE-23286 > Project: HBase > Issue Type: Improvement > Components: MTTR >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Major > > After HBASE-20724, the compaction event marker is not used anymore when > failover. So our new proposal is split WAL to HFile to imporve MTTR. It has 3 > steps: > # Read WAL and write HFile to region’s column family’s recovered.hfiles > directory. > # Open region. > # Bulkload the recovered.hfiles for every column family. > The design doc was attathed by a google doc. Any suggestions are welcomed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-22888) Share some stuffs with the initial reader when new stream reader created
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969945#comment-16969945 ] chenxu commented on HBASE-22888: Thanks for the review. > Share some stuffs with the initial reader when new stream reader created > > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Improvement > Components: HFile, regionserver >Affects Versions: 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > Fix For: 3.0.0, 2.3.0 > > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23270) Inter-cluster replication is unaware destination peer cluster's RSGroup to push the WALEdits
[ https://issues.apache.org/jira/browse/HBASE-23270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969832#comment-16969832 ] chenxu commented on HBASE-23270: bq. Select a destination node having RSGroup awareness +1 Not only ReplicationSink, ReplicationSource should also be awareness of the source rsgroup, right? > Inter-cluster replication is unaware destination peer cluster's RSGroup to > push the WALEdits > > > Key: HBASE-23270 > URL: https://issues.apache.org/jira/browse/HBASE-23270 > Project: HBase > Issue Type: Bug >Reporter: Pradeep >Assignee: Pradeep >Priority: Major > > In a source RSGroup enabled HBase cluster where replication is enabled to > another destination RSGroup enabled cluster, the replication stream of > List go to any node in the destination cluster without the > awareness of RSGroup and then gets routed to appropriate node where the > region is hosted. This extra hop where the data is received and routed could > be of any node in the cluster and no restriction exists to select the node > within the same RSGroup. > Implications: RSGroup owner in the multi-tenant HBase cluster can see > performance and throughput deviations because of this unpredictability caused > by replication. > Potential fix: options: > a) Select a destination node having RSGroup awareness > b) Group the WAL.Edit list based on region and then by region-servers in > which the regions are assigned in the destination. Pass the list WAL.Edit > directly to the region-server to avoid extra intermediate hop in the > destination cluster during the replication process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-22480) Get block from BlockCache once and return this block to BlockCache twice make ref count error.
[
https://issues.apache.org/jira/browse/HBASE-22480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969817#comment-16969817
]
chenxu commented on HBASE-22480:
After reading the code, I have some doubt about
HFileScannerImpl#updateCurrBlockRef
{code:java}
void updateCurrBlockRef(HFileBlock block) {
if (block != null && curBlock != null && block.getOffset() ==
curBlock.getOffset()) {
return;
}
if (this.curBlock != null && this.curBlock.isSharedMem()) {
prevBlocks.add(this.curBlock);
}
this.curBlock = block;
}
{code}
I know it has little to do with the current JIRA, It's just a question
Should we put the new block into the prevBlocks if it has the same offset with
the curBlock. Otherwise, we can't release it ?
> Get block from BlockCache once and return this block to BlockCache twice make
> ref count error.
> --
>
> Key: HBASE-22480
> URL: https://issues.apache.org/jira/browse/HBASE-22480
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.2.2
>Reporter: Lijin Bin
>Assignee: Lijin Bin
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.3
>
> Attachments: HBASE-22480-branch-2.2-v1.patch,
> HBASE-22480-branch-2.2-v1.patch, HBASE-22480-branch-2.2-v1.patch,
> HBASE-22480-branch-2.2-v2.patch, HBASE-22480-master-v1.patch,
> HBASE-22480-master-v2.patch, HBASE-22480-master-v3.patch,
> HBASE-22480-master-v4.patch, HBASE-22480-master-v5.patch,
> HBASE-22480-master-v6.patch, HBASE-22480-master-v6.patch,
> HBASE-22480-master-v6.patch, HBASE-22480-master-v7.patch,
> HBASE-22480-master-v7.patch
>
>
> After debugging HBASE-22433, i find the problem it is that we get a block
> from BucketCache once and return this block to BucketCache twice and make the
> ref count error, sometimes the refCount can be negative.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (HBASE-23196) The IndexChunkPool’s percentage is hard code to 0.1
[
https://issues.apache.org/jira/browse/HBASE-23196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu reassigned HBASE-23196:
--
Assignee: chenxu
> The IndexChunkPool’s percentage is hard code to 0.1
> ---
>
> Key: HBASE-23196
> URL: https://issues.apache.org/jira/browse/HBASE-23196
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Code in ChunkCreator#initialize
> {code:java}
> public static ChunkCreator initialize(...) {
> if (instance != null) {
> return instance;
> }
> instance = new ChunkCreator(chunkSize, offheap, globalMemStoreSize,
> poolSizePercentage,
> initialCountPercentage, heapMemoryManager,
> MemStoreLABImpl.INDEX_CHUNK_PERCENTAGE_DEFAULT);
> return instance;
> }
> {code}
> When mslab is enabled, the IndexChunkPool’s percentage is hard code to
> INDEX_CHUNK_PERCENTAGE_DEFAULT, When we use IndexType#ARRAY_MAP other than
> IndexType#CHUNK_MAP, we should set IndexChunkPool’s size to 0, or there will
> be a waste of memory space.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23196) The IndexChunkPool’s percentage is hard code to 0.1
[
https://issues.apache.org/jira/browse/HBASE-23196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957625#comment-16957625
]
chenxu commented on HBASE-23196:
Ya, the issue is in 2.0+ versions
Working on our own branch now, will make a PR soon
> The IndexChunkPool’s percentage is hard code to 0.1
> ---
>
> Key: HBASE-23196
> URL: https://issues.apache.org/jira/browse/HBASE-23196
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: chenxu
>Priority: Major
>
> Code in ChunkCreator#initialize
> {code:java}
> public static ChunkCreator initialize(...) {
> if (instance != null) {
> return instance;
> }
> instance = new ChunkCreator(chunkSize, offheap, globalMemStoreSize,
> poolSizePercentage,
> initialCountPercentage, heapMemoryManager,
> MemStoreLABImpl.INDEX_CHUNK_PERCENTAGE_DEFAULT);
> return instance;
> }
> {code}
> When mslab is enabled, the IndexChunkPool’s percentage is hard code to
> INDEX_CHUNK_PERCENTAGE_DEFAULT, When we use IndexType#ARRAY_MAP other than
> IndexType#CHUNK_MAP, we should set IndexChunkPool’s size to 0, or there will
> be a waste of memory space.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23196) The IndexChunkPool’s percentage is hard code to 0.1
chenxu created HBASE-23196:
--
Summary: The IndexChunkPool’s percentage is hard code to 0.1
Key: HBASE-23196
URL: https://issues.apache.org/jira/browse/HBASE-23196
Project: HBase
Issue Type: Bug
Reporter: chenxu
Code in ChunkCreator#initialize
{code:java}
public static ChunkCreator initialize(...) {
if (instance != null) {
return instance;
}
instance = new ChunkCreator(chunkSize, offheap, globalMemStoreSize,
poolSizePercentage,
initialCountPercentage, heapMemoryManager,
MemStoreLABImpl.INDEX_CHUNK_PERCENTAGE_DEFAULT);
return instance;
}
{code}
When mslab is enabled, the IndexChunkPool’s percentage is hard code to
INDEX_CHUNK_PERCENTAGE_DEFAULT, When we use IndexType#ARRAY_MAP other than
IndexType#CHUNK_MAP, we should set IndexChunkPool’s size to 0, or there will be
a waste of memory space.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23184) The HeapAllocation in WebUI is not accurate
[ https://issues.apache.org/jira/browse/HBASE-23184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954222#comment-16954222 ] chenxu commented on HBASE-23184: FYI [~openinx] > The HeapAllocation in WebUI is not accurate > --- > > Key: HBASE-23184 > URL: https://issues.apache.org/jira/browse/HBASE-23184 > Project: HBase > Issue Type: Bug > Components: UI >Reporter: chenxu >Priority: Minor > > HeapAllocation in WebUI is always 0, the same reason as HBASE-22663 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-23184) The HeapAllocation in WebUI is not accurate
chenxu created HBASE-23184: -- Summary: The HeapAllocation in WebUI is not accurate Key: HBASE-23184 URL: https://issues.apache.org/jira/browse/HBASE-23184 Project: HBase Issue Type: Bug Components: UI Reporter: chenxu HeapAllocation in WebUI is always 0, the same reason as HBASE-22663 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23151) Backport HBASE-23083 (Collect Executor status info periodically and report to metrics system) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-23151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952609#comment-16952609 ] chenxu commented on HBASE-23151: Thanks for the review > Backport HBASE-23083 (Collect Executor status info periodically and report to > metrics system) to branch-1 > - > > Key: HBASE-23151 > URL: https://issues.apache.org/jira/browse/HBASE-23151 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Kyle Purtell >Assignee: chenxu >Priority: Minor > Fix For: 1.5.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23107) Avoid temp byte array creation when doing cacheDataOnWrite
[
https://issues.apache.org/jira/browse/HBASE-23107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950712#comment-16950712
]
chenxu commented on HBASE-23107:
The heap flamegraph has been upload, memory allocation ratio for CacheOnWrite
has an obvious reduce, hope this is usefully. [~openinx]
> Avoid temp byte array creation when doing cacheDataOnWrite
> --
>
> Key: HBASE-23107
> URL: https://issues.apache.org/jira/browse/HBASE-23107
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: flamegraph_after.svg, flamegraph_before.svg
>
>
> code in HFileBlock.Writer.cloneUncompressedBufferWithHeader
> {code:java}
> ByteBuffer cloneUncompressedBufferWithHeader() {
> expectState(State.BLOCK_READY);
> byte[] uncompressedBlockBytesWithHeader = baosInMemory.toByteArray();
> …
> }
> {code}
> When cacheOnWrite feature enabled, a temp byte array was created in order to
> copy block’s data, we can avoid this by use of ByteBuffAllocator. This can
> improve GC performance in write heavy scenarios.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23107) Avoid temp byte array creation when doing cacheDataOnWrite
[
https://issues.apache.org/jira/browse/HBASE-23107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-23107:
---
Attachment: flamegraph_after.svg
> Avoid temp byte array creation when doing cacheDataOnWrite
> --
>
> Key: HBASE-23107
> URL: https://issues.apache.org/jira/browse/HBASE-23107
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: flamegraph_after.svg, flamegraph_before.svg
>
>
> code in HFileBlock.Writer.cloneUncompressedBufferWithHeader
> {code:java}
> ByteBuffer cloneUncompressedBufferWithHeader() {
> expectState(State.BLOCK_READY);
> byte[] uncompressedBlockBytesWithHeader = baosInMemory.toByteArray();
> …
> }
> {code}
> When cacheOnWrite feature enabled, a temp byte array was created in order to
> copy block’s data, we can avoid this by use of ByteBuffAllocator. This can
> improve GC performance in write heavy scenarios.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23107) Avoid temp byte array creation when doing cacheDataOnWrite
[
https://issues.apache.org/jira/browse/HBASE-23107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-23107:
---
Attachment: flamegraph_before.svg
> Avoid temp byte array creation when doing cacheDataOnWrite
> --
>
> Key: HBASE-23107
> URL: https://issues.apache.org/jira/browse/HBASE-23107
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: flamegraph_after.svg, flamegraph_before.svg
>
>
> code in HFileBlock.Writer.cloneUncompressedBufferWithHeader
> {code:java}
> ByteBuffer cloneUncompressedBufferWithHeader() {
> expectState(State.BLOCK_READY);
> byte[] uncompressedBlockBytesWithHeader = baosInMemory.toByteArray();
> …
> }
> {code}
> When cacheOnWrite feature enabled, a temp byte array was created in order to
> copy block’s data, we can avoid this by use of ByteBuffAllocator. This can
> improve GC performance in write heavy scenarios.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23107) Avoid temp byte array creation when doing cacheDataOnWrite
[
https://issues.apache.org/jira/browse/HBASE-23107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950676#comment-16950676
]
chenxu commented on HBASE-23107:
{quote}did you mind to provide some perf data to show the GC pressure decrement
{quote}
Will do this later.
> Avoid temp byte array creation when doing cacheDataOnWrite
> --
>
> Key: HBASE-23107
> URL: https://issues.apache.org/jira/browse/HBASE-23107
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> code in HFileBlock.Writer.cloneUncompressedBufferWithHeader
> {code:java}
> ByteBuffer cloneUncompressedBufferWithHeader() {
> expectState(State.BLOCK_READY);
> byte[] uncompressedBlockBytesWithHeader = baosInMemory.toByteArray();
> …
> }
> {code}
> When cacheOnWrite feature enabled, a temp byte array was created in order to
> copy block’s data, we can avoid this by use of ByteBuffAllocator. This can
> improve GC performance in write heavy scenarios.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23158) If KVs are in memstore, small batch get can come across MultiActionResultTooLarge
[ https://issues.apache.org/jira/browse/HBASE-23158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950209#comment-16950209 ] chenxu commented on HBASE-23158: I think [HBASE-23063|https://github.com/apache/hbase/pull/656] can also resolve this issue, since we restrict the number of return rows instead. IMHO ,limit the number of Blocks each Multi can use is truly not suitable, since the mslab CHUNK, Bucket's ByteBuffer are all shared mem among diff RPC. > If KVs are in memstore, small batch get can come across > MultiActionResultTooLarge > -- > > Key: HBASE-23158 > URL: https://issues.apache.org/jira/browse/HBASE-23158 > Project: HBase > Issue Type: Bug > Components: regionserver, rpc > Environment: [^TestMultiRespectsLimitsMemstore.patch] >Reporter: junfei liang >Priority: Minor > Attachments: TestMultiRespectsLimitsMemstore.patch > > > to protect against big scan, we set hbase.server.scanner.max.result.size = > 10MB in our customer hbase cluster, however our clients can meet > MultiActionResultTooLarge even in small batch get (for ex. 15 batch get, and > row size is about 5KB ) . > after [HBASE-14978|https://issues.apache.org/jira/browse/HBASE-14978] hbase > take the data block reference into consideration, but the block size is 64KB > (the default value ), even if all cells are from different block , the block > size retained is less than 1MB, so what's the problem ? > finally i found that HBASE-14978 also consider the cell in memstore, as > MSLAB is enabled default, so if the cell is from memstore, cell backend array > can be large (2MB as default), so even if a small batch can meet this error, > is this reasonable ? > plus: > when throw MultiActionResultTooLarge exception, hbase client should retry > ignore rpc retry num, however if set retry num to zero, client will fail > without retry in this case. > > see attachment TestMultiRespectsLimitsMemstore for details. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HBASE-23151) Backport HBASE-23083 (Collect Executor status info periodically and report to metrics system) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-23151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-23151 started by chenxu. -- > Backport HBASE-23083 (Collect Executor status info periodically and report to > metrics system) to branch-1 > - > > Key: HBASE-23151 > URL: https://issues.apache.org/jira/browse/HBASE-23151 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Kyle Purtell >Assignee: chenxu >Priority: Minor > Fix For: 1.6.0, 1.5.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23151) Backport HBASE-23083 (Collect Executor status info periodically and report to metrics system) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-23151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949857#comment-16949857 ] chenxu commented on HBASE-23151: assign it to me？ > Backport HBASE-23083 (Collect Executor status info periodically and report to > metrics system) to branch-1 > - > > Key: HBASE-23151 > URL: https://issues.apache.org/jira/browse/HBASE-23151 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Kyle Purtell >Priority: Minor > Fix For: 1.6.0, 1.5.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23107) Avoid temp byte array creation when doing cacheDataOnWrite
[
https://issues.apache.org/jira/browse/HBASE-23107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949549#comment-16949549
]
chenxu commented on HBASE-23107:
{quote}Ping Anoop Sam John, would you like to give a review? You have better
insights over kinds of cache and mem issues.
{quote}
+1
cc [~openinx] , [~ram_krish]
> Avoid temp byte array creation when doing cacheDataOnWrite
> --
>
> Key: HBASE-23107
> URL: https://issues.apache.org/jira/browse/HBASE-23107
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> code in HFileBlock.Writer.cloneUncompressedBufferWithHeader
> {code:java}
> ByteBuffer cloneUncompressedBufferWithHeader() {
> expectState(State.BLOCK_READY);
> byte[] uncompressedBlockBytesWithHeader = baosInMemory.toByteArray();
> …
> }
> {code}
> When cacheOnWrite feature enabled, a temp byte array was created in order to
> copy block’s data, we can avoid this by use of ByteBuffAllocator. This can
> improve GC performance in write heavy scenarios.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-23107) Avoid temp byte array creation when doing cacheDataOnWrite
chenxu created HBASE-23107:
--
Summary: Avoid temp byte array creation when doing cacheDataOnWrite
Key: HBASE-23107
URL: https://issues.apache.org/jira/browse/HBASE-23107
Project: HBase
Issue Type: Improvement
Reporter: chenxu
Assignee: chenxu
code in HFileBlock.Writer.cloneUncompressedBufferWithHeader
{code:java}
ByteBuffer cloneUncompressedBufferWithHeader() {
expectState(State.BLOCK_READY);
byte[] uncompressedBlockBytesWithHeader = baosInMemory.toByteArray();
…
}
{code}
When cacheOnWrite feature enabled, a temp byte array was created in order to
copy block’s data, we can avoid this by use of ByteBuffAllocator. This can
improve GC performance in write heavy scenarios.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23066) Allow cache on write during compactions when prefetching is enabled
[
https://issues.apache.org/jira/browse/HBASE-23066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941659#comment-16941659
]
chenxu commented on HBASE-23066:
{quote}You mean after every compaciton or in general if the hfile count
increases certain level do not cache?
{quote}
As time goes on, HFile will grow larger(because of Compaction), and it's data
may get colder and colder, In some scenarios, only the latest time window data
is accessed, so warmup the large HFile seems unnecessary.
> Allow cache on write during compactions when prefetching is enabled
> ---
>
> Key: HBASE-23066
> URL: https://issues.apache.org/jira/browse/HBASE-23066
> Project: HBase
> Issue Type: Improvement
> Components: Compaction, regionserver
>Affects Versions: 1.4.10
>Reporter: Jacob LeBlanc
>Assignee: Jacob LeBlanc
>Priority: Minor
> Fix For: 1.5.0, 2.3.0
>
> Attachments: HBASE-23066.patch, performance_results.png,
> prefetchCompactedBlocksOnWrite.patch
>
>
> In cases where users care a lot about read performance for tables that are
> small enough to fit into a cache (or the cache is large enough),
> prefetchOnOpen can be enabled to make the entire table available in cache
> after the initial region opening is completed. Any new data can also be
> guaranteed to be in cache with the cacheBlocksOnWrite setting.
> However, the missing piece is when all blocks are evicted after a compaction.
> We found very poor performance after compactions for tables under heavy read
> load and a slower backing filesystem (S3). After a compaction the prefetching
> threads need to compete with threads servicing read requests and get
> constantly blocked as a result.
> This is a proposal to introduce a new cache configuration option that would
> cache blocks on write during compaction for any column family that has
> prefetch enabled. This would virtually guarantee all blocks are kept in cache
> after the initial prefetch on open is completed allowing for guaranteed
> steady read performance despite a slow backing file system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-23084) Assertion "Added a key not lexically larger than previous" or "prevKey followed by a smaller key" caused abortion of RS
[
https://issues.apache.org/jira/browse/HBASE-23084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940375#comment-16940375
]
chenxu commented on HBASE-23084:
Is the phoenix table enabled FAST_DIFF encoding? Is there any crash log? Can
you apply HBASE-22965’s patch and test again?
> Assertion "Added a key not lexically larger than previous" or "prevKey
> followed by a smaller key" caused abortion of RS
> --
>
> Key: HBASE-23084
> URL: https://issues.apache.org/jira/browse/HBASE-23084
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Environment: We store many phoenix tables in hbase, only one table
> trigger this issues.
> When two jacent keys in wrong order, the observation as follows.
> 1. the prevKey is written into hbase via Put rpc
> 2. the current key via phoenix upsert statment( Multi rpc in underlying hbase)
> 3. the current Cell extends 1MB.
> 4. the error is easy to re-ocurr.
>Reporter: ranpanfeng
>Priority: Critical
>
> when auto flush and manual flush is invoked, cell in immutable memstore
> segment is scanned one by one to build data block and bloom filter block,
> during this time, two adjacent keys are compared to assert that they are in
> lexicographical order, but regretfully, the assertion fails in some
> scenarios, when RS encounter these assertion failure, always call abort
> function to terminate abnormally.
>
> the version is 0ba7cc01a13dbb7fec8e6c5d599fc8b4936bae61 tag: rel/2.1.5
>
> At least three cases are found.
> *error case#1: getQualifierArray throws
> java.lang.ArrayIndexOutOfBoundsException*
>
> {code:java}
> 17:57:50.328 [MemStoreFlusher.0] ERROR
> org.apache.hadoop.hbase.regionserver.HRegionServer - * ABORTING region
> server ${regionserver}: Replay of WAL required. Forcing server shutdown *
> org.apache.hadoop.hbase.DroppedSnapshotException: region: ${region}.
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushCacheAndCommit(HRegion.java:2788)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2467)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2439)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:2329)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:612)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:581)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher.access$1000(MemStoreFlusher.java:68)
> [hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.MemStoreFlusher$FlushHandler.run(MemStoreFlusher.java:361)
> [hbase-server-2.1.5.jar:2.1.5]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.hadoop.hbase.util.ByteBufferUtils.copyFromBufferToArray(ByteBufferUtils.java:1155)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.CellUtil.copyQualifierTo(CellUtil.java:309)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at org.apache.hadoop.hbase.CellUtil.cloneQualifier(CellUtil.java:121)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.ByteBufferKeyValue.getQualifierArray(ByteBufferKeyValue.java:112)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.CellUtil.getCellKeyAsString(CellUtil.java:1306)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at org.apache.hadoop.hbase.CellUtil.toString(CellUtil.java:1483)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.ByteBufferKeyValue.toString(ByteBufferKeyValue.java:296)
> ~[hbase-common-2.1.5.jar:2.1.5]
> at java.lang.String.valueOf(String.java:2994) ~[?:1.8.0_144]
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> ~[?:1.8.0_144]
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.checkScanOrder(StoreScanner.java:1007)
> ~[hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:582)
> ~[hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.StoreFlusher.performFlush(StoreFlusher.java:127)
> ~[hbase-server-2.1.5.jar:2.1.5]
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreFlusher.flushSnapshot(DefaultStoreFlusher.java:69)
> ~[hbase-server-2.1.5.jar:2.1.5]
> at
>
[jira] [Commented] (HBASE-23083) Collect Executor status info periodically and report to metrics system
[ https://issues.apache.org/jira/browse/HBASE-23083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939200#comment-16939200 ] chenxu commented on HBASE-23083: FYI [~stack] > Collect Executor status info periodically and report to metrics system > -- > > Key: HBASE-23083 > URL: https://issues.apache.org/jira/browse/HBASE-23083 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > > HRegionServer#startServiceThreads will start some Executors, but we don't > have a good way to know their status, such as how many threads pending, and > how many threads running. Can add an ScheduledChore to collect the > information periodically and report to metrics system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-23083) Collect Executor status info periodically and report to metrics system
chenxu created HBASE-23083: -- Summary: Collect Executor status info periodically and report to metrics system Key: HBASE-23083 URL: https://issues.apache.org/jira/browse/HBASE-23083 Project: HBase Issue Type: Improvement Reporter: chenxu Assignee: chenxu HRegionServer#startServiceThreads will start some Executors, but we don't have a good way to know their status, such as how many threads pending, and how many threads running. Can add an ScheduledChore to collect the information periodically and report to metrics system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939077#comment-16939077 ] chenxu commented on HBASE-23067: Hi Stack, I mean the perf has no improvement, the number of object instances can be controlled(but Netty will introduce extra Handle instance), maybe the Recycler is more suitable for large size Objects. And BucketEntry might be better managed by ourselves. > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: HBASE-23067-master-v1.patch, heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-23067: --- Attachment: HBASE-23067-master-v1.patch > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: HBASE-23067-master-v1.patch, heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938385#comment-16938385 ] chenxu commented on HBASE-23067: Unfortunately, After testing found no improvement, maybe I used it incorrectly, upload the patch first. > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937455#comment-16937455 ] chenxu commented on HBASE-23067: The total cache size is about 80G, hfile block size is 32KB, so 2500k BucketEntry should be enough, but the actual use exceeds 6000k [~anoop.hbase] > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937389#comment-16937389 ] chenxu commented on HBASE-23067: yeah, it's just a obj pool, i think. > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937380#comment-16937380 ] chenxu commented on HBASE-23067: bq. I'd think the refcount entries would be < bucket cache entries? I think it's not necessarily, because each ByteBuff allocate through ByteBuffAllocator will also have a RefCnt. > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23066) Allow cache on write during compactions when prefetching is enabled
[ https://issues.apache.org/jira/browse/HBASE-23066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937361#comment-16937361 ] chenxu commented on HBASE-23066: Can we declare a warmup threshold on the Table schema? If the compacted HFile greater than this threshold, do not cache it, just a suggestion. > Allow cache on write during compactions when prefetching is enabled > --- > > Key: HBASE-23066 > URL: https://issues.apache.org/jira/browse/HBASE-23066 > Project: HBase > Issue Type: Improvement > Components: Compaction, regionserver >Affects Versions: 1.4.10 >Reporter: Jacob LeBlanc >Assignee: Jacob LeBlanc >Priority: Minor > Fix For: 1.5.0, 2.3.0 > > Attachments: HBASE-23066.patch, prefetchCompactedBlocksOnWrite.patch > > > In cases where users care a lot about read performance for tables that are > small enough to fit into a cache (or the cache is large enough), > prefetchOnOpen can be enabled to make the entire table available in cache > after the initial region opening is completed. Any new data can also be > guaranteed to be in cache with the cacheBlocksOnWrite setting. > However, the missing piece is when all blocks are evicted after a compaction. > We found very poor performance after compactions for tables under heavy read > load and a slower backing filesystem (S3). After a compaction the prefetching > threads need to compete with threads servicing read requests and get > constantly blocked as a result. > This is a proposal to introduce a new cache configuration option that would > cache blocks on write during compaction for any column family that has > prefetch enabled. This would virtually guarantee all blocks are kept in cache > after the initial prefetch on open is completed allowing for guaranteed > steady read performance despite a slow backing file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23063) Add an option to enable multiget in parallel
[ https://issues.apache.org/jira/browse/HBASE-23063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937355#comment-16937355 ] chenxu commented on HBASE-23063: Any advise about the PR ? [~zhangduo], [~ram_krish], [~zghao] > Add an option to enable multiget in parallel > > > Key: HBASE-23063 > URL: https://issues.apache.org/jira/browse/HBASE-23063 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > > Currently, multiget operation will be processed serially on the server side, > RSRpcServices#multi will handle the Action one by one. We can add an option > to handle this in parallel, just like what parallel seek doing. In some > scenarios, this can improve multiget performance a lot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-23067: --- Attachment: heap_dump.png > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: heap_dump.png > > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
chenxu created HBASE-23067: -- Summary: Use Netty’s Recycler to manage RefCnt and BucketEntry creation Key: HBASE-23067 URL: https://issues.apache.org/jira/browse/HBASE-23067 Project: HBase Issue Type: Improvement Reporter: chenxu Assignee: chenxu After dump the heap, found that the number of RefCnt & BucketEntry object instances is so large now, How about use Netty’s Recycler to manage them, this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23067) Use Netty’s Recycler to manage RefCnt and BucketEntry creation
[ https://issues.apache.org/jira/browse/HBASE-23067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936656#comment-16936656 ] chenxu commented on HBASE-23067: I think It's not complicated to implement this, since RefCnt has already extended netty’s AbstractReferenceCounted, we can do the recycling in RefCnt#deallocation. will have a test soon. > Use Netty’s Recycler to manage RefCnt and BucketEntry creation > -- > > Key: HBASE-23067 > URL: https://issues.apache.org/jira/browse/HBASE-23067 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > > After dump the heap, found that the number of RefCnt & BucketEntry object > instances is so large now, How about use Netty’s Recycler to manage them, > this may improve the YGC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-23063) Add an option to enable multiget in parallel
[
https://issues.apache.org/jira/browse/HBASE-23063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16935667#comment-16935667
]
chenxu commented on HBASE-23063:
Client open 10 threads to perform 1 million MultiGet operations, each Row has 1
KV and the size of KV is 1 KB, the test results are as follows:
||RowsPerMultiget||ParallelGetEnable||*ops/sec*||*AvaLatency(ms)*||*P95thLatency(ms)*||*P99thLatency(ms)***||TotalTime(ms)||
|20|YES|6702|1.43 {color:#FF}*(2%)*{color}|1.95|2.90|149197|
|50|YES|4105|2.36 {color:#FF}*(23%)*{color}|3.12|4.27|243584|
|100|YES|2600|3.73 {color:#FF}*(38%)*{color}|4.51|6.25|384492|
|20|NO|6345|1.47|2.15|3.51|157581|
|50|NO|3349|2.91|4.04|6.69|298513|
|100|NO|1891|5.18|7.24|13.67|528617|
Will prepare the patch soon.
> Add an option to enable multiget in parallel
>
>
> Key: HBASE-23063
> URL: https://issues.apache.org/jira/browse/HBASE-23063
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> Currently, multiget operation will be processed serially on the server side,
> RSRpcServices#multi will handle the Action one by one. We can add an option
> to handle this in parallel, just like what parallel seek doing. In some
> scenarios, this can improve multiget performance a lot.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (HBASE-23063) Add an option to enable multiget in parallel
[ https://issues.apache.org/jira/browse/HBASE-23063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-23063: --- Description: Currently, multiget operation will be processed serially on the server side, RSRpcServices#multi will handle the Action one by one. We can add an option to handle this in parallel, just like what parallel seek doing. In some scenarios, this can improve multiget performance a lot. (was: Currently, multiget operation will be processed serially on the server side, RSRpcServices#multi will handle the Action one by one. We can add an option to handle this in parallel, just like what parallel seek doing. In some scenarios, this can improve multiget performance a lot.) > Add an option to enable multiget in parallel > > > Key: HBASE-23063 > URL: https://issues.apache.org/jira/browse/HBASE-23063 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > > Currently, multiget operation will be processed serially on the server side, > RSRpcServices#multi will handle the Action one by one. We can add an option > to handle this in parallel, just like what parallel seek doing. In some > scenarios, this can improve multiget performance a lot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-23063) Add an option to enable multiget in parallel
chenxu created HBASE-23063: -- Summary: Add an option to enable multiget in parallel Key: HBASE-23063 URL: https://issues.apache.org/jira/browse/HBASE-23063 Project: HBase Issue Type: Improvement Reporter: chenxu Assignee: chenxu Currently, multiget operation will be processed serially on the server side, RSRpcServices#multi will handle the Action one by one. We can add an option to handle this in parallel, just like what parallel seek doing. In some scenarios, this can improve multiget performance a lot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-22975) Add read and write QPS metrics at server level and table level
[ https://issues.apache.org/jira/browse/HBASE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932497#comment-16932497 ] chenxu commented on HBASE-22975: Does hbase-15518 already contain similar features? > Add read and write QPS metrics at server level and table level > -- > > Key: HBASE-22975 > URL: https://issues.apache.org/jira/browse/HBASE-22975 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 2.2.0, 1.4.10, master >Reporter: zbq.dean >Priority: Major > Attachments: readQPS.png, writeQPS.png > > > Use HBase‘s existing class DropwizardMeter to collect read and write QPS. The > collected location is the same as metrics readRequestsCount and > writeRequestsCount. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-22888) Share some stuffs with the initial reader when new stream reader created
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22888: --- Summary: Share some stuffs with the initial reader when new stream reader created (was: Use separate classe to deal with streaming read and pread) > Share some stuffs with the initial reader when new stream reader created > > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22965) RS Crash due to DBE reference to an reused ByteBuff
[ https://issues.apache.org/jira/browse/HBASE-22965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22965: --- Summary: RS Crash due to DBE reference to an reused ByteBuff (was: RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff) > RS Crash due to DBE reference to an reused ByteBuff > --- > > Key: HBASE-22965 > URL: https://issues.apache.org/jira/browse/HBASE-22965 > Project: HBase > Issue Type: Bug >Reporter: chenxu >Priority: Major > Attachments: hs_regionserver_err_pid.log > > > After introduce HBASE-21879 into our own branch, when enable data block > encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been > uploaded). > After reading RowIndexEncoderV1, find _lastCell_ may refer to an reused > ByteBuff, because DBE is not a listener of Shipper。 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (HBASE-22965) RS Crash due to DBE reference to an reused ByteBuff
[ https://issues.apache.org/jira/browse/HBASE-22965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu reassigned HBASE-22965: -- Assignee: chenxu > RS Crash due to DBE reference to an reused ByteBuff > --- > > Key: HBASE-22965 > URL: https://issues.apache.org/jira/browse/HBASE-22965 > Project: HBase > Issue Type: Bug >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: hs_regionserver_err_pid.log > > > After introduce HBASE-21879 into our own branch, when enable data block > encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been > uploaded). > After reading RowIndexEncoderV1, find _lastCell_ may refer to an reused > ByteBuff, because DBE is not a listener of Shipper。 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HBASE-22888) Use separate classe to deal with streaming read and pread
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926325#comment-16926325 ] chenxu commented on HBASE-22888: The following changes have been made (1) make BlockIndexReader Stateless, so we share it between readers (2) share the FixedFileTrailer between readers (3) do computeHDFSBlocksDistribution in pread reader only The performance improvement of Scan is obvious in our test env > Use separate classe to deal with streaming read and pread > - > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22802) Avoid temp ByteBuffer allocation in FileIOEngine#read
[
https://issues.apache.org/jira/browse/HBASE-22802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-22802:
---
Release Note: HBASE-21879 introduces a utility class
(org.apache.hadoop.hbase.io.ByteBuffAllocator) used for allocating/freeing
ByteBuffers from/to NIO ByteBuffer pool, when BucketCache enabled with file or
mmap engine, we will use this ByteBuffer pool to avoid temp ByteBuffer
allocation a lot.
> Avoid temp ByteBuffer allocation in FileIOEngine#read
> -
>
> Key: HBASE-22802
> URL: https://issues.apache.org/jira/browse/HBASE-22802
> Project: HBase
> Issue Type: Improvement
> Components: BucketCache
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-22802-master-v1.patch, profile_mem_alloc.png,
> profile_mem_alloc_with_pool.png
>
>
> a temp ByteBuffer was allocated each time FileIOEngine#read was called
> {code:java}
> public Cacheable read(BucketEntry be) throws IOException {
> long offset = be.offset();
> int length = be.getLength();
> Preconditions.checkArgument(length >= 0, "Length of read can not be less
> than 0.");
> ByteBuffer dstBuffer = ByteBuffer.allocate(length);
> ...
> }
> {code}
> we can avoid this by use of ByteBuffAllocator#allocate(length) after
> HBASE-21879
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (HBASE-22965) RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff
[ https://issues.apache.org/jira/browse/HBASE-22965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925561#comment-16925561 ] chenxu commented on HBASE-22965: Testing based on our own branch yet, will upload patches when there are no problems on out own env. > RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff > - > > Key: HBASE-22965 > URL: https://issues.apache.org/jira/browse/HBASE-22965 > Project: HBase > Issue Type: Bug >Reporter: chenxu >Priority: Major > Attachments: hs_regionserver_err_pid.log > > > After introduce HBASE-21879 into our own branch, when enable data block > encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been > uploaded). > After reading RowIndexEncoderV1, find _lastCell_ may refer to an reused > ByteBuff, because DBE is not a listener of Shipper。 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22996) refact MultiByteBuff, combine the buffsIterator and curItem & curItemIndex into one iterator
[
https://issues.apache.org/jira/browse/HBASE-22996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chenxu updated HBASE-22996:
---
Description:
AS [~openinx] mentioned in HBASE-22082
{quote}maybe we can try to combine the buffsIterator and curItem & curItemIndex
into one iterator, seems they are doing the same thing , say tracking the
current buffer.
{quote}
will do this in this JIRA.
was:
AS [~openinx] mentioned in HBASE-22082
{quote}Better to use buffer instead of curItem here, otherwise seems strange
here although no much difference in logics. Also maybe we can try to combine
the buffsIterator and curItem & curItemIndex into one iterator, seems they are
doing the same thing , say tracking the current buffer.
{quote}
will do this in this JIRA.
> refact MultiByteBuff, combine the buffsIterator and curItem & curItemIndex
> into one iterator
>
>
> Key: HBASE-22996
> URL: https://issues.apache.org/jira/browse/HBASE-22996
> Project: HBase
> Issue Type: Improvement
>Reporter: chenxu
>Assignee: chenxu
>Priority: Minor
>
> AS [~openinx] mentioned in HBASE-22082
> {quote}maybe we can try to combine the buffsIterator and curItem &
> curItemIndex into one iterator, seems they are doing the same thing , say
> tracking the current buffer.
> {quote}
> will do this in this JIRA.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (HBASE-22996) refact MultiByteBuff, combine the buffsIterator and curItem & curItemIndex into one iterator
chenxu created HBASE-22996:
--
Summary: refact MultiByteBuff, combine the buffsIterator and
curItem & curItemIndex into one iterator
Key: HBASE-22996
URL: https://issues.apache.org/jira/browse/HBASE-22996
Project: HBase
Issue Type: Improvement
Reporter: chenxu
Assignee: chenxu
AS [~openinx] mentioned in HBASE-22082
{quote}Better to use buffer instead of curItem here, otherwise seems strange
here although no much difference in logics. Also maybe we can try to combine
the buffsIterator and curItem & curItemIndex into one iterator, seems they are
doing the same thing , say tracking the current buffer.
{quote}
will do this in this JIRA.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (HBASE-22888) Use separate classe to deal with streaming read and pread
[
https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925117#comment-16925117
]
chenxu edited comment on HBASE-22888 at 9/8/19 9:01 AM:
Thank you for the valueable comments, [~anoop.hbase]
{quote}Do we really need to do this copy? The stream reader's block index
reader can directly refer to the pread HFileReader's block index reader?
{quote}
I think it's necessary, Otherwise we need to call readMultiLevelIndexRoot and
readRootIndex in all StreamReader, and read the index from HFile again
{quote}Checking the E2E reader creation flow, I can see it will again call the
CP hooks around the StoreFileReader creation! May be even that is not needed
really? More over can we do this clone stuff within the HFileReader itself?
Same way would have been best for StoreFileReader also so that we can avoid the
CP hooks calls
{quote}
The CP hooks may be required by the upper layer？Want to know if removal will
have an impact on upper-layer applications such as phoenix.
was (Author: javaman_chen):
Thank you for the valueable comments, [~anoop.hbase]
bq. Do we really need to do this copy? The stream reader's block index reader
can directly refer to the pread HFileReader's block index reader?
I think it's necessary, Otherwise we need to call readMultiLevelIndexRoot and
readRootIndex in all StreamReader read the index info from HFile again
bq. Checking the E2E reader creation flow, I can see it will again call the CP
hooks around the StoreFileReader creation! May be even that is not needed
really? More over can we do this clone stuff within the HFileReader itself?
Same way would have been best for StoreFileReader also so that we can avoid the
CP hooks calls
The CP hooks may be required by the upper layer？Want to know if removal will
have an impact on upper-layer applications such as phoenix.
> Use separate classe to deal with streaming read and pread
> -
>
> Key: HBASE-22888
> URL: https://issues.apache.org/jira/browse/HBASE-22888
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> When switching pread to stream read, new HFileReaderImpl will be create, but
> the two different readers do not share informations with each other. maybe we
> can divide HFileReaderImpl into two different class, such as HFilePreadReader
> and HFileStreamReader. When constructing HFileStreamReader, it will copy some
> stuffs (fileInfo, index, etc) from an already existing Reader, and no need to
> do prefetch operations.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (HBASE-22888) Use separate classe to deal with streaming read and pread
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925117#comment-16925117 ] chenxu commented on HBASE-22888: Thank you for the valueable comments, [~anoop.hbase] bq. Do we really need to do this copy? The stream reader's block index reader can directly refer to the pread HFileReader's block index reader? I think it's necessary, Otherwise we need to call readMultiLevelIndexRoot and readRootIndex in all StreamReader read the index info from HFile again bq. Checking the E2E reader creation flow, I can see it will again call the CP hooks around the StoreFileReader creation! May be even that is not needed really? More over can we do this clone stuff within the HFileReader itself? Same way would have been best for StoreFileReader also so that we can avoid the CP hooks calls The CP hooks may be required by the upper layer？Want to know if removal will have an impact on upper-layer applications such as phoenix. > Use separate classe to deal with streaming read and pread > - > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (HBASE-22888) Use separate classe to deal with streaming read and pread
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu reassigned HBASE-22888: -- Assignee: chenxu > Use separate classe to deal with streaming read and pread > - > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: chenxu >Assignee: chenxu >Priority: Major > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22965) RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff
[ https://issues.apache.org/jira/browse/HBASE-22965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22965: --- Description: After introduce HBASE-21879 into our own branch, when enable data block encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been uploaded). After reading RowIndexEncoderV1, find _lastCell_ may refer to an reused ByteBuff, because DBE is not a listener of Shipper。 was: After introduce HBASE-21879 into our own branch, when enable data block encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been uploaded). After reading RowIndexEncoderV1, find lastCell may refer to an reused ByteBuff, because DEB is not a listener of Shipper。 > RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff > - > > Key: HBASE-22965 > URL: https://issues.apache.org/jira/browse/HBASE-22965 > Project: HBase > Issue Type: Bug >Reporter: chenxu >Priority: Major > Attachments: hs_regionserver_err_pid.log > > > After introduce HBASE-21879 into our own branch, when enable data block > encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been > uploaded). > After reading RowIndexEncoderV1, find _lastCell_ may refer to an reused > ByteBuff, because DBE is not a listener of Shipper。 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HBASE-22965) RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff
[ https://issues.apache.org/jira/browse/HBASE-22965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920732#comment-16920732 ] chenxu commented on HBASE-22965: FYI [~openinx] > RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff > - > > Key: HBASE-22965 > URL: https://issues.apache.org/jira/browse/HBASE-22965 > Project: HBase > Issue Type: Bug >Reporter: chenxu >Priority: Major > Attachments: hs_regionserver_err_pid.log > > > After introduce HBASE-21879 into our own branch, when enable data block > encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been > uploaded). > After reading RowIndexEncoderV1, find lastCell may refer to an reused > ByteBuff, because DEB is not a listener of Shipper。 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (HBASE-22965) RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff
chenxu created HBASE-22965: -- Summary: RS Crash due to RowIndexEncoderV1 reference to an reused ByteBuff Key: HBASE-22965 URL: https://issues.apache.org/jira/browse/HBASE-22965 Project: HBase Issue Type: Bug Reporter: chenxu Attachments: hs_regionserver_err_pid.log After introduce HBASE-21879 into our own branch, when enable data block encoding with ROW_INDEX_V1, RegionServer crashed (the crash log has been uploaded). After reading RowIndexEncoderV1, find lastCell may refer to an reused ByteBuff, because DEB is not a listener of Shipper。 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22888) Use separate classe to deal with streaming read and pread
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22888: --- Description: When switching pread to stream read, new HFileReaderImpl will be create, but the two different readers do not share informations with each other. maybe we can divide HFileReaderImpl into two different class, such as HFilePreadReader and HFileStreamReader. When constructing HFileStreamReader, it will copy some stuffs (fileInfo, index, etc) from an already existing Reader, and no need to do prefetch operations. (was: When switching from pread to stream read, new HFileReaderImpl will be created，and Prefetch will be executed again.) > Use separate classe to deal with streaming read and pread > - > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: chenxu >Priority: Major > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22888) Use separate classe to deal with streaming read and pread
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22888: --- Issue Type: Improvement (was: Bug) > Use separate classe to deal with streaming read and pread > - > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: chenxu >Priority: Major > > When switching pread to stream read, new HFileReaderImpl will be create, but > the two different readers do not share informations with each other. maybe we > can divide HFileReaderImpl into two different class, such as HFilePreadReader > and HFileStreamReader. When constructing HFileStreamReader, it will copy some > stuffs (fileInfo, index, etc) from an already existing Reader, and no need to > do prefetch operations. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (HBASE-22888) Use separate classe to deal with streaming read and pread
[ https://issues.apache.org/jira/browse/HBASE-22888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22888: --- Summary: Use separate classe to deal with streaming read and pread (was: Prefetch may be executed many times after HBASE-17910) > Use separate classe to deal with streaming read and pread > - > > Key: HBASE-22888 > URL: https://issues.apache.org/jira/browse/HBASE-22888 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: chenxu >Priority: Major > > When switching from pread to stream read, new HFileReaderImpl will be > created，and Prefetch will be executed again. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HBASE-22936) Close memStoreScanners in StoreScanner#updateReaders else memory leak
[
https://issues.apache.org/jira/browse/HBASE-22936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917401#comment-16917401
]
chenxu commented on HBASE-22936:
Looking forward to your patch, [~ram_krish]
> Close memStoreScanners in StoreScanner#updateReaders else memory leak
> -
>
> Key: HBASE-22936
> URL: https://issues.apache.org/jira/browse/HBASE-22936
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Priority: Major
> Fix For: 2.3.0, 2.1.7, 2.2.2
>
>
> Via [~aoxiang] from over on HBASE-22723
> {code}
> + if (!closeLock.tryLock()) {
> +// no lock acquired.
> +LOG.debug("StoreScanner already has the close lokc. There is no need
> to updateReaders");
> +return;
> + }
> + // lock acquired
> + updateReaders = true;
> + if (this.closing) {
> +LOG.debug("StoreScanner already closing. There is no need to
> updateReaders");
> +return;
> + }
> {code}
> We need to close memStoreScanners in StoreScanner#updateReaders before this
> two return, someone else can take over the task.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (HBASE-22905) Avoid temp ByteBuffer allocation in BlockingRpcConnection#writeRequest
[ https://issues.apache.org/jira/browse/HBASE-22905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-22905: --- Attachment: HBASE-22905-master-v1.patch Assignee: chenxu Status: Patch Available (was: Open) > Avoid temp ByteBuffer allocation in BlockingRpcConnection#writeRequest > -- > > Key: HBASE-22905 > URL: https://issues.apache.org/jira/browse/HBASE-22905 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Assignee: chenxu >Priority: Major > Attachments: HBASE-22905-master-v1.patch > > > Currently BlockingRpcConnection use ByteBufferOutputStream to serialize > CellBlock which involve temp ByteBuffer allocation, we can replace it with > netty’s ByteBufOutputStream, just like what > NettyRpcDuplexHandler#writeRequest doing -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HBASE-22380) break circle replication when doing bulkload
[ https://issues.apache.org/jira/browse/HBASE-22380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915462#comment-16915462 ] chenxu commented on HBASE-22380: There's a scenario we should consider about, when MOB feature enabled, after compaction PartitionedMobCompactor#bulkloadRefFile will be called, but the target ref file should not be replicated to the next cluster, so I think there still need a mechanism to skip the BulkLoadMarker write > break circle replication when doing bulkload > > > Key: HBASE-22380 > URL: https://issues.apache.org/jira/browse/HBASE-22380 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 3.0.0, 1.5.0, 2.2.0, 1.4.10, 2.0.5, 2.3.0, 2.1.5, 1.3.5 >Reporter: chenxu >Assignee: Wellington Chevreuil >Priority: Critical > Labels: bulkload > Fix For: 3.0.0, 1.5.0, 2.3.0, 1.4.11, 2.1.7, 2.2.2 > > > when enabled master-master bulkload replication, HFiles will be replicated > circularly between two clusters -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (HBASE-22905) Avoid temp ByteBuffer allocation in BlockingRpcConnection#writeRequest
[ https://issues.apache.org/jira/browse/HBASE-22905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915399#comment-16915399 ] chenxu commented on HBASE-22905: working on it, will upload soon > Avoid temp ByteBuffer allocation in BlockingRpcConnection#writeRequest > -- > > Key: HBASE-22905 > URL: https://issues.apache.org/jira/browse/HBASE-22905 > Project: HBase > Issue Type: Improvement >Reporter: chenxu >Priority: Major > > Currently BlockingRpcConnection use ByteBufferOutputStream to serialize > CellBlock which involve temp ByteBuffer allocation, we can replace it with > netty’s ByteBufOutputStream, just like what > NettyRpcDuplexHandler#writeRequest doing -- This message was sent by Atlassian Jira (v8.3.2#803003)
