Skip to main content

Hadoop server performance tuning


To tune a Hadoop cluster from a DevOps perspective needs an understanding of the kernel principles and linux. The following article will describe the most important parameters together with tricks for an optimal tuning.


Typically modern Linux systems (Linux 2.6 +) use swapping to avoid OOM (Out of Memory) to protect the system from kernel freezes. But Hadoop uses Java, and typically Java is configured with MAXHEAPSIZE per service (HDFS, HBase, Zookeeper etc). The configuration has to match the available memory in the system. A common formula for MapReduce1:

TOTAL_MEMORY = (Mappers + Reducers) * CHILD_TASK_HEAP + TT_HEAP + DN_HEAP + RS_HEAP + OTHER_SERVICES_HEAP + 3GB (for OS and caches)

For MapReduce2 YARN takes care about the resources, but only for services which are running as YARN Applications. [1], [2]

Disable swappiness is done one the fly per
echo 0 > /proc/sys/vm/swappiness

and persistent after reboots per sysctl.conf:
echo “vm.swappiness = 0” >> /etc/sysctl.conf

Additionally, RedHat implemented in kernel 2.6.39 THP (transparent huge pages swapping). THP reduces the I/O of an I/O based application at linux systems up 30%. It’s highly recommended to disable THP.

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

To do that at boot time automatically, I used /etc/rc.local:
if test -f /sys/kernel/mm/redhat_transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
if test -f /sys/kernel/mm/redhat_transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

Another nice tuning trick is the use of vm.overcommit_memory. This switch enables the overcommitting of virtual memory. Mostly, virtual memory sparse arrays using zero pages - as Java does when the memory for a VM is allocated. In most circumstances these pages contain no data, and the allocated memory can be reused (overcommitted) by other pages. With this switch the OS knows that always enough memory is available to backup the virtual pages.

This feature can be configured at runtime per:

sysctl -w vm.overcommit_memory = 1
sysctl -w vm.overcommit_ratio = 50

and permanently per /etc/sysctl.conf.

Network / Sockets

On highly used and large Linux based clusters the default sockets and network configuration can slow down some operations. This section covers some of the possibilities I figured out over the years. But please be aware of the use, since this affects the network communications.

First of all, enable the whole available port range of max available sockets:

sysctl -w net.ipv4.ip_local_port_range = 1024 65535

Additionally, increasing the recycling time of sockets avoids large TIME_WAIT queues. Re-useing the sockets for new connections can speed up the network communication. It’s to be used with caution and depends highly on the network stack and the running jobs within your cluster. The performance can grow, but also drop dramatically, since we now fast recycle the connections in the WAIT status. Typically used in clusters with a high ingest rate like HBase or Storm, Kafka etc.

sysctl -w net.ipv4.tcp_tw_recycle = 1
sysctl -w net.ipv4.tcp_tw_reuse = 1

For the same purpose, the network buffers backlog can be overfilled. In this case, new connections can be dropped or deleted - which leads to performance issues. Raising the backlog up to 16MB / Socket is mostly enough, together with the number of outstanding syn - requests and backlog sockets.

sysctl -w net.core.rmem_max = 16777216
sysctl -w net.core.wmem_max = 16777216
sysctl -w net.ipv4.tcp_max_syn_backlog = 4096
sysctl -w net.ipv4.tcp_syncookies = 1
sysctl -w net.core.somaxconn = 1024

=> Remember, this is not a generic tuning trick. On generic purpose clusters playing around with the network stack is not safe at all.  

Disk / Filesystem / File descriptors

Linux tracks the file access time, and that means a lot more disk seeks. But HDFS writes once, reads many times, and the Namenode tracks the time. Hadoop doesn't need to track the access time on the OS level, it’s safe to disable this per data disk per mount options.

/dev/sdc /data01 ext3 defaults,noatime 0 

Eliminate the root reserved space on partitions. The nature of EXT3/4 reserves 5% of per disk for root. That means the systems will have a lot of unused space. Disable the root reserved space on Hadoop disk

mkfs.ext3 –m 0 /dev/sdc

If the disk is already mounted this can be done forever per 

tune2fs -m 0 /dev/sdc

An optimal server has one HDFS mount point per disk, and one or two dedicated disks for logs and the operating system.

File handler and processes

Typically a Linux system has very conservative file handles configured. Mostly, these handlers are enough for small application servers, but not for Hadoop. When the file handler are to less, Hadoop reports that per Too many open files - to avoid that raise the limits up.

echo hdfs – nofile 32768 >> /etc/security/limits.conf
echo mapred – nofile 32768 >> /etc/security/limits.conf

Additionally the max. processes, too
echo hbase – nofile 32768 >> /etc/security/limits.conf
echo hdfs – nproc 32768 >> /etc/security/limits.conf
echo mapred – nproc 32768 >> /etc/security/limits.conf
echo hbase – nproc 32768 >> /etc/security/limits.conf

DNS / Name resolution

The communication of Hadoop’s Ecosystem depends highly on a correct DNS resolution. Typically the name resolution is configured per /etc/hosts. Important is, that the canonical name must be the FQDN of the server, see the example. one namenode two datanode

If DNS is used the system’s hostname must match the FQDN in forward as well as reverse name resolution.To reduce the latency of DNS lookups use the name service caching daemon (nscd), but don’t cache passwd, group, netbios informations.

There are also a lot of specific tuning tricks within the Hadoop Ecosystem, which will be discussed in one of the following articles.


  1. Thank you for this great article! I will try these on my environment. +1


Post a Comment

Popular posts from this blog

Deal with corrupted messages in Apache Kafka

Under some strange circumstances it can happen that a message in a Kafka topic is corrupted. This happens often by using 3rd party frameworks together with Kafka. Additionally, Kafka < 0.9 has no lock at at the consumer read level, but has a lock on Log.write(). This can cause a rare race condition, as described in KAKFA-2477 [1]. Probably a log entry looks like: ERROR Error processing message, stopping consumer: ($) kafka.message.InvalidMessageException: Message is corrupt (stored crc = xxxxxxxxxx, computed crc = yyyyyyyyyy Kafka-Tools Kafka stores the offset of every consumer in Zookeeper. To read out the offsets, Kafka provides handy tools [2]. But also can be used, at least to display the consumer and the stored offsets. First we need to find the consumer for a topic (> Kafka 0.9): bin/ --zookeeper management01:2181 --describe --group test Prior to Kafka 0.9 the only possibility to get this inform

Hive query shows ERROR "too many counters"

A hive job face the odd " Too many counters:"  like Ended Job = job_xxxxxx with exception 'org.apache.hadoop.mapreduce.counters.LimitExceededException(Too many counters: 201 max=200)' FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MapRedTask Intercepting System.exit(1) These happens when operators are used in queries ( Hive Operators ). Hive creates 4 counters per operator, max upto 1000, plus a few additional counters like file read/write, partitions and tables. Hence the number of counter required is going to be dependent upon the query.  To avoid such exception, configure " mapreduce.job.counters.max " in mapreduce-site.xml to a value above 1000. Hive will fail when he is hitting the 1k counts, but other MR jobs not. A number around 1120 should be a good choice. Using " EXPLAIN EXTENDED " and " grep -ri operators | wc -l " print out the used numbers of operators. Use this value to tweak the MR s

GPT & GenAI for Startup Storytelling

OpenAI and Bard   are the most used GenAI tools today; the first one has a massive Microsoft investment, and the other one is an experiment from Google. But did you know that you can also use them to optimize and hack your startup?  For startups, creating pitch scripts, sales emails, and elevator pitches with generative AI (GenAI) can help you not only save time but also validate your marketing and wording. Curious? Here are a few prompt hacks for startups to create,improve, and validate buyer personas, your startup's mission/vision statements, and unique selling proposition (USP) definitions. First Step: Introduce yourself and your startup Introduce yourself, your startup, your website, your idea, your position, and in a few words what you are doing to the chatbot: Prompt : I'm NAME and our startup NAME, with website URL, is doing WHATEVER. With PRODUCT NAME, we aim to change or disrupt INDUSTRY. Bard is able to pull information from your website. I'm not sure if ChatGPT