Praxistipp Big Data Performance Tuning

So holen Sie mehr aus Ihrem Hadoop Cluster raus

Seite: 3/3

Anbieter zum Thema

Ein Forschungsteam des Prozessorherstellers AMD erzielte 2012 einen beachtlichen Erfolg mit folgender Konfiguration auf Red Hat Linux 6.2 und 6.3:

  • Zuteilen von vier Daten-Festplatten pro DataNode;
  • zwei Map-Slots und einen Reduce-Slot (in der JVM) pro Hardware-Knoten zuweisen;
  • für Map und Reduce je ein Gigabyte anfänglichen und maximalen Java-Heap-Speicher zuweisen: ergibt insgesamt drei Gigabyte Freispeicher pro Hardware-Knoten. Pro Knoten standen nur vier Gigabyte bereit. Das restliche Gigabyte war für Caches und Buffers reserviert.

In dieser bescheidenen Konfiguration ließen sich bereits gute Resultate messen, was das Tuning bestimmter Systemkomponenten anging.

  • 1. Erhöht man die Anzahl der Daten-Disks mithilfe der Parameter dfs.name.dir und dfs.data.dir, so erhält man eine lineare Leistungssteigerung.
  • 2. Die Verdichtung von Daten hilft ebenfalls erheblich: Eine Leistungssteigerung durch Kompression um bis zu 36 Prozent wurde beobachtet. Zuständig sind die Parameter mapred.compress.map.output, mapred.map.output.compression.codec, mapred.output.compress, mapred.output.compression.type und mapred.output.compression.codec.
  • 3. Mit dem Parameter mapred.job.reuse.jvm.num.tasks kann man festlegen, ob JVM-Prozesse für MapReduce wiederverwendet werden sollen. Die Voreinstellung ist „nein“, ausgedrückt als 1. Mit dem Wert -1 lässt sich eine unbegrenzte Wiederverwendung einrichten. Dadurch kann man den Overhead verringern, der für Auf- und Abbau der JVM nötig ist. Das Team erzielte eine Leistungssteigerung von zwei Prozent.
  • 4. Die Blockgröße für das HDFS muss je nach System optimiert werden, wie oben erwähnt. Mit den Parametern dfs.block.size und mapred.max.split.size konnten die AMD-Tester Leistungssteigerungen um bis zu 20 Prozent erzielen. Ihre optimale Blockgröße lag bei 256 Megabyte.
  • 5. Die Gesamtmenge an verfügbarem Pufferspeicher, um Dateien sortieren zu können, lässt sich mit io.sort.mb festlegen (s. o.). Der Defaultwert für den Pufferspeicher liegt bei 100 (Megabyte). 1,3 Prozent dieser Größe werden jedoch von Metadaten und ihre zwischenzeitliche Auslagerung beansprucht. Die Parameter dafür sind io.sort.record.percent und io.sort.spill.percent. Optimal wäre es, die Zahl dieser Spills auf null zu reduzieren und nur den finalen Output zuzulassen. Dieses Tuning erfolgt mit dem Parameter io.sort.record.percent. Zusammen mit anderen Kniffen hierzu erzielten die Tester eine Leistungsverbesserung durch Spill-Vermeidung um 2,64 Prozent.
  • 6. Nach dem Map-Task sollte die Reduce-Phase in der jeweiligen JVM folgen. Der Zwischenschritt besteht im Kopieren der Map-Resultate. Durch Tuning der Kopier- & Verlagerungsphase sowie durch die Reduzierung der Spills auf der Reduce-Seite (analog zu denen auf der Map-Seite) erzielten die AMD-Tester eine Leistungssteigerung von beachtlichen zehn Prozent.
  • 7. Das Tuning der JVM-Konfiguration wurde in das Setzen bestimmter Flags (AggressiveOpts, UseCompressedOops, UseBiasedLocking) und in die Optimierung der Garbage Collection aufgeteilt. Die GC-Optimierung erbrachte mehr als drei Prozent mehr Performance, die Flags etwa 3,4 Prozent.
  • 8. Das Tuning der OS-Konfiguration erbrachte ingesamt rund 23 Prozent verbesserte Leistung. Diesen Erfolg erzielten die AMD-Tester mit Transparent Huge Pages (THP) in Red Hat Linux 6.2ff, mit EXT4 des Filesystem von RHEL 6.3 und mit der Wahl des IO Schedulers CFQ in RHEL 6.3 anstelle des Schedulers in Ubuntu 11.x.

Das Endergebnis bestand in einer Leistungssteigerung um den Faktor 5,6 gegenüber der minimalen Ausgangskonfiguration von vier Festplatten und um den Faktor 3,0, wenn die Baseline-Konfiguration alle verfügbaren Hardwareressourcen nutzte. Man sieht also, dass bereits die Ausgangslage für das Tuning gut bedacht sein will.

Ausblick

„Der Fokus der vergangenen Benchmarks war immer MapReduce“, erläutert Hoge. „Aktuell werden diese Werte auch mit Apache Spark verglichen. Das seit 2013 verfügbare Spark ist bei spezifischen Benchmarks um Größenordnungen schneller, sodass es In-memory-Computing beherrscht.“

(ID:43105672)