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

ASF GitHub Bot commented on ORC-409:
------------------------------------

GitHub user prasanthj opened a pull request:

    https://github.com/apache/orc/pull/313

    ORC-409: Changes for extending MemoryManagerImpl

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/prasanthj/orc ORC-409

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/orc/pull/313.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #313
    
----
commit 9cc833d560da188fd48ece42c31d1daa9ea6bc08
Author: Prasanth Jayachandran <prasanthj@...>
Date:   2018-09-28T00:51:57Z

    ORC-409: Changes for extending MemoryManagerImpl

----


> Changes for extending MemoryManagerImpl
> ---------------------------------------
>
>                 Key: ORC-409
>                 URL: https://issues.apache.org/jira/browse/ORC-409
>             Project: ORC
>          Issue Type: Bug
>    Affects Versions: 1.5.4, 1.6.0
>            Reporter: Prasanth Jayachandran
>            Assignee: Prasanth Jayachandran
>            Priority: Major
>
> Orc memory manager uses MemoryMX bean to get max heap usage and assumes 50% 
> (configurable) is available for orc writers. This works well if container 
> model where container size is close to Xmx. In LLAP for example, a single 
> container runs multiple executors and a single task take up 50% of heap which 
> is typically much more that the task executors own memory limit. 
> Example: 128Gb container + 32 executors (assuming no cache) means there is 
> 4GB available per executor. But a single task that opens multiple orc writers 
> in the default case will assume 64GB memory is available for orc when in fact 
> it should only use 2GB from memory per executor.
>  
> WriterOption provides a mechanism to plug-in a custom memory manager for such 
> scenarios which is greate. But if the custom memory manager want to extend 
> MemoryManagerImpl class, MemoryManagerImpl should use getTotalMemoryPool() 
> everywhere so that custom memory manager can just Override 
> getTotalMemoryPool() method and rest of the code from MemoryManagerImpl. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to