☰

В чем причина этого странного сбоя, связанного с Python, Anaconda, Matplotlib, MKL и Jupyter?

tag-icon • tag-icon ubuntu python crash matplotlib jupyter
В чем причина этого странного сбоя, связанного с Python, Anaconda, Matplotlib, MKL и Jupyter?

Мы в полном замешательстве по поводу этой проблемы со сбоем, так как не получаем никаких трассировок или других сообщений о том, что на самом деле не так, поэтому было сложно отладить. В любом случае, вот.

У нас есть рабочая станция для выполнения нашей аналитической работы на Python. Суть проблемы в том, что когда мы работаем на ноутбуках (или запускаем тестовый скрипт, показанный ниже), система падает. Сбой состоит из зависания ОС и последующего перезапуска. Нет ничего, что говорило бы нам о том, что произошло, просто машина зависла и перезапустилась.

Чаще всего сбои происходят, когда мы запускаем блокнот и просим его сделать слишком много чертежей. Мы не можем точно определить "слишком много чертежей", но пример ниже — это крайний случай, чтобы навязать проблему. Иногда скрипт быстро вызывает сбой, а иногда занимает некоторое время. Но неизбежно он вызовет сбой.

Вот некоторые из вещей, которые, по нашим данным, являются частью проблемы:

  • Убунту 18.04
  • Анаконда 5.2.0 с МКЛ
  • Numpy 1.16.2
  • Matplotlib 3.0.3
  • Юпитер 1.0.0

Резюме результатов таково:

  1. Базовая установка Anaconda использует Numpy с MKL и имеет Matplotlib, связанный с его зависимостями в дистрибутиве Anaconda. Запуск тестового скрипта ниже с Python каждый раз приводит к сбою. ETA: Мы пробовали разные бэкенды для Matplotlib, но это не имело значения.
  2. Если мы запустим тестовый скрипт из дистрибутива Anaconda, где Numpy был установлен Conda, нонетс MKL и Matplotlib был установлен через pip инетчерез Conda, то скрипт работает нормально. Если мы используем MKLилиConda вместо pip для установки Matplotlib, мы получаем сбой. Мы также можем нормально запустить скрипт с дистрибутивом, отличным от Anaconda, со всем установленным через pip (и без других ссылок MKL).
  3. Если мы создадим версию скрипта в блокноте Jupyter (один график на ячейку) и запустим все ячейки, блокнот вызовет сбой. Таким образом, все наши достижения в пункте 2 будут уничтожены только за счет использования Jupyter.
  4. Обычно мы запускаем Jupyter в контейнере Docker и за обратным прокси-сервером Nginx. Мы исключили это как причину, поскольку образы Docker также являются Ubuntu 18.04, и мы запускали тесты непосредственно на хост-машине, чтобы исключить любые проблемы Docker.
  5. Когда мы отслеживаем использование ресурсов, мы, естественно, обнаруживаем, что с MKL использование ЦП достигает диапазона 300-400%. У нас 12-ядерный ЦП, и мы регулярно достигаем более высоких значений в процентах. Мы едва используем гигабайт памяти при запуске тестового скрипта, имея емкость 128 ГБ и регулярно запуская анализы данных, которые выталкивают нас намного выше 1 ГБ.

Это все, что мы смогли выяснить. Поскольку сбои были так сильно связаны с построением графиков, казалось довольно очевидным, что настройки Matplotlib создали по крайней мере частичное исправление. Проблема MKL добавила загадочный конфаундер вдобавок ко всему, но мы думали, что у нас есть обходной путь. Но затем, когда мы вернулись, чтобы протестировать его в Jupyter, оказалось, что даже несмотря на то, что мы запустили скрипт, пункт 4 все еще показывает, что мы не полностью все исправили.

И это приводит нас к этому посту. Ничто из того, что я видел в сети, даже отдаленно не соответствует тому, что мы наблюдаем, и я никогда не видел ничего подобного. У меня полностью закончились идеи, и я не собираюсь задаваться вопросом, действительно ли это проблема с оборудованием.

Любая помощь в раскалывании этого ореха будет высоко оценена. Я думаю попробовать это на нашей рабочей станции с дистрибутивом Linux, отличным от Ubuntu.

# 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

Аобходной путьиспользовать настройки загрузки 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 notebook. Поэтому я добавил intel_pstate=disableи сохранил последнюю версию matplotlib, и это смогло запуститься через jupyter notebook.

ОБНОВЛЕНИЕ: Один из недостатков этого способа заключается в том, что система не выключается должным образом :/ Ubuntu зависнет к самому концу выключения с этими настройками, и мне придется вручную выключать машину. Не уверен, что это технически хорошо для оборудования.

Связанный контент