☰

與 Python、Anaconda、Matplotlib、MKL 和 Jupyter 相關的奇怪崩潰行為的原因是什麼？

tag-icon • tag-icon ubuntu python crash matplotlib jupyter
與 Python、Anaconda、Matplotlib、MKL 和 Jupyter 相關的奇怪崩潰行為的原因是什麼？

我們對這個崩潰問題感到非常困惑，因為我們沒有得到任何關於實際錯誤的回溯或其他訊息，因此很難調試。不管怎樣，就這樣吧。

我們有一個工作站用於在 Python 中運行我們的分析工作。問題的要點是，當我們在筆記本上工作（或執行如下所示的測試腳本）時，系統就會崩潰。崩潰包括作業系統凍結然後重新啟動。沒有任何資訊告訴我們發生了什麼，只是機器死機並重新啟動。

當我們運行筆記本並要求筆記本進行過多的繪圖時，最常發生崩潰。我們不可能準確地定義“太多的陰謀”，但下面的例子是一個極端的例子來強行解決這個問題。該腳本有時會很快導致崩潰，有時會花費一些時間。但不可避免地，它會導致崩潰。

根據我們迄今為止的研究，以下是我們正在運行的一些內容，這些內容似乎是問題的一部分：

  • 烏班圖18.04
  • 帶有 MKL 的 Anaconda 5.2.0
  • numpy 1.16.2
  • Matplotlib 3.0.3
  • 朱皮特1.0.0

調查結果摘要如下：

  1. 基本 Anaconda 安裝使用帶有 MKL 的 Numpy，並將 Matplotlib 連結到 Anaconda 發行版中的依賴項。使用 Python 運行下面的測試腳本每次都會導致崩潰。 ETA：我們為 Matplotlib 嘗試了不同的後端，但沒有什麼差別。
  2. 如果我們從 Anaconda 發行版運行測試腳本，其中 Numpy 由 Conda 安裝，但是不是MKL 和 Matplotlib 是透過 pip 安裝的不是通過Conda，那麼腳本運行良好。如果我們使用 MKL或者使用 Conda 而不是 pip 安裝 Matplotlib，我們遇到了崩潰。我們也可以在非 Anaconda 發行版上正常運行腳本，所有內容都透過 pip 安裝（並且沒有其他 MKL 連結）。
  3. 如果我們建立腳本的 Jupyter 筆記本版本（每個單元一個圖）並運行所有單元，則筆記本將導致崩潰。因此，僅使用 Jupyter，我們在第 2 點中獲得的所有收益都會被抹去。
  4. 我們通常在 Docker 容器中並在 Nginx 反向代理後面運行 Jupyter。我們排除了這個原因，因為 Docker 映像也是 Ubuntu 18.04，並且我們直接在主機上執行測試以排除任何 Docker 問題。
  5. 當我們追蹤資源使用情況時，我們自然會發現使用 MKL，CPU 使用率會進入 300-400% 的範圍。我們有一個 12 核心 CPU，並且通常會達到更高的百分比值。在運行測試腳本時，我們幾乎只使用了 1GB 內存，而容量為 128GB，並且定期運行的數據分析使我們遠高於 1GB。

這大約涵蓋了我們已經能夠弄清楚的內容。由於崩潰與繪圖密切相關，因此很明顯，對 Matplotlib 的調整至少創建了部分修復。 MKL 問題除此之外增加了一個令人費解的混雜因素，但我們認為我們有一個解決方法。但是當我們回去在 Jupyter 中測試它時，結果發現即使我們運行了腳本，第 4 點仍然表明我們還沒有完全修復所有問題。

這讓我們看到了這篇文章。我在網路上看到的任何東西都與我們所觀察到的情況相差甚遠，而且我從未見過類似的東西。我完全沒有想法，也沒有想過這是否真的是一個硬體問題。

任何幫助解決這個問題的幫助將不勝感激。我正在考慮在我們的工作站上使用 Ubuntu 以外的 Linux 發行版來嘗試。

# 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
...

補充：我的同事今天早上發現了這篇文章。為硬體問題提供更有力的理由。https://forum.manjaro.org/t/python-matplotlib-script-crashes-system/44052/10

修訂更新：在 BIOS 中關閉超線程不起作用。但遵循 manjaro.org 上那篇文章的啟動建議做過只要它們沒有與關閉 BIOS 中的超線程一起完成，就會有幫助。

答案1

A解決方法apci=off是使用此論壇帖子中提到的 啟動設定：https://forum.manjaro.org/t/python-matplotlib-script-crashes-system/44052/10

這對我們來說是可以接受的，但如果有人有實際的解決方案或解釋或確實需要添加任何內容，我會洗耳恭聽。

答案2

我在全新的 Ubuntu 18.04.2 LTS 系統和最新的 Anaconda 全新安裝中遇到了完全相同的問題。有趣的是，我在 Windows 10 Pro（完全最新）上有完全相同的行為（凍結+系統崩潰）。

AFAIK，Windows 不允許在沒有 ACPI 的情況下啟動。然而，Ubuntu 確實如此，並且透過新增更改 grub 引導設定acpi=off解決了該問題。

但是，這並沒有解決 Windows 分割區的問題，因為 ACPI 是 Windows 所期望的。我的阿根廷同事（他真的很棒）建議嘗試使用早期版本的 matplotlib。於是，我使用指令conda install matplotlib=2.2.3降級到2.2.3版本。

降級立即解決了 Ubuntu 和 Windows 上的問題！因此，我建議暫時降級，直到 matplotlib 開發人員解決這個問題。這也意味著您不必停用 ACPI 或任何其他選項（根據這位新手的估計）可能會在後台做一些好事，因此最好繼續使用。

實際上，這適用於 matplotlib 庫中的第一個範例。但在透過腳本和 jupyter Notebook 嘗試更多範例後，它仍然在 2.2.3 中崩潰。因此，我升級回最新的 matplotlib 並添加回來acpi=off，但這仍然導致在 jupyter 筆記本中繪製直方圖時凍結+崩潰。因此，我添加intel_pstate=disable並保持最新版本的 matplotlib 可以透過 jupyter 筆記本運行。

更新：這樣做的一個缺點是系統無法正確關閉電源：/ Ubuntu 將在使用這些設定關閉電源的最後一刻掛起，我必須手動關閉機器。不確定它在技術上是否適合硬體。

相關內容