[
https://issues.apache.org/jira/browse/HBASE-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833622#comment-13833622
]
Nicolas Liochon commented on HBASE-9535:
----------------------------------------
bq. do you have any gc perf numbers before and after the patch? I am
interesting to know is there any scenarios existing could observe the gc
improvement after pooling ipc memory.
I will do a test... when it works ;-)
I'm aiming more at the array copy here. But it could have a nice effect on the
gc as well when the system is loaded; the query could get promoted to older
generations (may be).
bq. Do we need a BB of the size of the request? Would be better if we allocated
fix sized small'ish (8-128k) BBs and read in chunks.
I don't know actually. I'm trying to minimize the changes. I suppose I would
have to create a specific InputStream to hide this for the prototobuf parser.
The idea is nice. I don't know if we have lock issues, that would justify
doing a single read to help to free the lock sooner.
bq. In that case I would posit that we won't need a pool.
Do you have some insight on this: there is a lot of "it depends on the jvm and
the hardware" when it comes to the cost of doing a direct allocate. If we can
make more assumptions on the allocation speed on "jvm 1.7+ on modern hardware",
it would help for sure.
> Try a pool of direct byte buffers handling incoming ipc requests
> ----------------------------------------------------------------
>
> Key: HBASE-9535
> URL: https://issues.apache.org/jira/browse/HBASE-9535
> Project: HBase
> Issue Type: Brainstorming
> Reporter: stack
> Assignee: stack
> Attachments: 9535.v1.patch
>
>
> ipc takes in a query by allocating a ByteBuffer of the size of the request
> and then reading off the socket into this on-heap BB.
> Experiment with keeping a pool of BBs so we have some buffer reuse to cut on
> garbage generated. Could checkout from pool in RpcServer#Reader. Could
> check back into the pool when Handler is done just before it queues the
> response on the Responder's queue. We should be good since, at least for
> now, kvs get copied up into MSLAB (not references) when data gets stuffed
> into MemStore; this should make it so no references left over when we check
> the BB back into the pool for use next time around.
> If on-heap BBs work, we could then try direct BBs (Allocation of DBBs takes
> time so if already allocated, should be good. GC of DBBs is a pain but if in
> a pool, we shouldn't be wanting this to happen). The copy from socket to the
> DBB will be off-heap (should be fast).
> Could start w/ the HDFS DirectBufferPool. It is unbounded and keeps items by
> size (we might want to bypass the pool if an object is > size N).
> DBBs for this task would contend w/ offheap BBs used in BlockReadLocal when
> short-circuit reading. It'd be a bummer if we had to allocate big objects
> on-heap. Would still be an improvement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
