Memory footprint von Scripts

Hin und wieder stellt sich die Frage in welcher Sprache man ein Programm eigentlich schreiben sollte. Neben persönliche Vorlieben, Features und Modellen welche die Sprache unterstützen soll, gilt es aber auch ein Auge auf der Performance zu haben.
Bevor es nun ungezähmt aus dem Wald schallert: “Klar, C, schneller geht’s kaum”, wage ich anzumerken dass auch die Performance in der Schreibgeschwindigkeit zählt, oder der Praktikabilität, usw. Allerdings interessiert mich in diesem Artikel mehr der Speicherverbrauch.
Scriptsprachen welche meistens dynamisch typisieren oder eine Mischform aus dynamischer und statischer Typisierung verwenden brauchen oft mehr Speicher als eigentlich nötig. Daraus würde ich gerne einen Vergleich aus den populärsten Sprachen ziehen.
Basis hierfür ist ein 10.9673 MB großer JSON Dump (sagen wir halt 11MB), mit 100000 Objekten innerhalb eines Arrays. Als Implementierung wurde immer die kleinste gewählt, möglichst streams, keine Zwischenspeicher und keine Ausgabe (Ergebnis wurde natürlich vorher geprüft bevor mit der Zeitnahme begonnen wurde.
Die Messung wurde mit Valgrind durchgeführt (mit dem tool massif) und als Vergleichswert der maximale Peak in Mebibyte gemessen.

chart_time2

Nun, verloren hat ganz klar – und auch leider – PHP. Mit fast 240 Mebibyte aufgeblasenen Heap wundert man sich fast schon was eigentlich drin steht – im Speicher. Ganz gut im Mittelfeld platziert sich der Liebling der Administratoren, Perl – Gut schnell und annehmbarer Speicherverbrauch. Node ist zwar schnell aber nicht weit verbreitet weshalb es eher (auch hier ein klares leider) ein klares Schattendasein führt. Zu C++ ist noch zu sagen das hier alles Dynamisch angelegt und ein großes Framework verwendet wurde, weshalb das Ergebnis kaum zu rechnen ist.
Dieser Test ist natürlich auch in keinster Weise repräsentativ. Werden doch Shared Objects in den Speicher geladen und andere Dinge unternommen welche einen objektiven und ausgeglichenen Vergleich kaum zulassen. Aber man kann doch Stärken und Schwächen erkennen, da es sich zumindest bei den Scriptsprachen um Standardinstallationen aus einem Ubuntu (12.04 LTS) System handelt. Ansonsten folgen noch ein paar hübsche Graphen.

 

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Memory-Profiling mit Massif

Mit dem Heap-Profiler Massif kann man schnell herauszufinden, welcher Teil eines Programms am meisten Arbeitsspeicher verbraucht. Massif ist Teil von Valgrind und kann unter Ubuntu z.B. so installiert werden:

$ sudo aptitude install valgrind

Danach kann man das zu profilende Programm mit Massif starten:

$ valgrind --tool=massif ./pfad/zum/eigenen/programm --parameter

Massif schreibt die Profiling-Ergebnis in eine Datei mit dem Namen massif.out.<PID>. Wer das ganze etwas grafischer haben möchte, kann den Massif Visualizer verwenden (Paket: massif-visualizer):

Speicherwarnung für PHP

Das man bei PHP eigentlich nicht auf den Speicher achten muss ist entweder Freud oder Leid. Die Freude ist begrenzt denn ab einer gewissen Größe ist der Speicherverbrauch nicht mehr so einfach “wegzuimplementieren”.
Abhilfe schafft hier eine PECL Erweiterung namens “memtrack” die PHP Warnung anhand von Schwellwerten in die Fehlerbehandlung von PHP einkippt. Man wird also während der Entwicklung bereits gewarnt oder überprüft regelmäßig seine Logs nach ausreißern.
Die Installation ist denkbar einfach mit PECL oder per Hand:

# wget "http://pecl.php.net/get/memtrack-0.2.1.tgz"
# tar -xvzf memtrack-0.2.1.tgz
# cd memtrack-0.2.1
# phpize
# sh configure
# make install

Danach erstellt man sich einen php.ini Eintrag um das Modul erstmal zu laden:

# cat memtrack.ini
[memtrack]
extension=memtrack.so
memtrack.enabled = 1
memtrack.soft_limit=1M
memtrack.vm_limit=3M

Wir stellen eine Prozessschwelle (vm_limit) von 3MB und eine Ausführungsschwelle von 1MB. Außerdem aktivieren wir das Module global für alle laufenden PHP Interpreter Instanzen.
Mit Hilfe eines kleinen Scripts den Speicherverbrauch aufdrehen und sich über die Warnungen freuen (oder weinen):

# cat test.php

# php test.php
PHP Warning:  [memtrack] [pid 5704] user function buildArray() executed in /tmp/test.php on line 13 allocated 27787264 bytes in Unknown on line 0
PHP Stack trace:
PHP   1. {main}() /tmp/test.php:0
PHP Warning:  [memtrack] [pid 5704] virtual memory usage on shutdown: 31571968 bytes in Unknown on line 0
Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.