Wir sind bei diesem Absturzproblem ziemlich ratlos, da wir keine Tracebacks oder andere Nachrichten darüber erhalten, was eigentlich falsch ist. Daher war es schwierig, das Problem zu beheben. Wie auch immer, los geht’s.
Wir haben eine Workstation, auf der wir unsere Analysearbeit in Python ausführen. Das Problem besteht im Wesentlichen darin, dass das System abstürzt, wenn wir an Notebooks arbeiten (oder das unten gezeigte Testskript ausführen). Der Absturz besteht aus einem Einfrieren des Betriebssystems und einem anschließenden Neustart. Es gibt keine Informationen darüber, was passiert ist, nur dass die Maschine einfriert und neu startet.
Die Abstürze treten am häufigsten auf, wenn wir ein Notebook ausführen und es bitten, etwas zu viel zu plotten. Es ist uns unmöglich, „zu viel plotten“ genau zu definieren, aber das folgende Beispiel ist ein Extremfall, der das Problem verdeutlicht. Das Skript verursacht manchmal schnell einen Absturz und manchmal dauert es etwas länger. Aber es wird unvermeidlich einen Absturz verursachen.
Nachfolgend sind einige der Dinge aufgeführt, die wir ausführen und die nach unseren bisherigen Untersuchungen Teil des Problems zu sein scheinen:
- Ubuntu 18.04
- Anaconda 5.2.0 mit MKL
- Numpy 1.16.2
- Matplotlib 3.0.3
- Jupyter 1.0.0
Die Zusammenfassung der Ergebnisse lautet:
- Die Basisinstallation von Anaconda verwendet Numpy mit MKL und hat Matplotlib mit seinen Abhängigkeiten innerhalb der Anaconda-Distribution verknüpft. Das Ausführen des folgenden Testskripts mit Python führt jedes Mal zu einem Absturz. ETA: Wir haben verschiedene Backends für Matplotlib ausprobiert, aber es hat keinen Unterschied gemacht.
- Wenn wir das Testskript von einer Anaconda-Distribution ausführen, in der Numpy von Conda installiert wurde, abernichtmit MKL und Matplotlib wurde über pip installiert undnichtüber Conda, dann läuft das Skript einwandfrei. Wenn wir entweder MKL verwendenoderConda statt pip zum Installieren von Matplotlib, wir bekommen den Absturz. Wir können das Skript auch mit einer Nicht-Anaconda-Distribution problemlos ausführen, bei der alles über pip installiert ist (und keine andere MKL-Verknüpfung).
- Wenn wir eine Jupyter-Notebook-Version des Skripts erstellen (ein Diagramm pro Zelle) und alle Zellen ausführen, verursacht das Notebook den Absturz. Alle unsere Gewinne in Punkt 2 werden also allein durch die Verwendung von Jupyter zunichte gemacht.
- Normalerweise führen wir Jupyter in einem Docker-Container und hinter einem Nginx-Reverse-Proxy aus. Wir haben dies als Ursache ausgeschlossen, da die Docker-Images ebenfalls Ubuntu 18.04 sind und wir die Tests direkt auf dem Host-Computer ausgeführt haben, um Docker-Probleme auszuschließen.
- Wenn wir die Ressourcennutzung verfolgen, stellen wir natürlich fest, dass die CPU-Auslastung mit MKL im Bereich von 300-400 % liegt. Wir haben eine 12-Kern-CPU und erreichen regelmäßig höhere Prozentwerte. Wir verbrauchen beim Ausführen des Testskripts kaum ein Gigabyte Speicher, obwohl wir eine Kapazität von 128 GB haben, und führen regelmäßig Datenanalysen durch, die uns weit über dieses 1 GB hinausbringen.
Das deckt ungefähr alles ab, was wir herausfinden konnten. Da die Abstürze so stark mit dem Plotten zusammenhingen, schien es ziemlich offensichtlich, dass Optimierungen an Matplotlib zumindest eine teilweise Lösung brachten. Das MKL-Problem fügte noch einen rätselhaften Störfaktor hinzu, aber wir dachten, wir hätten eine Problemumgehung. Aber als wir dann zurückgingen, um es in Jupyter zu testen, stellte sich heraus, dass, obwohl wir das Skript zum Laufen gebracht hatten, Punkt 4 immer noch zeigt, dass wir nicht alles vollständig behoben hatten.
Und das bringt uns zu diesem Beitrag. Nichts, was ich online gesehen habe, kommt auch nur annähernd an das heran, was wir beobachten, und ich habe noch nie etwas Vergleichbares gesehen. Ich habe keine Ideen mehr und frage mich, ob es sich tatsächlich um ein Hardwareproblem handelt.
Für jede Hilfe beim Knacken dieser Nuss wäre ich sehr dankbar. Ich denke darüber nach, dies auf unserer Workstation mit einer anderen Linux-Distribution als Ubuntu auszuprobieren.
# Test Script
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
# None of the dataframe stuff seems to matter nor the figure size, just
# that we're trying to plot a bunch
n = 100000
figsize = (8, 6)
df = pd.DataFrame(
{
'A': np.cumsum(np.random.rand(n)) / np.arange(1, n+1, 1),
'B': np.cumsum(np.random.rand(n)) / np.arange(1, n+1, 1),
'C': np.cumsum(np.random.rand(n)) / np.arange(1, n+1, 1)
},
index=pd.date_range('2001-01-01 12:00:00', freq='S', periods=n)
)
df.plot(figsize=figsize)
# closing the figures just in case, but doesn't make a difference
plt.close(plt.gcf())
...
# Repeat the dataframe and plotting snippet a lot, like ~100x
...
HINZUFÜGT: Mein Kollege hat diesen Beitrag heute Morgen gefunden. Er liefert ein stärkeres Argument für ein Hardwareproblem.https://forum.manjaro.org/t/python-matplotlib-script-crashes-system/44052/10
ÜBERARBEITETES UPDATE: Das Ausschalten von Hyperthreading im BIOS hat nicht funktioniert. Aber den Boot-Vorschlägen aus diesem Beitrag auf manjaro.org folgendtathelfen, sofern sie nicht in Verbindung mit der Deaktivierung von Hyperthreading im BIOS durchgeführt wurden.
Antwort1
AProblemumgehungbesteht darin, die Starteinstellung zu verwenden apci=off, die in diesem Forenbeitrag beschrieben wird: https://forum.manjaro.org/t/python-matplotlib-script-crashes-system/44052/10
Für uns ist das akzeptabel, aber wenn jemand tatsächlich eine Lösung oder Erklärung hat oder wirklich irgendetwas hinzuzufügen hat, bin ich ganz Ohr.
Antwort2
Ich hatte genau die gleichen Probleme mit einem neuen Ubuntu 18.04.2 LTS-System und der neuesten Anaconda-Neuinstallation. Interessanterweise hatte ich genau das gleiche Verhalten (Einfrieren + Systemabsturz) unter Windows 10 Pro (komplett auf dem neuesten Stand).
Soweit ich weiß, erlaubt Windows kein Booten ohne ACPI. Ubuntu hingegen schon. acpi=offDas Problem ließ sich lösen, indem man die Grub-Boot-Einstellungen durch Hinzufügen von änderte.
Dies löste das Problem für die Windows-Partition jedoch nicht, da ACPI etwas ist, das Windows erwartet. Mein argentinischer Kollege (der wirklich großartig ist) schlug vor, eine frühere Version von matplotlib auszuprobieren. Also verwendete ich den Befehl, conda install matplotlib=2.2.3um auf Version 2.2.3 herunterzustufen.
Durch das Downgrade wurde das Problem unter Ubuntu und Windows sofort gelöst! Ich schlage daher vor, vorerst ein Downgrade durchzuführen, bis die Matplotlib-Entwickler dieses Problem gelöst haben. Außerdem bedeutet dies, dass Sie ACPI oder andere Optionen nicht deaktivieren müssen, die (nach Einschätzung dieses Laien) wahrscheinlich im Hintergrund nette Dinge tun und daher besser beibehalten werden sollten.
Tatsächlich funktionierte dies für das erste Beispiel in der Galerie von Matplotlib. Aber nachdem ich weitere Beispiele über Skripte und in Jupyter Notebook ausprobiert hatte, stürzte es mit 2.2.3 immer noch ab. Also habe ich wieder auf die neueste Matplotlib-Version aktualisiert und wieder hinzugefügt acpi=off, aber dies führte immer noch zu einem Einfrieren + Absturz beim Plotten eines Histogramms in Jupyter Notebook. Also habe ich wieder hinzugefügt intel_pstate=disableund die neueste Version von Matplotlib beibehalten, sodass dies über ein Jupyter Notebook ausgeführt werden konnte.
UPDATE: Ein Nachteil dabei ist, dass das System nicht richtig herunterfährt :/ Ubuntu bleibt mit diesen Einstellungen gegen Ende des Herunterfahrens hängen und ich muss die Maschine manuell ausschalten. Ich bin mir nicht sicher, ob das technisch gut für die Hardware ist.