[
https://issues.apache.org/jira/browse/HBASE-17073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15659452#comment-15659452
]
Anoop Sam John commented on HBASE-17073:
----------------------------------------
In case of old BBBPool it was twice handler count by def. The 2x factor make
sense. If all handlers handle reads, at the end of the handler process, we will
make the response cellblock and add the Call to connection's response Q and the
single Responder thread takes connections and response from that one by one and
do the socket write. So there is chances that by the time a handler originated
response is actually done and so released the BBs it used, the handler might
have processed one more read req. On an avg 2x was added. We should continue to
consider that fact. So 32x may be still less! Go with 32 * 2 * #handers only?
For 100 handlers this is total 400 MB.
> Increase the max number of buffers in ByteBufferPool
> ----------------------------------------------------
>
> Key: HBASE-17073
> URL: https://issues.apache.org/jira/browse/HBASE-17073
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
>
> Before the HBASE-15525 issue fix, we had variable sized buffers in our buffer
> pool. The max size upto which one buffer can grow was 2 MB. Now we have
> changed it to be a fixed sized BBPool. By default 64 KB is the size of each
> buffer. But the max number of BBs allowed to be in the pool was not changed.
> ie. twice the number of handlers. May be we should be changing increasing it
> now? To make it equal to the way like 2 MB, we will need 32 * 2 * handlers.
> There is no initial #BBs any way. 2 MB is the default max response size what
> we have. And write reqs also, when it is Buffered mutator 2 MB is the default
> flush limit. We can make it to be 32 * #handlers as the def max #BBs I
> believe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
