You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tajo.apache.org by "Keuntae Park (JIRA)" <ji...@apache.org> on 2013/11/22 09:16:36 UTC
[jira] [Comment Edited] (TAJO-317) Improve TajoResourceManager to
support more elaborate resource management
[ https://issues.apache.org/jira/browse/TAJO-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829783#comment-13829783 ]
Keuntae Park edited comment on TAJO-317 at 11/22/13 8:15 AM:
-------------------------------------------------------------
I've uploaded the patch for the issue:
Now, TajoResourceManager allocates container based on memory or disk slots
1. At startup time, Worker sends its resource information to ResourceManager
- tajo.worker.parallel-execution.max-num is no longer used
- if tajo.worker.resource.dedicated = true,
** memory: value from tajo.worker.resource.memory-mb (default is max heap of worker)
** disk: value from tajo.worker.resource.disks (default is number of disks)
- if tajo.worker.resoure.dedicated = false,
** memory: tajo.worker.resource.dedicated-memory-ratio * max heap of worker
** disk: number of disks
- TajoResouceManager manages memory and disk as follows:
** Memory is managed in MB: TajoResoueceManager allocates a worker based on min/max parameter specified in a container request of QueryMaster
(Detailed allocation policy is explained in 3)
** Disk is managed in slot: query master specifies the number of slots (decimal is OK) for a container in its request, then, TajoResourceManager allocated a worker that has enough slots. (Detailed allocation policy is explained in 3)
2. QueryMaster requests container with following parameters:
- ResourceRequestPriority(Memory or Disk)
- min/max memory in MB
- min/max disk slots
3. Resource allocation policy of TajoResourceManager:
- if ResourceRequestPriority = Memory,
** First, find a worker whose available memory is more than 'max'
** If not exist, find a worker that has more than 'min'
** 'min/max disk slots' is used just for updating 'used disk slot' value of the selected worker
** This mode is for memory-intensive tasks
- if ResourceRequestPriority = Disk,
** First, find a worker whose available disk slots is more than 'max'
** If not exist, find a worker has more slots than 'min'
** 'min/max memory MB' is only used for updating used memory value of the selected worker
** For disk-intensive tasks
- Logic to adjust requesting memory, disk size based on the task type is NOT YET IMPLEMENTED. For the compatibility with current allocation policy which considers memory only, every task is implemented to request 512MB memory.
** For '1 worker = 10 task' concurrency, set as
.tajo.worker.resource.dedicated=false
.tajo.worker.resource.memory-mb=5120
4. Test case
TestTajoResourceManager
was (Author: sirpkt):
I've uploaded the patch for the issue:
Now, TajoResourceManager allocates container based on memory or disk slots
1. At startup time, Worker sends its resource information to ResourceManager
- tajo.worker.parallel-execution.max-num is no longer used
- if tajo.worker.resource.dedicated = true,
** memory: value from tajo.worker.resource.memory-mb (default is max heap of worker)
** disk: value from tajo.worker.resource.disks (default is number of disks)
- if tajo.worker.resoure.dedicated = false,
** memory: tajo.worker.resource.dedicated-memory-ratio * max heap of worker
** disk: number of disks
- TajoResouceManager manages memory and disk as follows:
** Memory is managed in MB: TajoResoueceManager allocates a worker based on min/max parameter specified in a container request of QueryMaster
(Detailed allocation policy is explained in 3)
** Disk is managed in slot: query master specifies the number of slots (decimal is OK) for a container in its request, then, TajoResourceManager allocated a worker that has enough slots. (Detailed allocation policy is explained in 3)
2. QueryMaster requests container with following parameters:
- ResourceRequestPriority(Memory or Disk)
- min/max memory in MB
- min/max disk slots
3. Resource allocation policy of TajoResourceManager:
- if ResourceRequestPriority = Memory,
** First, find a worker whose available memory is more than 'max'
** If not exist, find a worker that has more than 'min'
** 'min/max disk slots' is used just for updating 'used disk slot' value of the selected worker
** This mode is for memory-intensive tasks
- if ResourceRequestPriority = Disk,
** First, find a worker whose available disk slots is more than 'max'
** If not exist, find a worker has more slots than 'min'
** 'min/max memory MB' is only used for updating used memory value of the selected worker
** For disk-intensive tasks
- Logic to adjust requesting memory, disk size based on the task type is NOT YET IMPLEMENTED. For the compatibility with current allocation policy which considers memory only, every task is implemented to request 512MB memory.
** For '1 worker = 10 task' concurrency, set as
.tajo.worker.resource.dedicated=false
.tajo.worker.resource.memory-mb=5120
- Test case
TestTajoResourceManager
> Improve TajoResourceManager to support more elaborate resource management
> -------------------------------------------------------------------------
>
> Key: TAJO-317
> URL: https://issues.apache.org/jira/browse/TAJO-317
> Project: Tajo
> Issue Type: Improvement
> Components: resource manager
> Reporter: Hyunsik Choi
> Assignee: Keuntae Park
> Fix For: 0.8-incubating
>
> Attachments: TAJO-317.patch
>
>
> h3. Status of the current Tajo Resource Manager (RM)
> * Tajo RM manages CPU, DISK resource incompletely, and it only provides resource management through memory allocations.
> * In addition, Tajo RM considers the memory resource as the fixed number of slots.
> h3. Problem
> In many cases, workloads can be categorized into I/O intensive job and CPU and memory consuming job. For example, scan and hash partition or INSERT OVERWRITE may be belong to I/O intensive job. In general, Aggregation can be belong to CPU-memory consuming job. The current RM is not fit to support selectively I/O intensive job or CPU-memory consuming job because it provides only memory slots. We need more elaborate resource management mechanism.
> In addition, in most resource management systems, the remain resource less than required resource is not allocated in response to a resource request. It is not good to fully utilize the cluster resources. In order to mitigate this problem, we need to add resilience to allocation mechanism. For example, min-max request would be useful for it.
> h3. Proposal
> * Tajo RM should provides resource management for disk and cpu-memory.
> ** Tajo RM should provide allocation request call with min, max memory request, and min, max disk request.
> *** min-max request will be useful to fully utilize remain cluster resources.
> * Each resource request should have a priority. The priority can be disk or memory.
> ** If the priority is disk
> *** disk allocation will be limited depending on the remain disk resource
> *** memory allocation will be not limited regardless of the remain memory resource, and just reduce the remain memory resource.
> ** If the priority is memory
> *** memory allocation will be limited depending on the remain memory resource
> *** disk allocation will be not limited regardless of the remain disk resource, and just reduce the remain disk resource.
> * disk resource in each worker is represented as a float value.
> ** The initial disk resource will be the number of disks which participate in HDFS data directory.
--
This message was sent by Atlassian JIRA
(v6.1#6144)