Github user kkhatua commented on the issue:
https://github.com/apache/drill/pull/922
@paul-rogers
The reason this would be needed is because the system admin might not be
the one managing the specifics of the Drill memory allocations. This allows a
node admin to define the limits within which Drill will work, while the
specifications can be delegated to the drill-env.sh script which is managed by
a power user.
There isn't a conflict with the way a service like Warden would allocate
memory, because it does not need to manage the internal allocations, only the
overall. The Drill service will continue to own its configuration's specifics.
Your solution is pretty much in line with what the PR proposes. The
exception being that, in the presence of the env variable defined, the
specifications **cannot** oversubscribe the available (or max permissible)
memory. In case of oversubscribing, Drill will not startup.
If there are uber resource managers (for e.g. YARN), they have the option
of either
- providing this limit and relying on files like ```drill-env.sh``` to
specify the limits...
or
- provide the explicit parameters for Heap, DirectMemory, etc to the JVM
and **not** have to specify ```DRILLBIT_MAX_PROC_MEM``` .
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
