Wir verwenden Python bei Zendesk häufig, um Produkte für maschinelles Lernen (ML) zu entwickeln. Eines der häufigsten Leistungsprobleme, auf die wir bei Anwendungen für maschinelles Lernen gestoßen sind, sind Speicherlecks und -spitzen. Der Python-Code wird normalerweise in Containern über verteilte Verarbeitungsframeworks wie Hadoop, Spark und AWS Batch ausgeführt. Jedem Container wird eine feste Menge an Speicher zugewiesen. Sobald die Codeausführung die festgelegte Speichergrenze überschreitet, wird der Container aufgrund von Fehlern wegen fehlenden Speichers beendet.
Eine schnelle Lösung besteht darin, die Speicherzuweisung zu erhöhen. Dies kann jedoch zu einer Verschwendung von Ressourcen führen und die Stabilität der Produkte aufgrund von unvorhersehbaren Speicherspitzen beeinträchtigen. Die Ursachen für Speicherlecks können sein:
- Große Objekte, die nicht freigegeben werden
- Referenzzyklen innerhalb des Codes
- Unterliegende Bibliotheken/Erweiterungen, die Speicher lecken
Eine nützliche Übung ist die Erstellung eines Profils für die Speichernutzung der Anwendungen, um ein besseres Verständnis für die Speichereffizienz des Codes und der zugrunde liegenden Pakete zu erhalten. Dieser Beitrag behandelt:
- Profilieren der Speichernutzung der Anwendung über die Zeit
- Wie man die Speichernutzung in bestimmten Teilen des Programms untersucht
- Tipps zum Debuggen von Speicherproblemen
Mit dem memory-profile-Paket kann man die Speichernutzung über die Zeit während der Ausführung des Python-Codes betrachten.
# install the required packages
pip install memory_profiler
pip install matplotlib# run the profiler to record the memory usage
# sample 0.1s by defaut
mprof run --include-children python fantastic_model_building_code.py# plot the recorded memory usage
mprof plot --output memory-profile.png
Die Option include-children bezieht den Speicherverbrauch aller Kindprozesse mit ein, die über den Elternprozess erzeugt werden. Diagramm A zeigt einen iterativen Modelltrainingsprozess, bei dem der Speicher zyklisch ansteigt, wenn Stapel von Trainingsdaten verarbeitet werden. Die Objekte werden freigegeben, sobald die Garbage Collection einsetzt.
Wenn der Speicherverbrauch ständig ansteigt, besteht ein potenzielles Problem mit Speicherlecks. Hier ist ein Beispielskript, um dies zu veranschaulichen.