[
https://issues.apache.org/jira/browse/HBASE-13819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15207917#comment-15207917
]
Anoop Sam John commented on HBASE-13819:
----------------------------------------
Ya we had an offline discuss abt this issue.
As the client is async, there are lot of requests pumped in and response are in
Q. The Q size increases. While it is in Q, the cell block is already been
made by getting BB from the pool.
There should be some sort of a throttling and should not allow these many
responses to grow in Q.
Still one issue [~dvdreddy] noticed is that, we increase the avg running size
of the BB pool and for them it reaches till 512 KB. Initially it was 16KB.
The case is row reads. So normally the response size is much lesser than this
512 KB. Still we reserve those many for each of the BB.
I was thinking abt this time back also.. And it came in some other Jira
discuss as well..
Actually for the response CellBlock we dont need the entire cells serialized
data to be in single BB. It can be in N BBs also. Any way for writing the
response we have a BufferChain. Within this also, we can see that the actual
write to socket happens as chunks of 64KB. So when a buffer of size say 1 MB
is written, it is written in N writes to socket with 64 KB chunk size.
So when we make the cell block, we can make it on N BBs rather than one. We
need a new BBOS.. So there is no need to grow the BB within the BBOS and copy
the old content to new one. When we run out of space in current BB, get a new
one from pool. Finally all can be returned to pool.
What I wanted to see is that the pool deal with fixed sized BBs. Say all 64 KB
sized buffers. Depending on the need, the users of the pool may poll one or
more BBs
> Make RPC layer CellBlock buffer a DirectByteBuffer
> --------------------------------------------------
>
> Key: HBASE-13819
> URL: https://issues.apache.org/jira/browse/HBASE-13819
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-13819.patch, HBASE-13819_branch-1.patch,
> HBASE-13819_branch-1.patch, HBASE-13819_branch-1.patch
>
>
> In RPC layer, when we make a cellBlock to put as RPC payload, we will make an
> on heap byte buffer (via BoundedByteBufferPool). The pool will keep upto
> certain number of buffers. This jira aims at testing possibility for making
> this buffers off heap ones. (DBB) The advantages
> 1. Unsafe based writes to off heap is faster than that to on heap. Now we are
> not using unsafe based writes at all. Even if we add, DBB will be better
> 2. When Cells are backed by off heap (HBASE-11425) off heap to off heap
> writes will be better
> 3. When checked the code in SocketChannel impl, if we pass a HeapByteBuffer
> to the socket channel, it will create a temp DBB and copy data to there and
> only DBBs will be moved to Sockets. If we make DBB 1st hand itself, we can
> avoid this one more level of copying.
> Will do different perf testing with changed and report back.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
