우리는 실제로 무엇이 잘못되었는지에 대한 추적이나 기타 메시지를 얻지 못하여 이 충돌 문제에 대해 매우 당황스러워서 디버깅하기가 어려웠습니다. 어쨌든, 여기 간다.
Python에서 분석 작업을 실행하기 위한 워크스테이션이 있습니다. 문제의 요점은 노트북에서 작업할 때(또는 아래 표시된 테스트 스크립트를 실행할 때) 시스템이 충돌한다는 것입니다. 충돌은 OS 정지 후 다시 시작으로 구성됩니다. 무슨 일이 일어났는지 알려주는 것은 없고 단지 기계가 멈췄다가 다시 시작된다는 것뿐입니다.
충돌은 노트북을 실행하고 노트북에 너무 많은 플롯을 수행하도록 요청할 때 가장 자주 발생합니다. "너무 많은 플롯"을 정확하게 정의하는 것은 불가능하지만 아래 예는 문제를 강제하는 극단적인 경우입니다. 스크립트는 때때로 충돌을 빠르게 일으키고 때로는 약간의 시간이 걸립니다. 그러나 필연적으로 충돌이 발생합니다.
지금까지의 연구에 따르면 문제의 일부인 것으로 보이는 몇 가지 사항은 다음과 같습니다.
- 우분투 18.04
- MKL이 포함된 Anaconda 5.2.0
- 넘파이 1.16.2
- 맷플롯립 3.0.3
- 주피터 1.0.0
조사 결과를 요약하면 다음과 같습니다.
- 기본 Anaconda 설치는 MKL과 함께 Numpy를 사용하며 Matplotlib가 Anaconda 배포판 내 종속성에 연결되어 있습니다. Python으로 아래 테스트 스크립트를 실행하면 매번 충돌이 발생합니다. ETA: Matplotlib에 대해 다양한 백엔드를 시도했지만 아무런 차이가 없었습니다.
- Numpy가 Conda에 의해 설치된 Anaconda 배포판에서 테스트 스크립트를 실행하지만~ 아니다MKL 및 Matplotlib은 pip를 통해 설치되었으며~ 아니다Conda를 통해 스크립트가 정상적으로 실행됩니다. MKL 중 하나를 사용하는 경우또는Matplotlib을 설치하기 위해 pip 대신 Conda를 사용하면 충돌이 발생합니다. 또한 모든 것이 pip를 통해 설치된(다른 MKL 연결 없음) 비 Anaconda 배포판에서도 제대로 스크립트를 실행할 수 있습니다.
- Jupyter 노트북 버전의 스크립트(셀당 하나의 플롯)를 생성하고 모든 셀을 실행하면 노트북에서 충돌이 발생합니다. 따라서 Jupyter를 사용하는 것만으로도 포인트 2의 모든 이점이 사라집니다.
- 우리는 일반적으로 Docker 컨테이너와 Nginx 역방향 프록시 뒤에서 Jupyter를 실행합니다. Docker 이미지도 Ubuntu 18.04이고 Docker 문제를 배제하기 위해 호스트 시스템에서 직접 테스트를 실행했기 때문에 이를 원인으로 배제했습니다.
- 리소스 사용량을 추적하면 MKL을 사용하면 CPU 사용량이 300~400% 범위에 들어가는 것을 자연스럽게 알 수 있습니다. 우리는 12개의 코어 CPU를 가지고 있으며 정기적으로 더 높은 % 값을 달성했습니다. 우리는 128GB 용량을 가지고 테스트 스크립트를 실행할 때 1GB의 메모리를 거의 사용하지 않고 일상적으로 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
ㅏ해결 방법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
문제를 해결했습니다.
그러나 ACPI는 Windows에서 기대하는 기능이므로 Windows 파티션 문제는 해결되지 않았습니다. 정말 멋진 아르헨티나 동료가 matplotlib의 이전 버전을 사용해 볼 것을 제안했습니다. 그래서 conda install matplotlib=2.2.3
2.2.3 버전으로 다운그레이드하는 명령어를 사용했습니다.
다운그레이드하면 Ubuntu 및 Windows의 문제가 즉시 해결되었습니다! 따라서 matplotlib 개발자가 이 문제를 해결할 때까지 지금은 다운그레이드하는 것이 좋습니다. 이는 또한 ACPI 또는 (이 초보자의 평가에 따르면) 백그라운드에서 좋은 작업을 수행하고 있으므로 계속 유지하는 것이 더 나은 다른 옵션을 비활성화할 필요가 없음을 의미합니다.
실제로 이것은 matplotlib 갤러리의 첫 번째 예에서 작동했습니다. 그러나 스크립트와 jupyter 노트북을 통해 추가 예제를 시도한 후에도 여전히 2.2.3과 충돌합니다. 그래서 최신 matplotlib로 다시 업그레이드하고 다시 추가했지만 acpi=off
jupyter 노트북에 히스토그램을 그리는 동안 여전히 정지 + 충돌이 발생했습니다. 그래서 저는 intel_pstate=disable
matplotlib의 최신 버전을 추가하고 유지하여 jupyter 노트북을 통해 실행할 수 있었습니다.
업데이트: 이것의 한 가지 단점은 시스템의 전원이 제대로 꺼지지 않는다는 것입니다./ Ubuntu는 이러한 설정으로 인해 전원이 꺼질 때까지 작동하지 않으며 수동으로 시스템 전원을 꺼야 합니다. 하드웨어에 대해 기술적으로 훌륭한지 확실하지 않습니다.