Most Read This Week
So What? – Monitoring Hadoop Beyond Ganglia
Don’t just run Hadoop jobs at scale, run them efficiently and at scale
By: Michael Kopp
Apr. 29, 2013 10:15 AM
Over the last couple of months I have been talking to more and more customers who are either bringing their Hadoop clusters into production or have already done so and are now getting serious about operations. This leads to some interesting discussions about how to monitor Hadoop properly and one thing pops up quite often: Do they need anything beyond Ganglia? If yes, what should they do beyond it?
The problem in a Hadoop system is of course its size. Nothing new for us, some of our customers monitor well beyond 1000+ JVMs with CompuwareAPM. The "advantage" in a Hadoop system is its relative conformity - every node looks pretty much like the other. This is what Ganglia leverages.
Cluster Monitoring with Ganglia
This chart shows the CPU load on a 1000 Server cluster that has roughly 15.000 CPUs
It tells us the number of available cores in the system and the number of running processes (in theory a core can never handle more than one process at a time) and the 1-min load average. If the system is getting fully utilized the 1-min load average would approach the total number of CPUs. Another view on this is the well-known CPU utilization chart:
CPU Utilization over the last day. While the utilization stays well below 10% we see a lot of I/O wait spikes.
While the load chart gives a good overall impression of usage, the utilization tells us the story of how the CPUs are used. While typical CPU charts show a single server, Ganglia specializes in showing whole clusters (the picture shows CPU usage of a 1000 machine cluster). In the case of the depicted chart we see that the CPUs are experiencing a lot of I/O wait spikes, which points toward heavy disk I/O. Basically it seems the disk I/O is the reason that we cannot utilize our CPU better at these times. But in general our cluster is well underutilized in terms of CPU.
Trends are also easy to understand, as can be seen in this memory chart over a year.
Memory capacity and usage over a year
All this looks pretty good, so what is missing? The "so what" and "why" is what is missing. If my memory demand is growing, I have no way of knowing why it is growing. If the CPU chart tells me that I spend a lot of time waiting, it does not tell what to do, or why that is so? These questions are beyond the scope of Ganglia.
What about Hadoop specifics?
Capacity of the DataNodes over time
Capacity of the Name Nodes over time
The DataNode Operations give me an impression of I/O pressure on the Hadoop cluster
All these charts can of course be easily built in any modern monitoring or APM solution like CompuwareAPM, but Ganglia gives you a simple starting point; and it's Free as in Beer.
What's missing again is the so what? If my jobs are running a lot longer than yesterday, what should I do? Why do they run longer? A Hadoop expert might dig into 10 different charts around I/O and Network, spilling, look at log files among other things and try an educated guess as to what might be the problem. But we aren't all experts, neither do we have the time to dig into all of these metrics and log files all the time.
This is the reason that we and our customers are moving beyond Ganglia - to solve the "Why" and "So What" within time constraints.
Beyond the Basics #1 - Understanding Cluster Utilization
The CPU Usage in the Hadoop Cluster on per User basis
In this example I wanted to monitor which user consumed how much of my Amazon EMR cluster. If we see a user or pool that occupies a lot of the cluster we can course also see which jobs are running and how much of the cluster they occupy.
The CPU Usage in the Hadoop Cluster on per Job basis
And this will also tell us if that job has always been there, and just uses a lot more resources now. This would be our cue to start analyzing what has changed.
Beyond the Basics #2 - Understanding why my jobs are slow(er)
In which phase of the map reduce do we spend the most time, or did we spend more time than yesterday? Understanding these timings in context with the respective job counters, like Map Input or Spilled Records, helps us understand why the phase took longer.
Overview of the time spent in different phases and the respective input/output counters
At this point we will already have a pretty good idea as to what happened. We either simply have more data to crunch (more input data) or a portion of the MapReduce job consumes more CPU (code change?) or we spill more records to disk (code change or Hadoop config change?). We might also detect an unbalanced cluster in the performance breakdown.
This job is executing nearly exclusively on a single node instead of distributing
In this case we want to check whether all the involved nodes processed the same amount of data
Here we see that there is a wide range from minimum, average to maximum on mapped input and output records. The data is not balanced
or if the difference can again be found in the code (different kinds of computations). If we are running against HBase we might of course have an issue with HBase performance or distribution.
At the beginning of the job only a single HBase region Server consumes CPU while all others remain idle
On the other hand, if a lot of mapping time is spent in the garbage collector then you should maybe invest in larger JVMs.
The Performance Breakdown of this particular job shows considerable time in GC suspension
If spilling data to disk is where we spend our time, we should take a closer look at that phase. It might turn out that all of our time is spent on disk wait.
If the Disk were the bottleneck we would see it on disk I/O here
Now if disk write is our bottleneck, then really the only thing that we can do is reduce the map output records. Adding a combiner will not reduce the disk write (it will actually increase it, read here). In other words combining only optimizes the shuffle phase, thus the amount of data sent over the network, but not spill time!!
And at the very detailed level we can look at single task executions and understand in detail what is really going on.
The detailed data about each Map, Reduce Task Atttempt as well as the spills and shuffles
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads