[
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)