Cloudera Docs

Configuring Resource Parameters

After enabling cgroups, you can restrict and limit the resource consumption of roles (or role groups) on a per-resource basis.

All of these parameters can be found in the Cloudera Manager Admin Console, under the Resource Management category:
  • CPU Shares - The more CPU shares given to a role, the larger its share of the CPU when under contention. Until processes on the host (including both roles managed by Cloudera Manager and other system processes) are contending for all of the CPUs, this will have no effect. When there is contention, those processes with higher CPU shares will be given more CPU time. The effect is linear: a process with 4 CPU shares will be given roughly twice as much CPU time as a process with 2 CPU shares.

    Updates to this parameter are dynamically reflected in the running role.

  • I/O Weight - The greater the I/O weight, the higher priority will be given to I/O requests made by the role when I/O is under contention (either by roles managed by Cloudera Manager or by other system processes).

    This only affects read requests; write requests remain unprioritized. The Linux I/O scheduler controls when buffered writes are flushed to disk, based on time and quantity thresholds. It continually flushes buffered writes from multiple sources, not certain prioritized processes.

    Updates to this parameter are dynamically reflected in the running role.

  • Memory Soft Limit - When the limit is reached, the kernel will reclaim pages charged to the process if and only if the host is facing memory pressure. If reclaiming fails, the kernel may kill the process. Both anonymous as well as page cache pages contribute to the limit.

    After updating this parameter, you must restart the role for changes to take effect.

  • Memory Hard Limit - When a role's resident set size (RSS) exceeds the value of this parameter, the kernel will swap out some of the role's memory. If it is unable to do so, it will kill the process. The kernel measures memory consumption in a manner that does not necessarily match what the top or ps report for RSS, so expect that this limit is a rough approximation.

    After updating this parameter, you must restart the role for changes to take effect.

Example: Protecting Production MapReduce Jobs from Impala Queries

Suppose you have MapReduce deployed in production and want to roll out Impala without affecting production MapReduce jobs. For simplicity, we will make the following assumptions:
  • The cluster is using homogenous hardware
  • Each worker host has two cores
  • Each worker host has 8 GB of RAM
  • Each worker host is running a DataNode, TaskTracker, and an Impala Daemon
  • Each role type is in a single role group
  • Cgroups-based resource management has been enabled on all hosts
Action Procedure
CPU
  1. Leave DataNode and TaskTracker role group CPU shares at 1024.
  2. Set Impala Daemon role group's CPU shares to 256.
  3. The TaskTracker role group should be configured with a Maximum Number of Simultaneous Map Tasks of 2 and a Maximum Number of Simultaneous Reduce Tasks of 1. This yields an upper bound of three MapReduce tasks at any given time; this is an important detail for memory sizing.
Memory
  1. Set Impala Daemon role group memory limit to 1024 MB.
  2. Leave DataNode maximum Java heap size at 1 GB.
  3. Leave TaskTracker maximum Java heap size at 1 GB.
  4. Leave MapReduce Child Java Maximum Heap Size for Gateway at 1 GB.
  5. Leave cgroups hard memory limits alone. We'll rely on "cooperative" memory limits exclusively, as they yield a nicer user experience than the cgroups-based hard memory limits.
I/O
  1. Leave DataNode and TaskTracker role group I/O weight at 500.
  2. Impala Daemon role group I/O weight is set to 125.
When you're done with configuration, restart all services for these changes to take effect. The results are:
  1. When MapReduce jobs are running, all Impala queries together will consume up to a fifth of the cluster's CPU resources.
  2. Individual Impala Daemons will not consume more than 1 GB of RAM. If this figure is exceeded, new queries will be cancelled.
  3. DataNodes and TaskTrackers can consume up to 1 GB of RAM each.
  4. We expect up to 3 MapReduce tasks at a given time, each with a maximum heap size of 1 GB of RAM. That's up to 3 GB for MapReduce tasks.
  5. The remainder of each host's available RAM (6 GB) is reserved for other host processes.
  6. When MapReduce jobs are running, read requests issued by Impala queries will receive a fifth of the priority of either HDFS read requests or MapReduce read requests.