[ 
https://issues.apache.org/jira/browse/CASSANDRA-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15340326#comment-15340326
 ] 

T Jake Luciani commented on CASSANDRA-11870:
--------------------------------------------

I'm trying to weigh the value of this approach, is this something people 
experience in the wild?  It seems if you hit this you would simply bump the JVM 
flag.  You also have your own flag you need to size appropriately so how is 
this really any operationally better?  

This might not be appropriate for this issue but looking at the patch it seems 
we should try and consolidate calls to ByteBuffer.allocateDirect() with 
BufferPool.tryGet()/put() which gracefully handles running out of DirectMemory 
and recycling(). But is currently sized by the 
DatabaseDescriptor.getFileCacheSizeInMB() which seems wrong to me, since it's a 
generic buffer pool.

> Consider allocating direct buffers bypassing ByteBuffer.allocateDirect
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-11870
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11870
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Robert Stupp
>            Assignee: Robert Stupp
>            Priority: Minor
>             Fix For: 3.x
>
>
> As outlined in CASSANDRA-11818, {{ByteBuffer.allocateDirect}} uses 
> {{Bits.reserveMemory}}, which is there to respect the JVM setting 
> {{-XX:MaxDirectMemorySize=...}}.
> {{Bits.reserveMemory}} first tries an "optimistic" {{tryReserveMemory}} and 
> exits immediately on success. However, if that somehow doesn't succeed, it 
> triggers a {{System.gc()}}, which is bad IMO (however, kind of how direct 
> buffers work in Java). After that GC it sleeps and tries to reserve the 
> memory up to 9 times - up to 511 ms - and then throws 
> {{OutOfMemoryError("Direct buffer memory")}}.
> This is unnecessary for us since we always immediately "free" direct buffers 
> as soon as we no longer need them.
> Proposal: Manage direct-memory reservations in our own code and skip 
> {{Bits.reserveMemory}} that way.
> (However, Netty direct buffers are not under our control.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to