Pytorch: 데이터 로더에서 가능한 교착 상태

로더가 중지되면 얼마나 많은 여유 메모리가 있습니까?

@apaszke top 를 확인하면 나머지 메모리(캐시된 메모리도 사용된 것으로 계산됨)는 일반적으로 2GB입니다. 그러나 캐시된 것을 사용한 것으로 계산하지 않으면 항상 30GB 이상입니다.

또한 유효성 검사 시작 시 항상 중지되지만 다른 곳에서는 중지되지 않는 이유를 이해할 수 없습니다.

아마도 유효성 검사를 위해 공유 메모리 사용을 제한을 초과하는 별도의 로더가 사용되기 때문일 수 있습니다.

@ngimel

방금 프로그램을 다시 실행했습니다. 그리고 막혔습니다.

top 출력:

~~~
상단 - 17:51:18 최대 2일, 21:05, 2명의 사용자, 로드 평균: 0.49, 3.00, 5.41
작업: 총 357개, 실행 2개, 잠자기 355개, 중지 0개, 좀비 0개
%Cpu(s): 1.9 us, 0.1 sy, 0.7 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 총 65863816개, 60115084개 사용됨, 5748732개 사용 가능, 1372688개 버퍼
KiB 스왑: 총 5917692, 620 사용, 5917072 무료. 51154784 캐시된 메모리

PID 사용자 PR NI VIRT RES SHR S %CPU %MEM TIME+ 명령 3067 aalreja 20 0 143332 101816 21300 R 46.1 0.2 1631:44 Xvnc
16613 알레자 30 10 32836 4880 3912 S 16.9 0.0 1:06.92 fiberlamp 3221 알레자 20 0 8882348 1.017g 110120 S 1.579 1.6 MATLAB
1285 루트 20 0 1404848 48252 25580 S 0.3 0.1 6:00.12 dockerd 16597 ymengz+ 20 0 25084 3252 2572 R 0.3 0.5 6 0:0
1 루트 20 0 33616 4008 2624 S 0.0 0.0 0:01.43 초기화
~~~

free 출력

~yimengzh_everyday@yimengzh :~$ 무료사용된 총 사용 가능한 공유 버퍼 캐시메모: 65863816 60122060 5741756 9954628 1372688 51154916-/+ 버퍼/캐시: 7594456 58269360스왑: 5917692 620 5917072~

nvidia-smi 출력

~~~
yimengzh_everyday@yimengzh :~$ nvidia-smi
2017년 4월 25일 화 17:52:38
+---------------------------------------------------------------- --------------------------+
| NVIDIA-SMI 375.39 드라이버 버전: 375.39 |
|------------------------------+-------------------- --+----------------------+
| GPU 이름 지속성-M| 버스 ID Disp.A | 휘발성 부정확. ECC |
| 팬 온도 성능 Pwr: 사용량/캡 | 메모리 사용량 | GPU 활용 컴퓨팅 M. |
|====================================================== =====+========================|
| 0 GeForce GTX TIT... 끄기 | 0000:03:00.0 끄기 | 해당 없음 |
| 30% 42C P8 14W / 250W | 3986MiB / 6082MiB | 0% 기본값 |
+-------------------------------+-------------------- --+----------------------+
| 1 Tesla K40c 끄기 | 0000:81:00.0 끄기 | 끄기 |
| 0% 46C P0 57W / 235W | 0MiB / 12205MiB | 0% 기본값 |
+-------------------------------+-------------------- --+----------------------+

+---------------------------------------------------------------- --------------------------+
| 프로세스: GPU 메모리 |
| GPU PID 유형 프로세스 이름 사용법 |
|==================================================== ==============================|
| 0 16509 C 파이썬 3970MiB |
+---------------------------------------------------------------- --------------------------+
~~~

메모리 문제는 아닌 것 같아요.

공유 메모리에는 별도의 제한이 있습니다. ipcs -lm 또는 cat /proc/sys/kernel/shmall 및 cat /proc/sys/kernel/shmmax 를) 시도할 수 있습니까? 또한 더 적은 수의 작업자를 사용하면 교착 상태가 발생합니까(예: 작업자 1명의 극단적인 경우로 테스트)?

@apaszke

~~~
yimengzh_everyday@yimengzh :~$ ipcs -lm

------ 공유 메모리 제한 --------
최대 세그먼트 수 = 4096
최대 세그먼트 크기(KB) = 18014398509465599
최대 총 공유 메모리(KB) = 18446744073642442748
최소 세그먼트 크기(바이트) = 1

yimengzh_everyday@yimengzh :~$ 고양이 /proc/sys/kernel/shmall
18446744073692774399
yimengzh_everyday@yimengzh :~$ 고양이 /proc/sys/kernel/shmmax
18446744073692774399
~~~

그들은 당신을 어떻게 찾나요?

더 적은 수의 노동자에 관해서는, 나는 그것이 자주 일어나지 않을 것이라고 믿습니다. (지금 시도할 수 있습니다). 하지만 실제로는 그렇게 많은 일꾼이 필요하다고 생각합니다.

최대 4096개의 공유 메모리 세그먼트가 허용됩니다. 문제일 수 있습니다. /proc/sys/kernel/shmmni (8192를 시도할 수 있음)에 작성하여 값을 늘릴 수 있습니다. 수퍼유저 권한이 필요할 수 있습니다.

@apaszke 글쎄 이것들은 Ubuntu와 CentOS 6의 기본값입니다... 그게 정말 문제입니까?

@apaszke 훈련 프로그램을 실행할 때 ipcs -a 실제로 사용 중인 공유 메모리가 표시되지 않습니다. 예상인가요?

@apaszke 는

~~~
yimengzh_everyday@yimengzh :~$ ipcs -lm

------ 공유 메모리 제한 --------
최대 세그먼트 수 = 8192
최대 세그먼트 크기(KB) = 18014398509465599
최대 총 공유 메모리(KB) = 18446744073642442748
최소 세그먼트 크기(바이트) = 1
~~~

한 명의 작업자를 시도하지 않았습니다. 첫째, 느릴 것입니다. 둘째, 문제가 실제로 데드 락킹이라면 확실히 사라질 것입니다.

@zym1010 기본 설정은 이러한 작업 부하를 염두에 두고 만들 필요가 없으므로 문제가 될 수 있습니다. ipcs 는 우리가 사용하지 않는 System V 공유 메모리용이지만 POSIX 공유 메모리에도 동일한 제한이 적용되지 않도록 하고 싶었습니다.

문제가 실제로 존재하는 경우 작업자와 기본 프로세스 사이의 교착 상태일 가능성이 있으며 작업자 한 명이 이를 트리거하기에 충분할 수 있기 때문에 확실히 사라지지는 않을 torch.__version__ 의 값은 얼마입니까? 도커에서 실행 중이신가요?

@apaszke 감사합니다. 나는 이제 당신의 분석을 훨씬 더 잘 이해합니다.

64GB RAM, 듀얼 Xeon 및 Titan Black(K40도 있지만 사용하지 않음)이 있는 Ubuntu 14.04 시스템에서 수행되는 방법까지 표시되는 다른 모든 결과입니다.

문제를 생성하는 명령은 CUDA_VISIBLE_DEVICES=0 PYTHONUNBUFFERED=1 python main.py -a alexnet --print-freq 20 --lr 0.01 --workers 22 --batch-size 256 /mnt/temp_drive_3/cv_datasets/ILSVRC2015/Data/CLS-LOC 입니다. 코드를 전혀 수정하지 않았습니다.

Python 3.5에서 pip를 통해 pytorch를 설치했습니다. pytorch 버전은 0.1.11_5 입니다. Docker에서 실행되지 않습니다.

BTW, 나는 또한 1 명의 작업자를 사용해 보았습니다. 하지만 다른 머신(128GB RAM, 듀얼 Xeon, 4 Pascal Titan X, CentOS 6)에서 수행했습니다. CUDA_VISIBLE_DEVICES=0 PYTHONUNBUFFERED=1 python main.py -a alexnet --print-freq 1 --lr 0.01 --workers 1 --batch-size 256 /ssd/cv_datasets/ILSVRC2015/Data/CLS-LOC 사용하여 실행했는데 오류 로그는 다음과 같습니다.

Epoch: [0][5003/5005]   Time 2.463 (2.955)      Data 2.414 (2.903)      Loss 5.9677 (6.6311)    Prec<strong i="14">@1</strong> 3.516 (0.545)    Prec<strong i="15">@5</strong> 8.594 (2.262)
Epoch: [0][5004/5005]   Time 1.977 (2.955)      Data 1.303 (2.903)      Loss 5.9529 (6.6310)    Prec<strong i="16">@1</strong> 1.399 (0.545)    Prec<strong i="17">@5</strong> 7.692 (2.262)
^CTraceback (most recent call last):
  File "main.py", line 292, in <module>
    main()
  File "main.py", line 137, in main
    prec1 = validate(val_loader, model, criterion)
  File "main.py", line 210, in validate
    for i, (input, target) in enumerate(val_loader):
  File "/home/yimengzh/miniconda2/envs/pytorch/lib/python3.5/site-packages/torch/utils/data/dataloader.py", line 168, in __next__
    idx, batch = self.data_queue.get()
  File "/home/yimengzh/miniconda2/envs/pytorch/lib/python3.5/queue.py", line 164, in get
    self.not_empty.wait()
  File "/home/yimengzh/miniconda2/envs/pytorch/lib/python3.5/threading.py", line 293, in wait
    waiter.acquire()

top 는 작업자 1명과 붙어있을 때 다음을 보여줍니다.

~상단 - 08:34:33 최대 15일, 20:03, 0명의 사용자, 로드 평균: 0.37, 0.39, 0.36작업: 총 894개, 실행 1개, 잠자기 892개, 중지 0개, 좀비 1개CPU: 7.2%us, 2.8%sy, 0.0%ni, 89.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st메모리: 총 132196824k, 131461528k 사용, 735296k 여유, 347448k 버퍼스왑: 총 2047996k, 사용 22656k, 여유 공간 2025340k, 캐시된 125226796k~

내가 찾은 또 다른 사실은 훈련 코드를 수정하여 모든 배치를 거치지 않도록 하는 것입니다. 예를 들어 50개의 배치만 훈련시킵니다.

if i >= 50:
    break

그러면 교착 상태가 사라지는 것 같습니다.

추가 테스트에 따르면 컴퓨터를 재부팅한 직후에 프로그램을 실행하면 이러한 정지가 훨씬 더 자주 발생합니다. 컴퓨터에 약간의 캐시가 있는 후에는 이 멈춤 현상이 덜 발생하는 것 같습니다.

시도했지만 이 버그를 어떤 식으로든 재현할 수 없습니다.

비슷한 문제가 발생했습니다. 한 에포크를 마치면 데이터 로더가 중지되고 새 에포크가 시작됩니다.

num_workers = 0으로 설정하면 작동합니다. 그러나 프로그램이 느려집니다.

@apaszke 먼저 컴퓨터를 재부팅한 다음 프로그램을 실행해

한 가지 지적하고 싶은 것은 OpenBLAS 연결 numpy가 설치되어 있고 @soumith 의 anaconda 클라우드의 MKL이 제대로 작동하지 않기 때문에 pip 사용하여 pytorch를 설치 했다는 것입니다.

따라서 본질적으로 pytorch는 MKL을 사용하고 numpy는 OpenBLAS를 사용합니다. 이것은 이상적이지 않을 수 있지만 이것이 여기서 문제와 관련이 없어야 한다고 생각합니다.

나는 그것을 조사했지만 결코 그것을 재현 할 수 없었습니다. MKL/OpenBLAS는 이 문제와 관련이 없어야 합니다. 시스템 구성에 문제가 있는 것 같습니다.

@apaszke 감사합니다. 방금 aaconda 공식 repo와 MKL 기반 pytorch에서 python을 시도했습니다. 여전히 같은 문제입니다.

Docker에서 코드를 실행해 보았습니다. 여전히 붙어 있습니다.

4개 중 1개의 GPU를 사용하여 nvidia-docker 내부에서 pytorch/examples imagenet 교육 예제(resnet18, 4개의 작업자)를 실행하는 것과 동일한 문제가 있습니다. 프로세스에 도달할 수 있다면 gdb 역추적을 수집하려고 노력할 것입니다. .

최소한 OpenBLAS는 행렬 곱셈에서 교착 상태 문제가 있는 것으로 알려져 있으며, 이는 비교적 드물게 발생합니다( https://github.com/xiani/OpenBLAS/issues/937). 이 버그는 적어도 numpy 1.12.0에 패키징된 OpenBLAS에 존재했습니다.

@jsainio 또한 순수 MKL 기반 PyTorch(numpy는 MKL과 연결됨)를 시도했지만 동일한 문제가 발생했습니다.

또한 이 문제는 데이터 로더에 대해 pin_memory 를 켜면 (적어도 저에게는) 해결됩니다.

2명의 작업자가 사망한 것 같습니다.

정상 작동 중:

root<strong i="7">@b06f896d5c1d</strong>:~/mnt# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user+        1 33.2  4.7 91492324 3098288 ?    Ssl  10:51   1:10 python -m runne
user+       58 76.8  2.3 91079060 1547512 ?    Rl   10:54   1:03 python -m runne
user+       59 76.0  2.2 91006896 1484536 ?    Rl   10:54   1:02 python -m runne
user+       60 76.4  2.3 91099448 1559992 ?    Rl   10:54   1:02 python -m runne
user+       61 79.4  2.2 91008344 1465292 ?    Rl   10:54   1:05 python -m runne

잠금 후:

root<strong i="11">@b06f896d5c1d</strong>:~/mnt# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user+        1 24.8  4.4 91509728 2919744 ?    Ssl  14:25  13:01 python -m runne
user+       58 51.7  0.0      0     0 ?        Z    14:27  26:20 [python] <defun
user+       59 52.1  0.0      0     0 ?        Z    14:27  26:34 [python] <defun
user+       60 52.0  2.4 91147008 1604628 ?    Sl   14:27  26:31 python -m runne
user+       61 52.0  2.3 91128424 1532088 ?    Sl   14:27  26:29 python -m runne

아직 남아 있는 작업자 중 하나의 경우 gdb 스택 추적의 시작은 다음과 같습니다.

root<strong i="15">@b06f896d5c1d</strong>:~/mnt# gdb --pid 60
GNU gdb (GDB) 8.0
Attaching to process 60
[New LWP 65]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f36f52af827 in do_futex_wait.constprop ()
   from /lib/x86_64-linux-gnu/libpthread.so.0

(gdb) bt
#0  0x00007f36f52af827 in do_futex_wait.constprop ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f36f52af8d4 in __new_sem_wait_slow.constprop.0 ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f36f52af97a in sem_wait@@GLIBC_2.2.5 ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#3  0x00007f36f157efb1 in semlock_acquire (self=0x7f3656296458,
    args=<optimized out>, kwds=<optimized out>)
    at /home/ilan/minonda/conda-bld/work/Python-3.5.2/Modules/_multiprocessing/semaphore.c:307
#4  0x00007f36f5579621 in PyCFunction_Call (func=
    <built-in method __enter__ of _multiprocessing.SemLock object at remote 0x7f3656296458>, args=(), kwds=<optimized out>) at Objects/methodobject.c:98
#5  0x00007f36f5600bd5 in call_function (oparg=<optimized out>,
    pp_stack=0x7f36c7ffbdb8) at Python/ceval.c:4705
#6  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>)
    at Python/ceval.c:3236
#7  0x00007f36f5601b49 in _PyEval_EvalCodeWithName (_co=<optimized out>,
    globals=<optimized out>, locals=<optimized out>, args=<optimized out>,
    argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0,
    closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4018
#8  0x00007f36f5601cd8 in PyEval_EvalCodeEx (_co=<optimized out>,
    globals=<optimized out>, locals=<optimized out>, args=<optimized out>,
    argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0,
    defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4039
#9  0x00007f36f5557542 in function_call (
    func=<function at remote 0x7f36561c7d08>,
    arg=(<Lock(release=<built-in method release of _multiprocessing.SemLock object at remote 0x7f3656296458>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x7f3656296458>, _semlock=<_multiprocessing.SemLock at remote 0x7f3656296458>) at remote 0x7f3656296438>,), kw=0x0)
    at Objects/funcobject.c:627
#10 0x00007f36f5524236 in PyObject_Call (
    func=<function at remote 0x7f36561c7d08>, arg=<optimized out>,
    kw=<optimized out>) at Objects/abstract.c:2165
#11 0x00007f36f554077c in method_call (
    func=<function at remote 0x7f36561c7d08>,
    arg=(<Lock(release=<built-in method release of _multiprocessing.SemLock object at remote 0x7f3656296458>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x7f3656296458>, _semlock=<_multiprocessing.SemLock at remote 0x7f3656296458>) at remote 0x7f3656296438>,), kw=0x0)
    at Objects/classobject.c:330
#12 0x00007f36f5524236 in PyObject_Call (
    func=<method at remote 0x7f36556f9248>, arg=<optimized out>,
    kw=<optimized out>) at Objects/abstract.c:2165
#13 0x00007f36f55277d9 in PyObject_CallFunctionObjArgs (
    callable=<method at remote 0x7f36556f9248>) at Objects/abstract.c:2445
#14 0x00007f36f55fc3a9 in PyEval_EvalFrameEx (f=<optimized out>,
    throwflag=<optimized out>) at Python/ceval.c:3107
#15 0x00007f36f5601166 in fast_function (nk=<optimized out>, na=1,
    n=<optimized out>, pp_stack=0x7f36c7ffc418,
    func=<function at remote 0x7f36561c78c8>) at Python/ceval.c:4803
#16 call_function (oparg=<optimized out>, pp_stack=0x7f36c7ffc418)
    at Python/ceval.c:4730
#17 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>)
    at Python/ceval.c:3236
#18 0x00007f36f5601b49 in _PyEval_EvalCodeWithName (_co=<optimized out>,
    globals=<optimized out>, locals=<optimized out>, args=<optimized out>,
    argcount=4, kws=0x7f36f5b85060, kwcount=0, defs=0x0, defcount=0,
    kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4018
#19 0x00007f36f5601cd8 in PyEval_EvalCodeEx (_co=<optimized out>,
    globals=<optimized out>, locals=<optimized out>, args=<optimized out>,
    argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0,
    defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:4039
#20 0x00007f36f5557661 in function_call (
    func=<function at remote 0x7f36e14170d0>,
    arg=(<ImageFolder(class_to_idx={'n04153751': 783, 'n02051845': 144, 'n03461385': 582, 'n04350905': 834, 'n02105056': 224, 'n02112137': 260, 'n03938244': 721, 'n01739381': 59, 'n01797886': 82, 'n04286575': 818, 'n02113978': 268, 'n03998194': 741, 'n15075141': 999, 'n03594945': 609, 'n04099969': 765, 'n02002724': 128, 'n03131574': 520, 'n07697537': 934, 'n04380533': 846, 'n02114712': 271, 'n01631663': 27, 'n04259630': 808, 'n04326547': 825, 'n02480855': 366, 'n02099429': 206, 'n03590841': 607, 'n02497673': 383, 'n09332890': 975, 'n02643566': 396, 'n03658185': 623, 'n04090263': 764, 'n03404251': 568, 'n03627232': 616, 'n01534433': 13, 'n04476259': 868, 'n03495258': 594, 'n04579145': 901, 'n04266014': 812, 'n01665541': 34, 'n09472597': 980, 'n02095570': 189, 'n02089867': 166, 'n02009229': 131, 'n02094433': 187, 'n04154565': 784, 'n02107312': 237, 'n04372370': 844, 'n02489166': 376, 'n03482405': 588, 'n04040759': 753, 'n01774750': 76, 'n01614925': 22, 'n01855032': 98, 'n03903868': 708, 'n02422699': 352, 'n01560419': 1...(truncated), kw={}) at Objects/funcobject.c:627
#21 0x00007f36f5524236 in PyObject_Call (
    func=<function at remote 0x7f36e14170d0>, arg=<optimized out>,
    kw=<optimized out>) at Objects/abstract.c:2165
#22 0x00007f36f55fe234 in ext_do_call (nk=1444355432, na=0,
    flags=<optimized out>, pp_stack=0x7f36c7ffc768,
    func=<function at remote 0x7f36e14170d0>) at Python/ceval.c:5034
#23 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>)
    at Python/ceval.c:3275
--snip--

메인 프로세스가 멈춘 상태에서 비슷한 오류 로그가 있었습니다. self.data_queue.get()
나에게 문제는 opencv를 이미지 로더로 사용했다는 것입니다. 그리고 cv2.imread 함수는 imagenet의 특정 이미지에서 오류 없이 무기한 중단되었습니다("n01630670/n01630670_1010.jpeg").

num_workers = 0으로 작동한다고 말하면 그게 아닙니다. 그러나 유사한 오류 추적을 가진 일부 사람들에게 도움이 될 수 있다고 생각했습니다.

현재 num_workers = 0 로 테스트를 실행 중이며 아직 중단되지 않았습니다. https://github.com/pytorch/examples/blob/master/imagenet/main.py 에서 예제 코드를 실행하고 pytorch/vision ImageFolder는 내부적으로 PIL 또는 pytorch/accimage 를 사용하여 이미지를 로드하는 것으로 보이므로 OpenCV가 관련되지 않습니다.

num_workers = 4 를 사용하면 때때로 첫 번째 epoch 기차를 얻고 완전히 검증할 수 있으며 두 번째 epoch 중간에 잠깁니다. 따라서 데이터셋/로딩 기능에 문제가 있을 가능성은 낮습니다.

특정 하드웨어/소프트웨어 조합에 의해 비교적 드물게 트리거될 수 있는 ImageLoader의 경쟁 조건처럼 보입니다.

@zym1010 포인터 주셔서 감사합니다. DataLoader에도 pin_memory = False 설정해 보겠습니다.

흥미로운. 내 설정에서 pin_memory = False 및 num_workers = 4 imagenet 예제는 거의 즉시 중단되고 작업자 중 3명은 좀비 프로세스로 끝납니다.

root<strong i="8">@034c4212d022</strong>:~/mnt# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user+        1  6.7  2.8 92167056 1876612 ?    Ssl  13:50   0:36 python -m runner
user+       38  1.9  0.0      0     0 ?        Z    13:51   0:08 [python] <defunct>
user+       39  4.3  2.3 91069804 1550736 ?    Sl   13:51   0:19 python -m runner
user+       40  2.0  0.0      0     0 ?        Z    13:51   0:09 [python] <defunct>
user+       41  4.1  0.0      0     0 ?        Z    13:51   0:18 [python] <defunct>

내 설정에서 데이터 세트는 NFS를 통해 읽는 네트워크 디스크에 있습니다. pin_memory = False 및 num_workers = 4 하면 시스템이 상당히 빨리 실패할 수 있습니다.

=> creating model 'resnet18'
- training epoch 0
Epoch: [0][0/5005]  Time 10.713 (10.713)    Data 4.619 (4.619)  Loss 6.9555 (6.9555)    Prec<strong i="8">@1</strong> 0.000 (0.000)    Prec<strong i="9">@5</strong> 0.000 (0.000)
Traceback (most recent call last):
--snip--
imagenet_pytorch.main.main([data_dir, "--transient_dir", context.transient_dir])
  File "/home/user/mnt/imagenet_pytorch/main.py", line 140, in main

train(train_loader, model, criterion, optimizer, epoch, args)
  File "/home/user/mnt/imagenet_pytorch/main.py", line 168, in train

for i, (input, target) in enumerate(train_loader):
  File "/home/user/anaconda/lib/python3.5/site-packages/torch/utils/data/dataloader.py", line 206, in __next__

idx, batch = self.data_queue.get()
  File "/home/user/anaconda/lib/python3.5/multiprocessing/queues.py", line 345, in get

return ForkingPickler.loads(res)
  File "/home/user/anaconda/lib/python3.5/site-packages/torch/multiprocessing/reductions.py", line 70, in rebuild_storage_fd

fd = df.detach()
  File "/home/user/anaconda/lib/python3.5/multiprocessing/resource_sharer.py", line 57, in detach

with _resource_sharer.get_connection(self._id) as conn:
  File "/home/user/anaconda/lib/python3.5/multiprocessing/resource_sharer.py", line 87, in get_connection

c = Client(address, authkey=process.current_process().authkey)
  File "/home/user/anaconda/lib/python3.5/multiprocessing/connection.py", line 493, in Client

answer_challenge(c, authkey)
  File "/home/user/anaconda/lib/python3.5/multiprocessing/connection.py", line 732, in answer_challenge

message = connection.recv_bytes(256)         # reject large message
  File "/home/user/anaconda/lib/python3.5/multiprocessing/connection.py", line 216, in recv_bytes

buf = self._recv_bytes(maxlength)
  File "/home/user/anaconda/lib/python3.5/multiprocessing/connection.py", line 407, in _recv_bytes

buf = self._recv(4)
  File "/home/user/anaconda/lib/python3.5/multiprocessing/connection.py", line 379, in _recv

chunk = read(handle, remaining)
ConnectionResetError
: 
[Errno 104] Connection reset by peer

@zym1010 네트워크 디스크나 기존 회전 디스크 중 지연 시간 등이 더 느릴 수 있습니까?

@jsainio

클러스터의 컴퓨팅 노드에서 로컬 SSD를 사용하고 있습니다. 코드는 NFS 드라이브에 있지만 데이터는 최대 로딩 속도를 위해 로컬 SSD에 있습니다. NFS 드라이브에 데이터 로드를 시도한 적이 없습니다.

@zym1010 정보 감사합니다. 클러스터의 컴퓨팅 노드에서도 이것을 실행하고 있습니다.

실제로 num_workers = 4 변형을 시도하면서 동시에 동일한 노드에서 num_workers = 0 실험을 실행하고 있습니다. 첫 번째 실험은 가능한 경쟁 조건이 후자에서 더 빨리 나타나도록 충분한 부하를 생성하고 있을 수 있습니다.

@apaszke 이전에 이것을 재현하려고 할 때 두 개의 인스턴스를 나란히 실행하거나 시스템에 상당한 다른 부하를

@jsainio 조사해 주셔서 감사합니다! 이상하게도 작업자는 함께 종료되어야 하며 기본 프로세스가 데이터 읽기를 완료한 후에만 종료해야 합니다. 왜 조기 종료되는지 조사해 볼 수 있습니까? 커널 로그( dmesg )를 확인하시겠습니까?

아뇨 안써봤는데 안그럴때도 나오는거같은데 IIRC

@apaszke 알겠습니다 . 작업자가 기쁩니다 .

시도했지만 종료 이유를 확인하는 좋은 방법을 모르겠습니다. dmesg 에는 관련 항목이 표시되지 않습니다. (저는 Anaconda 패키지를 사용하여 Ubuntu 16.04 파생 Docker에서 실행 중입니다.)

한 가지 방법은 작업자 루프 내부에 여러 인쇄를 추가하는 것입니다. 나는 그들이 왜 조용히 퇴장하는지 모르겠다. stderr에 인쇄되었을 것이기 때문에 예외는 아닐 것입니다. 그래서 루프를 벗어나거나 OS에 의해 죽습니다(아마도 신호에 의해?)

@jsainio , 확인하기 위해 --ipc=host 와 함께 docker를 실행하고 있습니까(이것을 언급하지 않았습니까)? 공유 메모리 세그먼트의 크기를 확인할 수 있습니까(df -h | grep shm)?

@ngimel 저는 --shm-size=1024m 있습니다. df -h | grep shm 보고:

root<strong i="9">@db92462e8c19</strong>:~/mnt# df -h | grep shm
shm                                                          1.0G  883M  142M  87% /dev/shm

그 사용법은 다소 높은 것 같습니다. 이것은 두 명의 좀비 작업자가 있는 도커에 있습니다.

shm 크기를 늘릴 수 있습니까? 방금 확인했고 문제를 재현하려고 시도한 서버에서 16GB였습니다. 도커 플래그를 변경하거나

mount -o remount,size=8G /dev/shm

방금 크기를 512MB로 줄이려고 시도했지만 교착 상태가 아닌 명확한 오류가 발생했습니다. 😕 아직도 재현이 안되네요

docker를 사용하면 shm이 충분하지 않을 때 교착 상태가 발생하는 경향이 있습니다. 이유를 모르는 오류 메시지를 지우는 것입니다. 그러나 일반적으로 shm을 늘리면 해결됩니다(1G에서 교착 상태가 발생했습니다).

좋아, 10개의 작업자를 사용하면 오류가 발생하는 것 같지만 4개의 ​​작업자를 사용하면 /dev/shm 사용량의 58%에서 교착 상태가 발생합니다! 드디어 재현했네

이 문제의 형식을 재현할 수 있다는 것이 좋습니다. 나는 #1579에 중단을 유발하는 스크립트를 게시했는데 당신은 그것이 당신의 시스템에 중단되지 않는다고 대답했습니다. 실제로 MacBook에서만 테스트했습니다. 방금 Linux에서 시도했지만 중단되지 않았습니다. 따라서 Linux에서만 시도했다면 Mac에서도 시도해 볼 가치가 있습니다.

알겠습니다. 문제를 조사한 후 이상한 문제인 것 같습니다. /dev/shm 를 128MB로 제한하더라도 Linux는 147MB 파일을 생성하고 메모리에 완전히 mmap하도록 허용하지만 실제로 페이지에 액세스하려고 시도하면 작업자에게 치명적인 SIGBUS를 보냅니다. ... 등록된 SIGBUS 핸들러로 페이지를 반복하고 각 페이지를 만지는 것을 제외하고는 페이지의 유효성을 확인할 수 있는 메커니즘이 생각나지 않습니다...

현재 해결 방법은 위에 표시된 대로 mount 명령으로 /dev/shm 를 확장하는 것입니다. 16GB로 시도하십시오(RAM이 충분한 경우).

이것에 대한 언급을 찾기가 어렵지만 여기에 하나가 있습니다.

이 문제에 대해 시간을 내주셔서 감사합니다. 이 문제는 오랫동안 저를 미치게 했습니다! 내가 올바르게 이해했다면 /dev/shm 를 8G 대신 16G로 확장해야 합니다. 의미가 있지만 df -h 시도할 때 모든 램이 실제로 할당된 것을 볼 수 있습니다. (16G가 있습니다)

tmpfs              7,8G    393M  7,4G   5% /dev/shm
tmpfs              5,0M    4,0K  5,0M   1% /run/lock
tmpfs              7,8G       0  7,8G   0% /sys/fs/cgroup
tmpfs              1,6G     60K  1,6G   1% /run/user/1001

이것은 교착 상태 동안 df -h 의 출력입니다. 내가 아는 한, 16G의 SWAP 파티션이 있으면 tmpfs를 32G까지 마운트할 수 있으므로 /dev/shm 확장하는 데 문제가 되지 않겠죠?

더 중요한 것은 내 RAM의 거의 절반을 차지하기 때문에 cgroup 파티션과 그 목적에 대해 의아해합니다. 분명히 다중 프로세서 작업을 효율적으로 관리하도록 설계되었지만 그것이 하는 일과 왜 필요한지 잘 모르겠습니다. 모든 물리적 RAM을 shm에 할당하기 위해 무언가를 변경할까요? (크기를 16G로 설정했기 때문에) SWAP에 넣으십시오 (둘 다 부분적으로 RAM과 SWAP에 동시에 있을 것이라고 생각하지만)

@apaszke 감사합니다! 근본적인 원인을 찾으셨다니 대단합니다. 나는 때때로 한 컴퓨터에 다른 부하가 무엇인지에 따라 다양한 "ConnectionReset" 오류와 도커 --shm-size=1024m 교착 상태가 모두 발생했습니다. --shm-size=16384m 및 4명의 작업자와 함께 지금 테스트 중입니다.

@jsainio ConnectionReset이 같은 문제로 인해 발생했을 수 있습니다. 프로세스가 일부 데이터를 교환하기 시작했지만 shm 공간이 부족하면 SIGBUS가 작업자에게 전송되어 종료되었습니다.

@ClementPinard 내가 이해하는 한 원하는 만큼 크게 만들 수 있습니다. 단, RAM이 부족하면 시스템이 정지될 가능성이 있습니다(커널도 이 메모리를 해제할 수 없기 때문에). /sys/fs/cgroup 대해 신경쓰지 않아도 됩니다. tmpfs 파티션은 메모리를 느리게 할당하므로 사용량이 0B로 유지되는 한 비용이 들지 않습니다(제한 포함). 스왑을 사용하는 것은 좋은 생각이 아니라고 생각합니다. 데이터 로드가 훨씬 느려지므로 shm 크기를 12GB로 늘리고 작업자 수를 제한할 수 있습니다(내가 말했듯이, shm에 모든 RAM을 사용하지 마십시오!). 다음 은 커널 문서

/dev/shm 사용량이 매우 적은 경우에도 교착 상태가 발생하는 이유를 모르겠습니다(내 컴퓨터에서 20kB 발생). 아마도 커널은 지나치게 낙관적이지만 모든 것을 채울 때까지 기다리지 않고 이 영역의 모든 것을 사용하기 시작하면 프로세스를 종료합니다.

지금 12G와 내가 가진 절반의 작업자로 테스트했지만 실패했습니다.
그것은 루아 토치 버전(동일한 속도, 동일한 수의 작업자)에서 매력처럼 작동하여 문제가 단지 /dev/shm 관련이 있고 python 다중 처리에 더 가깝지 않은지 궁금하게 만듭니다...

그것에 대해 이상한 점은 (당신이 언급했듯이) /dev/shm 가 결코 가득 /dev/shm 추적해야 합니다. 아마도 데이터 로더가 변경되는 동안 최대 사용량이 있을 수 있습니다.

@ClementPinard 는 공유 메모리가 더 높고 Docker가 없으면 여전히 실패할 수 있습니다.

토치 버전 == Lua Torch인 경우 여전히 /dev/shm 관련될 수 있습니다. Lua Torch는 스레드를 사용할 수 있으므로(GIL이 없음) 공유 메모리를 통과할 필요가 없습니다(모두 단일 주소 공간을 공유함).

새로운 훈련 또는 검증 에포크의 시작 부분에서 메모리를 할당할 수 없다고 불평한 후 데이터 로더가 충돌하는 동일한 문제가 있었습니다. 위의 솔루션은 (i) /dev/shm 가 32GB이고 2.5GB 이상 사용된 적이 없으며 (ii) pin_memory=False 설정이 작동하지 않았습니다.

이것은 아마도 가비지 수집과 관련이 있습니까? 내 코드는 대략 다음과 같습니다. 무한 반복자가 필요하므로 아래 next() 주위를 제외하고 시도합니다 :-)

def train():
    train_iter = train_loader.__iter__()
    for i in xrange(max_batches):
        try:
            x, y = next(train_iter)
        except StopIteration:
            train_iter = train_loader.__iter__()
        ...
    del train_iter

train_loader 는 DataLoader 개체입니다. 함수 끝에 명시적인 del train_iter 줄이 없으면 프로세스는 항상 2-3 에포크 후에 충돌합니다( /dev/shm 여전히 2.5GB를 표시함). 도움이 되었기를 바랍니다!

4 작업자(Ubuntu 16.04의 CUDA 8.0 버전 0.1.12_2 )를 사용하고 있습니다.

특히 work_number가 클 때 교착 상태를 만났습니다. 이 문제에 대한 가능한 해결책이 있습니까? 내 /dev/shm 크기는 32GB이고 cuda 7.5, pytorch 0.1.12 및 python 2.7.13입니다. 다음은 사망 후 관련 정보입니다. 기억과 관련된 것 같다. @apaszke

@zhengyunqq 시도 pin_memory=False 당신이 그것을 설정하면 True . 그렇지 않으면 해결 방법을 모릅니다.

num_workers가 클 때 교착 상태도 만났습니다.

나에게 문제는 작업자 스레드가 어떤 이유로 죽으면 index_queue.put 가 영원히 중단된다는 것입니다. 작업 스레드가 죽어가는 한 가지 이유는 초기화 중 unpickler가 실패하기 때문입니다. 이 경우 2017년 5월 마스터의 이 Python 버그 수정 까지 작업자 스레드가 죽고 끝없는 중단이 발생합니다. 제 경우에는 일괄 프리페칭 프라이밍 단계에서 중단이 발생했습니다.

SimpleQueue 사용된 DataLoaderIter 를 Queue 로 대체하여 우아한 예외 메시지와 함께 시간 초과를 허용합니다.

UPD: 제가 잘못 생각했습니다. 이 버그 수정은 Queue 가 아니라 SimpleQueue Queue 패치합니다. 작업자 스레드가 온라인 상태가 아닌 경우 SimpleQueue 가 잠기는 것은 여전히 ​​사실입니다. 이를 확인하는 쉬운 방법은 이 줄 을 self.workers = [] 로 바꾸는 것입니다.

나는 같은 문제가 있고 shm (허가없이)을 변경할 수 없습니다. 아마도 Queue 또는 다른 것을 사용하는 것이 더 낫습니까?

비슷한 문제가 있습니다.
이 코드는 멈추고 아무 것도 인쇄하지 않습니다. num_workers=0으로 설정하면 작동하지만

dataloader = DataLoader(transformed_dataset, batch_size=2, shuffle=True, num_workers=2)
model.cuda()
for i, batch in enumerate(dataloader):
 print(i)

루프 뒤에 model.cuda()를 넣으면 모든 것이 잘 실행됩니다.

dataloader = DataLoader(transformed_dataset, batch_size=2, shuffle=True, num_workers=2)

for i, batch in enumerate(dataloader):
 print(i)
model.cuda()

누구든지 그 문제에 대한 해결책이 있습니까?

ImageNet을 교육하는 동안에도 비슷한 문제가 발생했습니다. 특정 아키텍처가 있는 특정 서버에서 일관되게 평가의 첫 번째 반복에서 중단되지만(동일한 아키텍처를 가진 다른 서버 또는 아키텍처가 다른 동일한 서버에서는 아님) 유효성 검사 시 평가하는 동안 항상 첫 번째 반복입니다. 내가 Torch를 사용할 때 nccl이 이와 같은 교착 상태를 유발할 수 있음을 발견했습니다. 끄는 방법이 있습니까?

나는 같은 문제에 직면하고 있습니다. 첫 번째 신기원의 시작 부분에서 무작위로 멈춥니다. 위에서 언급한 모든 해결 방법은 저에게 적합하지 않습니다. Ctrl-C를 누르면 다음이 인쇄됩니다.

Traceback (most recent call last):
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/multiprocessing/process.py", line 249, in _bootstrap
    self.run()
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 44, in _worker_loop
    data_queue.put((idx, samples))
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/multiprocessing/queues.py", line 354, in put
    self._writer.send_bytes(obj)
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/multiprocessing/connection.py", line 200, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/multiprocessing/connection.py", line 398, in _send_bytes
    self._send(buf)
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/multiprocessing/connection.py", line 368, in _send
    n = write(self._handle, buf)
KeyboardInterrupt
Traceback (most recent call last):
  File "scripts/train_model.py", line 640, in <module>
    main(args)
  File "scripts/train_model.py", line 193, in main
    train_loop(args, train_loader, val_loader)
  File "scripts/train_model.py", line 341, in train_loop
    ee_optimizer.step()
  File "/home/zhangheng_li/applications/anaconda3/lib/python3.6/site-packages/torch/optim/adam.py", line 74, in step
    p.data.addcdiv_(-step_size, exp_avg, denom)
KeyboardInterrupt

도커 내부의 단일 작업자와 교착 상태가 발생하는 비슷한 문제가 있었고 제 경우에는 공유 메모리 문제임을 확인할 수 있습니다. 기본적으로 도커는 64MB의 공유 메모리만 할당하는 것으로 보이지만 1명의 작업자에 대해 440MB가 필요했는데, 이로 인해 @apaszke에서 설명한 동작이 발생했을 수 있습니다.

나는 같은 문제로 고민하고 있지만 이 스레드의 대부분의 다른 사람들과 다른 환경에 있으므로 내 입력이 근본적인 원인을 찾는 데 도움이 될 수 있습니다. 내 pytorch는 Windows10에서 peterjc123이 빌드한 우수한 conda 패키지를 사용하여 설치됩니다.

cifar10 데이터 세트에서 일부 cnn을 실행하고 있습니다. 데이터 로더의 경우 num_workers는 1로 설정됩니다. num_workers > 0이면 BrokenPipeError가 발생하는 것으로 알려져 있고 #494에서 권장하지 않지만 제가 겪고 있는 것은 BrokenPipeError가 아니라 일부 메모리 할당 오류입니다. 오류는 항상 마지막 epoch의 유효성 검사 직후와 다음 epoch에 대한 훈련 시작 직전인 약 50 epoch에서 발생했습니다. 시간의 90%는 정확히 50 epoch이고 다른 경우에는 1 또는 2 epoch가 다릅니다. 그 외에는 거의 일치합니다. num_workers=0으로 설정하면 이 문제가 해결됩니다.

@paulguerrero 맞습니다. 공유 메모리를 64M에서 2G로 늘려서 이 문제를 해결했습니다. 도커 사용자에게 유용할 수 있습니다.

@berzjackson 그것은 conda 패키지의 알려진 버그입니다. 최신 CI 빌드에서 수정되었습니다.

월요일에 Pytorch를 사용하는 새로운 과정을 시작한 ~600명의 사람들이 있습니다. 포럼의 많은 사람들이 이 문제를 보고하고 있습니다. 일부는 AWS P2, 일부는 자체 시스템(주로 GTX 1070, 일부 Titan X).

그들이 훈련을 중단하면 스택 추적의 끝은 다음을 보여줍니다.

~/anaconda2/envs/fastai/lib/python3.6/multiprocessing/connection.py in _recv_bytes(self, maxsize)
    405 
    406     def _recv_bytes(self, maxsize=None):
--> 407         buf = self._recv(4)
    408         size, = struct.unpack("!i", buf.getvalue())
    409         if maxsize is not None and size > maxsize:

~/anaconda2/envs/fastai/lib/python3.6/multiprocessing/connection.py in _recv(self, size, read)
    377         remaining = size
    378         while remaining > 0:
--> 379             chunk = read(handle, remaining)
    380             n = len(chunk)
    381             if n == 0:

num_workers=4, pin_memory=False가 있습니다. 저는 그들에게 공유 메모리 설정을 확인하도록 요청했습니다. 하지만 이 문제를 해결하기 위해 제가 할 수 있는(또는 Pytorch에서 할 수 있는) 일이 있습니까? (num_workers를 줄이는 것 외에는 작업 속도가 상당히 느려집니다.)

저는 @jph00 (Jeremy에게 감사드립니다! :))이 언급된 수업에 있습니다. "num_workers=0"도 사용해 보았습니다. resnet34가 매우 느리게 로드되는 경우에도 동일한 오류가 발생합니다. 피팅도 매우 느립니다. 그러나 이상한 점은 노트북 세션의 수명 동안 한 번만 발생한다는 것입니다.

다시 말해, 일단 데이터가 로드되고 피팅이 한 번 실행되면 4개의 num_workers로도 계속 이동하고 단계를 반복할 수 있으며 모든 것이 GPU에서 예상대로 빠르게 작동하는 것 같습니다.

저는 PyTorch 0.2.0_4, Python 3.6.2, Torchvision 0.1.9, Ubuntu 16.04 LTS를 사용 중입니다. 내 터미널에서 "df -h"를 수행하면 사용률이 매우 낮았지만 /dev/shm에 16GB가 있다고 말합니다.

다음은 로딩이 실패한 스크린샷입니다(참고로 저는 데이터에 num_workers=0을 사용했습니다).
(소문자가 작아서 죄송합니다. 다 캡쳐하기 위해 줌 아웃을 해야 했습니다...)

@apiltamang 동일한 문제인지 확실하지 않습니다. 동일한 증상처럼 들리지 않습니다. 여기가 아닌 fast.ai 포럼에서 진단하는 것이 가장 좋습니다.

최대한 빨리 조사 중입니다!

@soumith 저는 @apaszke 에게 코스의 비공개 포럼에 대한 액세스 권한을 부여했고 문제가 있는 학생들에게 상자에 로그인할 수 있는 액세스 권한을 부여하도록 요청했습니다.

@jph00 안녕하세요 Jeremy, 학생 중에 위에서 언급한 높이 려고 시도한 학생이 있습니까? 도움이 되었나요?

@SsnL 학생 중 한 명이 공유 메모리를 늘

@jph00 감사합니다! 공유 메모리 부족으로 인한 중단을 성공적으로 재현했습니다. 문제가 다른 곳에 있는 경우 더 깊이 파고들어야 합니다! 저와 스크립트를 공유해 주시겠습니까?

물론입니다. 여기 우리가 사용하는 노트북이 있습니다: https://github.com/fastai/fastai/blob/master/courses/dl1/lesson1.ipynb . 학생들은 노트북에 있는 순서대로 모든 셀을 실행할 때만 문제가 발생한다는 것을 알아차렸습니다. 노트북에 설명이 잘 되어 있기를 바라지만 노트북을 실행하는 데 문제가 있으면 알려주십시오. 여기에는 필요한 데이터를 다운로드할 수 있는 링크가 포함되어 있습니다.

복제할 수 있는 공유 메모리 문제를 기반으로 라이브러리나 노트북에 추가할 수 있는 해결 방법이 있습니까?

@jph00 지금 바로 코드에

나는 또한 그냥 멈추게 두는 것보다 shm 제한에 도달했을 때 멋진 오류 메시지를 보여주기 위해 PR을 보낼 것입니다.

확인 최신 Pytorch conda 설치와 함께 CUDA 9 AMI를 사용하여 새로운 AWS P2 인스턴스에 문제를 복제했습니다. 공개 키를 제공하면 직접 사용해 볼 수 있는 액세스 권한을 부여할 수 있습니다. 내 이메일은 fast.ai에서 내 이름의 첫 글자입니다.

@jph00 방금 이메일을 보냈습니다 :) 감사합니다!

@jph00 그리고 참고로, 스크립트는 내 상자에서 400MB의 공유 메모리를 사용했습니다. 따라서 이 문제가 있는 학생들은 무료 shm이 충분한지 확인하는 것이 좋습니다.

좋아, 나는 opencv와 Pytorch 다중 처리가 때때로 함께 잘 작동하지 않는다는 기본적인 문제를 알아 냈습니다. 우리 대학에서는 문제가 없지만 AWS에서는 많은 문제가 있습니다(P2 인스턴스가 포함된 새로운 딥 러닝 CUDA 9 AMI에서). 모든 cv2 호출 주위에 잠금을 추가해도 문제가 해결되지 않고 cv2.setNumThreads(0) 해도 해결되지 않습니다. 이것은 그것을 해결하는 것 같습니다 :

from multiprocessing import set_start_method
set_start_method('spawn')

그러나 이는 성능에 약 15% 영향을 미칩니다. opencv github 문제의 권장 사항은 https://github.com/tomMoral/loky 를 사용하는 것입니다. 나는 전에 그 모듈을 사용했고 그것이 견고하다는 것을 알았다. 지금 당장은 충분히 잘 작동하는 솔루션이 있으므로 긴급하지 않습니다. 그러나 Dataloader에 Loky를 사용하는 것을 고려해 볼 가치가 있습니까?

아마도 더 중요한 것은 이러한 무한 중단이 잡힐 수 있도록 최소한 pytorch의 대기열에 일종의 시간 초과가 있다는 것입니다.

참고로, '스폰'이 일부 부품을 2-3배 느리게 만들기 때문에 다른 수정을 시도했습니다. 그것은 또한 문제를 해결했습니다. 비록 이상적이지는 않지만!

파헤쳐 주셔서 감사합니다! 두 가지 해결 방법을 찾으셨다니 다행입니다. 실제로 데이터 세트에 인덱싱할 때 시간 초과를 추가하는 것이 좋습니다. 우리는 논의하고 내일 경로에 대해 다시 연락 드리겠습니다.

cc @soumith 는 우리가 조사하고 싶은 로키인가요?

위의 토론을 위해 이 스레드에 오는 사람들을 위해 opencv 문제는 https://github.com/opencv/opencv/issues/5150 에서 더 깊이 논의됩니다.

이제 이에 대한 적절한 수정 사항이 있는 것 같습니다. Dataloader를 ProcessPoolExecutor.map() 사용자로 다시 작성하고 텐서 생성을 상위 프로세스로 옮겼습니다. 결과는 원래 Dataloader에서 본 것보다 더 빠르며 내가 시도한 모든 컴퓨터에서 안정적이었습니다. 코드도 훨씬 간단합니다.

사용에 관심이 있는 사람이 있으면 https://github.com/fastai/fastai/blob/master/fastai/dataloader.py 에서 얻을 수 있습니다.

API는 Dataset이 Pytorch 텐서를 반환하지 않아야 한다는 점을 제외하고는 표준 버전과 동일합니다. 이는 numpy 배열 또는 python 목록을 반환해야 합니다. 이전 Python에서 작동하도록 하려는 시도를 하지 않았으므로 거기에 몇 가지 문제가 있어도 놀라지 않을 것입니다.

(내가 이 길을 택한 이유는 최근 GPU에서 많은 이미지 처리/증강 작업을 수행할 때 Pytorch CPU를 사용하여 사전 처리를 수행하면 GPU를 계속 바쁘게 유지할 만큼 빠르게 처리를 완료할 수 없다는 것을 발견했기 때문입니다. 하지만 opencv를 사용하는 것이 훨씬 더 빨랐고 결과적으로 GPU를 충분히 활용할 수 있었습니다.)

오, 만약 그것이 opencv 문제라면 우리가 그것에 대해 할 수 있는 일이 많지 않습니다. 스레드 풀이 있을 때 포크가 위험한 것은 사실입니다. 특히 PyTorch 텐서를 제대로 처리하지 못할 것이라는 점에서 런타임 종속성을 추가하고 싶지 않다고 생각합니다. 교착 상태의 원인과 @SsnL 이 있는 원인을 파악하는 것이 좋습니다.

@jph00 Pillow-SIMD를 사용해

예, 나는 pillow-SIMD를 잘 압니다. 크기 조정, 흐림 및 RGB 변환 속도만 향상됩니다.

여기에서 할 수 있는 일이 많지 않다는 데 동의하지 않습니다. 이것은 정확히 opencv 문제가 아니며(pytorch의 특수 케이스 다중 처리 모듈은 고사하고 더 일반적으로 이러한 유형의 python 다중 처리를 지원한다고 주장하지 않음) Pytorch 문제도 아닙니다. 그러나 Pytorch가 어떤 종류의 오류도 제공하지 않고 조용히 영원히 기다린다는 사실은 (IMO) 당신이 고칠 수 있는 것이고, 더 일반적으로 많은 똑똑한 사람들이 지난 몇 년 동안 문제를 피하는 개선된 다중 처리 접근 방식을 만들기 위해 열심히 노력해 왔습니다. 이 같은. 외부 종속성을 가져오지 않고 그들이 사용하는 접근 방식에서 차용할 수 있습니다.

Loky 뒤에 있는 사람 중 한 명인 Olivier Grisel은 Python의 다중 처리 상태를 요약한 훌륭한 슬라이드 데크를 가지고 있습니다. http://ogrisel.github.io/decks/2017_euroscipy_parallelism/

나는 이제 문제가 없는 새로운 Dataloader를 작성했기 때문에 어느 쪽이든 상관하지 않습니다. 그러나 FWIW에서는 pytorch의 다중 처리와 다른 시스템 간의 상호 작용이 미래에 다른 사람들에게도 문제가 될 것이라고 생각합니다.

그만한 가치가 있기 때문에 우분투 14.04의 Python 2.7에서 이 문제가 발생했습니다. 내 데이터 로더는 sqlite 데이터베이스에서 읽고 num_workers=0 와 완벽하게 작동했으며 때로는 num_workers=1 괜찮아 보였고 더 높은 값에 대해 매우 빠르게 교착 상태에 빠졌습니다. 스택 추적은 recv_bytes 중단된 프로세스를 보여주었습니다.

작동하지 않는 것들:

• 도커를 시작할 때 --shm-size 8G 또는 --ipc=host
• echo 16834 | sudo tee /proc/sys/kernel/shmmni 를 실행하여 공유 메모리 세그먼트 수를 늘립니다(기본값은 내 컴퓨터에서 4096).
• pin_memory=True 또는 pin_memory=False 중 어느 것도 도움이 되지 않았습니다.

내 문제를 안정적으로 해결한 것은 내 코드를 Python 3으로 이식하는 것이었습니다. (Anaconda의) Python 3.6 인스턴스 내에서 동일한 버전의 Torch를 실행하면 내 문제가 완전히 해결되었으며 이제 데이터 로드가 더 이상 중단되지 않습니다.

@apaszke 참고로, opencv와 함께 잘 작동하는 것이 중요한 이유(그리고 토치샘플이 좋은 옵션이 아닌 이유 - <200개 이미지/초의 회전을 처리할 수 있음!):

누구든지이 문제에 대한 해결책을 찾았습니까?

@iqbalu 위의 스크립트를 사용해보십시오: https://github.com/fastai/fastai/blob/master/fastai/dataloader.py
내 문제를 해결했지만 num_workers=0 지원하지 않습니다.

@elbaro 실제로 시도했는데 제 경우에는 여러 작업자를 전혀 사용하지 않았습니다. 거기에서 변경한 것이 있습니까?

@iqbalu fast.ai 데이터 로더는 작업자 프로세스를 생성하지 않습니다. 스레드만 사용하므로 일부 도구에는 표시되지 않을 수 있습니다.

@apaszke @elbaro @jph00 fast.ai 의 데이터 로더가 데이터 읽기 속도를 10배 이상 늦췄습니다. num_workers=8을 사용하고 있습니다. 어떤 힌트가 그 이유가 될 수 있습니까?

데이터 로더가 GIL을 포기하지 않는 패키지를 사용할 가능성이 있습니다.

@apaszke 공유 메모리 사용량이 몇

@iqbalu 정말 아닙니다. 그런 일이 일어나서는 안 된다

나는 많은 것을 시도했고 cv2.setNumThreads(0) 마침내 내 문제를 해결했습니다.

@jph00 감사합니다

나는 최근에 이 문제로 고민했다. cv2.setNumThreads(0) 이(가) 작동하지 않습니다. 대신 scikit-image를 사용하도록 모든 cv2 코드를 변경했지만 문제는 여전히 존재합니다. 게다가 /dev/shm 16G가 있습니다. 여러 GPU를 사용할 때만 이 문제가 있습니다. 모든 것이 단일 GPU에서 잘 작동합니다. 솔루션에 대해 새로운 생각이 있는 사람이 있습니까?

같은 오류. 단일 GPU를 사용할 때 이 문제가 있습니다.

나를 위해 opencv 스레드를 비활성화하면 문제가 해결되었습니다.
cv2.setNumThreads(0)

pytorch 0.3, cuda 8.0, ubuntu 16.04도 사용해 보세요.
opencv를 사용하지 않습니다.

저는 pytorch 0.3, cuda 8.0, ubuntu 14.04를 사용하고 있습니다. cv2.resize() 사용을 시작한 후 이 중단을 관찰했습니다.

cv2.setNumThreads(0)이 내 문제를 해결했습니다.

2개의 1080Ti 및 32GB RAM이 있는 시스템에서 python 3.6, pytorch 0.3.0, cuda 8.0 및 ubuntu 17.04를 사용하고 있습니다.

내 데이터 세트에 8명의 작업자를 사용할 때 교착 상태가 자주 발생합니다(첫 번째 에포크에서 발생). 작업자를 4로 줄이면 사라집니다(80 Epoch 실행).

교착 상태가 발생하면 RAM에 ~10GB의 여유 공간이 있습니다.

여기에서 스크립트를 종료한 후 로그를 볼 수 있습니다. https://gist.github.com/milani/42f50c023cdca407115b309237d29c70

업데이트: SHMMNI 증가로 문제를 해결할 수 있음을 확인합니다. Ubuntu 17.04에서 kernel.shmmni=8192 를 /etc/sysctl.conf .

Ubuntu 17.10, Python 3.6, Pytorch 0.3.1, CUDA 8.0에서도 이 문제가 발생합니다. 교착 상태가 발생하고 시간이 일치하지 않는 것처럼 보일 때 RAM이 충분히 남아 있습니다. 첫 번째 에포크 이후 또는 200번째 이후에 발생할 수 있습니다.

kernel.shmmni=8192 와 cv2.setNumThreads(0) 을 조합하면 해결된 것 같지만 개별적으로는 작동하지 않습니다.

제 경우에도 마찬가지입니다. num_workers=4로 설정하면 교착 상태가 발생했습니다. Ubuntu 17.10, Pytorch 0.3.1, CUDA 9.1, python 3.6을 사용합니다. 4개의 python 스레드가 있으며, 각 스레드는 CPU(4개 코어)가 유휴 상태로 유지되는 동안 1.6GB 메모리를 차지합니다. num_workers=0으로 설정하면 이 문제를 해결하는 데 도움이 됩니다.

똑같은 문제가 있는데 정확히 한 에포크 후에 정지되지만 더 작은 데이터 세트에서는 실제로 재현할 수 없습니다. Docker 환경에서 CUDA 9.1, Pytorch 0.3.1, Python 3.6을 사용하고 있습니다.
@jph00 의 Dataloader를 시도했지만 내 사용

Ubuntu 17.10, CUDA 9.1, Pytorch 마스터(19/04 아침 컴파일)에서 정확히 동일한 문제가 발생했습니다. 또한 내 Dataset 하위 클래스에서 OpenCV를 사용합니다.

그런 다음 다중 처리 시작 방법을 'forkserver'에서 'spawn'으로 변경하여 교착 상태를 피할 수 있었습니다.

# Set multiprocessing start method - deadlock
set_start_method(forkserver')

# Set multiprocessing start method - runs fine
set_start_method('spawn')

위의 모든 접근 방식을 거의 시도했습니다! 그들 중 누구도 일하지 않았습니다!
이 문제는 하드웨어 아키텍처와의 일부 비호환성과 관련이 있을 수 있으며 Pytorch가 이를 유발할 수 있는지 모르겠습니다! Pytorch 문제일 수도 있고 아닐 수도 있습니다!

제 문제가 해결된 방법은 다음과 같습니다.
_BIOS를 업데이트합니다!

한번 해보세요. 적어도 내 문제를 해결합니다.

여기도 마찬가지입니다. 우분투 파이토치 0.4, 파이썬 3.6.

문제는 여전히 pytorch 0.4 및 python 3.6에 존재하는 것 같습니다. pytorch 문제인지 확실하지 않습니다. 나는 opencv를 사용하고 num_workers=8 , pin_memory=True . 위에서 언급한 모든 트릭을 시도하고 cv2.setNumThreads(0) 를 설정하면 문제가 해결됩니다.

(1) PyTorch 데이터 로드에서 num_workers=0을 설정하면 문제가 해결됩니다(위 참조) 또는
(2) cv2.setNumThreads(0)은 합리적으로 큰 num_workers가 있는 경우에도 문제를 해결합니다.

이것은 일종의 스레드 잠금 문제처럼 보입니다.

나는 cv2.setNumThreads(0)을 내 주요 파이썬 파일의 시작 부분으로 설정했고 그 이후로 이 문제가 발생한 적이 없습니다.

예, 이러한 문제의 대부분은 타사 라이브러리가 포크로부터 안전하지 않기 때문입니다. 한 가지 대안은 스폰 시작 방법을 사용하는 것입니다.

제 경우에는 모델을 nn.DataParallel로 래핑하고 데이터 로더에서 num_workers > 0을 사용할 때 교착 상태 문제가 발생합니다. nn.DataParallel 래퍼를 제거하면 잠금 없이 스크립트를 실행할 수 있습니다.
CUDA_VISIBLE_DEVICES=0 파이썬 myscript.py --split 1
CUDA_VISIBLE_DEVICES=1 파이썬 myscript.py --split 2

다중 GPU가 없으면 스크립트가 더 느리게 실행되지만 데이터 세트의 다른 분할에서 동시에 여러 실험을 실행할 수 있습니다.

Python 3.6.2 / Pytorch 0.4.0에서 동일한 문제가 있습니다.
그리고 무엇보다도 pin_memory 전환, 공유 메모리 크기 변경, 그리고 Skiamge 라이브러리(저는 cv2를 사용하지 않습니다!!)를 사용하려고 했지만 여전히 문제가 있습니다.

이 문제는 무작위로 발생합니다. 이 문제를 제어하는 ​​것은 콘솔을보고 훈련을 다시 시작하는 것입니다.

@jinh574 방금 데이터 로더 작업자 수를 0으로 설정

@Shuailong 큰 이미지를 사용해야 하므로 속도 때문에 해당 매개변수를 사용할 수 없습니다. 나는 이 문제에 대해 더 조사할 필요가 있다

Python 3.6 / Pytorch 0.4.0에서 동일한 문제가 있습니다. pin_memory 옵션이 영향을 미칩니까?

collate_fn 및 num_workers>0을 PyTorch 버전 < 0.4와 함께 사용하는 경우:

__getitem__() 함수에서 ZERO DIM 텐서를 반환하지 않도록 하십시오.
또는 NUMPY 어레이로 반환합니다.

num_workers=0 또는 cv2.setNumThreads(0)을 설정한 후에도 해당 문제가 있습니다.

이 두 가지 문제 중 하나로 실패합니다. 같은 일에 직면한 다른 사람이 있습니까?

역추적(가장 최근 호출 마지막):
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/runpy.py", 193행, _run_module_as_main
"__main__", mod_spec)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/runpy.py", 85행, _run_code
exec(코드, run_globals)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/site-packages/torch/distributed/launch.py", 209행,
기본()
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/site-packages/torch/distributed/launch.py", 라인 205, 메인
프로세스.대기()
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/subprocess.py", 라인 1457, 대기 중
(pid, sts) = self._try_wait(0)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/subprocess.py", 1404행, _try_wait
(pid, sts) = os.waitpid(self.pid, wait_flags)
키보드 인터럽트

파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/process.py", 258행, _bootstrap
self.run()
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/process.py", 라인 93, 실행 중
self._target( self._args, * self._kwargs)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/site-packages/torch/utils/data/dataloader.py", 96행, _worker_loop
r = index_queue.get(시간 초과=MANAGER_STATUS_CHECK_INTERVAL)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/queues.py", 104행, get
self._poll(시간 초과)이 아닌 경우:
설문조사에서 파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/connection.py", 257행
self._poll 반환(시간 초과)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/connection.py", 414행, _poll
r = 대기([자체], 시간 초과)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/connection.py", 라인 911, 대기 중
준비 = selector.select(시간 초과)
파일 "/opt/conda/envs/pytorch-py3.6/lib/python3.6/selectors.py", 376행, 선택
fd_event_list = self._poll.poll(시간 초과)
키보드 인터럽트

버전 '0.5.0a0+f57e4ce'를 사용하고 있는데 동일한 문제가 발생했습니다. 병렬 데이터 로더(num_workers=0)를 취소하거나 cv2.setNumThreads(0)를 설정하면 작동합니다.

나는 #11985가 모든 중단을 제거해야 한다고 상당히 확신합니다(당신이 우리가 통제할 수 없는 불행한 시간에 방해하지 않는 한). 이제 병합되었으므로 이것을 닫습니다.

cv2가 멀티프로세싱에서 제대로 작동하지 않기 때문에 cv2의 중단도 제어할 수 없습니다.

torch_nightly-1.0.0.dev20181029 현재까지도 이것을 경험하고 있으며 아직 PR이 병합되지 않았습니까?

@Evpok 이것은 거기에 병합되었습니다. 이 패치가 있어야 합니다. 더 이상 남아있는 교착 상태가 가능한지 궁금합니다. 우리가 볼 수 있는 쉬운 재현이 있습니까?

실제로 제 쪽에서 관련없는 다중 처리 엉망으로 추적했습니다. 불편을 드려 죄송합니다.

안녕하세요 @Evpok
나는 torch_nightly-1.0.0 를 사용하고 이 문제를 해결합니다. 이 문제를 해결했습니까?

collate_fn 및 num_workers>0을 PyTorch 버전 < 0.4와 함께 사용하는 경우:

__getitem__() 함수에서 ZERO DIM 텐서를 반환하지 않도록 하십시오.
또는 NUMPY 어레이로 반환합니다.

0 희미한 텐서를 반환하는 버그를 수정했는데 문제가 여전히 존재합니다.

@zimenglan-sysu-512 주요 문제는 멀티프로세싱의 한계였습니다. spawn 또는 forkserver (CPU-GPU 통신에 필요)를 사용할 때 프로세스 간에 객체를 공유하는 것은 다소 제한적이며 그렇지 않습니다. 내가 조작해야 하는 개체의 종류에 적합합니다.

이 중 어느 것도 나를 위해 일하지 않았습니다. 그러나 최신 opencv는 작동합니다( 3.4.0.12 ~ 3.4.3.18 변경할 사항 없음).
sudo pip3 install --upgrade opencv-python

@see-- opencv가 문제를 해결했다는 사실을 알게 되어 기쁩니다. :)

저는 python2.7과 함께 OpenCV 3.4.3.18을 사용 중이며 여전히 교착 상태가 발생하는 것을 봅니다. :/

다음을 시도하십시오.

from torch.utils.data.dataloader import DataLoader

대신에

from torch.utils.data import DataLoader

여기에서 유형 검사에 문제가 있다고 생각합니다.
https://github.com/pytorch/pytorch/blob/656b565a0f53d9f24547b060bd27aa67ebb89b88/torch/utils/data/dataloader.py#L816

다음을 시도하십시오.

from torch.utils.data.dataloader import DataLoader

대신에

from torch.utils.data import DataLoader

여기에서 유형 검사에 문제가 있다고 생각합니다.

pytorch/torch/utils/data/dataloader.py

656b565의 816행
super(DataLoader, self).__setattr__(attr, val)

이것은 단지 별칭이 아닙니까? Torch.utils.data.__init__에서 dataloader.DataLoader를 가져옵니다.

나는 또한 num_workers> 0으로 매달려있었습니다. 내 코드에는 opencv가 없으며 /dev/shm 의 메모리 사용량은 문제가 되지 않습니다. 위의 제안 사항이 저에게 효과적이지 않았습니다. 내 수정 사항은 numpy를 1.14.1에서 1.14.5로 업데이트하는 것이 었습니다.
conda install numpy=1.14.5
도움이 되기를 바랍니다.

흠, 내 numpy 버전은 1.15.4이므로 1.14.5보다 최신 버전입니다... 그럼 괜찮을까요?

흠, 내 numpy 버전은 1.15.4이므로 1.14.5보다 최신 버전입니다... 그럼 괜찮을까요?

Idk, numpy 업데이트도 mkl을 업데이트했습니다.

어떤 mkl 버전이 있습니까? 광산은 2019.1(빌드 144)이고 이름에 mkl이 포함된 기타 패키지는 다음과 같습니다.

mkl 서비스 1.1.2 py37he904b0f_5
mkl_fft 1.0.6 py37hd81dba3_0
mkl_random 1.0.2 py37hd81dba3_0

어떤 mkl 버전이 있습니까? 광산은 2019.1(빌드 144)이고 이름에 mkl이 포함된 기타 패키지는 다음과 같습니다.

mkl 서비스 1.1.2 py37he904b0f_5
mkl_fft 1.0.6 py37hd81dba3_0
mkl_random 1.0.2 py37hd81dba3_0

conda list | grep mkl
mkl                       2018.0.1             h19d6760_4
mkl-service               1.1.2            py36h17a0993_4

최신 pytorch에서 여전히 중단이 표시되는 경우 문제를 재현하는 짧은 스크립트를 제공할 수 있다면 큰 도움이 될 것입니다. 감사 해요!

나는 여전히 이 교착 상태를 보고 있습니다. 재생산하는 스크립트를 만들 수 있는지 확인하겠습니다.

pin_memory=True 이(가) 문제를 해결했습니다.

pin_memory=True 와 함께 작동하지 않는 것 같습니다. 70 epoch 후에도 여전히 멈춥니다. 지금까지 나를 위해 일한 것은 num_workers=0 설정하는 것이지만 눈에 띄게 느립니다.

또한 교착 상태가 발생하고 있습니다(매우 무작위로 발생). pin_memory 시도하고 Numpy를 업데이트했습니다. 다른 컴퓨터에서 실행해 보겠습니다.

데이터 로더가 있는 여러 스레드를 사용하는 경우 멀티스레딩 대신 멀티프로세싱을 사용해 보십시오. 이것은 나를 위해 문제를 완전히 해결했습니다 (그런데 GIL 때문에 Python에서 계산 집약적 인 작업에도 더 좋습니다)

Pytorch1.0, Pillow5.0.0 numpy1.16.1 python3.6에서 동일한 오류

나는 또한 같은 오류가 발생합니다. pin_memory=True 및 num_workers=0 . 데이터 세트의 작은 부분을 사용할 때 이 오류가 발생하지 않는다는 사실을 알게 되었습니다. 전체 데이터 세트만 사용하면 이 오류가 발생합니다.

편집: 시스템을 간단히 다시 시작하면 문제가 해결되었습니다.

나는 비슷한 문제가 있었다. 일부 코드에서 이 함수는 (거의 항상) d_iter.next()에서 중단됩니다.

def get_next_batch(d_iter, loader):
    try:
        data, label = d_iter.next()
    except StopIteration:
        d_iter = iter(loader)
        data, label = d_iter.next()
    return data, label

나를 위해 일한 해킹은이 함수를 호출 한 후 약간의 지연을 추가하는 것이 었습니다.

trn_X, trn_y = get_next_batch(train_data_iter, train_loader)
time.sleep(0.003)
val_X, val_y = get_next_batch(valid_data_iter, valid_loader)

지연이 교착 상태를 피하는 데 도움이 된 것 같습니까?

나는 여전히 이 문제를 겪고 있다. pytorch 1.0 및 python 3.7 사용. 여러 data_loader를 사용할 때 이 버그가 나타납니다. 3개 미만의 data_loader를 사용하거나 단일 GPU를 사용하는 경우 이 버그가 나타나지 않습니다. 시험을 마친:

1. time.sleep(0.003)
2. pin_memory=참/거짓
3. num_workers=0/1
4. Torch.utils.data.dataloader에서 DataLoader 가져오기
5. /proc/sys/kernel/shmmni에 8192 쓰기
   그들 중 누구도 작동하지 않습니다. 해결책이 있는지 모르십니까?

내 솔루션은 전처리 프로그램에서 cv2.setNumThreads(0)을 추가합니다.
나는 기차와 발을위한 2 개의 데이터 로더가 있습니다.
한 번만 평가자를 실행할 수 있습니다.

방금 pytorch 1.1에서 이 버그를 만났습니다. 99번째 epoch의 끝에서 같은 위치에 두 번 멈췄습니다. pin_memory 이 False 로 설정되었습니다.

작업자> 0을 사용할 때도 동일한 문제, 핀 메모리로 문제가 해결되지 않았습니다.

내 솔루션은 전처리 프로그램에서 cv2.setNumThreads(0)을 추가합니다.
나는 기차와 발을위한 2 개의 데이터 로더가 있습니다.
한 번만 평가자를 실행할 수 있습니다.

이 솔루션은 저에게 효과적입니다. 감사합니다.

데이터 로더는 내가 Epoch를 마치면 중지되고 새 Epoch를 시작합니다.

같은 문제를 만난다. 제 경우에는 opencv-python을 설치할 때 문제가 발생합니다(이전에 opencv3을 설치했습니다). opencv-python을 이동한 후 교육이 중지되지 않습니다.

그것도 좋은 생각이야

2019-06-20 10:51:02에서 "hongzhenwang" [email protected]에서 다음과 같이 썼습니다.

데이터 로더는 내가 Epoch를 마치면 중지되고 새 Epoch를 시작합니다.

같은 문제를 만난다. 제 경우에는 opencv-python을 설치할 때 문제가 발생합니다(이전에 opencv3을 설치했습니다). opencv-python을 이동한 후 교육이 중지되지 않습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

나는 여전히 이 문제를 겪고 있다. pytorch 1.0 및 python 3.7 사용. 여러 data_loader를 사용할 때 이 버그가 나타납니다. 3개 미만의 data_loader를 사용하거나 단일 GPU를 사용하는 경우 이 버그가 나타나지 않습니다. 시험을 마친:

1. time.sleep(0.003)

2. pin_memory=True/False

3. num_workers=0/1

4. from torch.utils.data.dataloader import DataLoader

5. writing 8192 to /proc/sys/kernel/shmmni
   None of them works. Don't know whether there is any solutions?

여전히 해결 방법을 찾으려고 합니다. 다른 GPU에서 동시에 2개의 병렬 프로세스를 실행할 때만 이 문제가 있는 것 같다는 데 동의합니다. 하나는 계속 진행되고 다른 하나는 멈춥니다.

num_workers=4로 설정하면 프로그램이 배치 4개마다 몇 초(또는 몇 분) 동안 중단되어 많은 시간을 낭비합니다. 해결 방법에 대한 아이디어가 있습니까?

데이터 로더에 pin_memory=True 및 num_workers=0 플래그를 추가하는 것이 솔루션입니다!

데이터 로더에 pin_memory=True 및 num_workers=0 플래그를 추가하는 것이 솔루션입니다!
@ArturoDeza
이것이 해결책일 수 있습니다. 그러나 num_workers=0으로 설정하면 CPU의 전체 데이터 가져오기 속도가 느려지고 GPU 사용률이 매우 낮아집니다.

저에게 그 이유는 시스템에 CPU가 충분하지 않거나 Dataloader에 지정된 num_workers 충분하지 않았기 때문입니다. 데이터 로더의 __get_item__ 메소드가 numpy , librosa 또는 opencv 와 같은 스레드 라이브러리를 사용하는 경우 데이터 로더 작업자에서 스레딩을 비활성화하는 것도 좋은 생각일 수 있습니다 numpy opencv (이것이 중요한 이유는 아래 참조). 이것은 OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 python train.py 훈련 스크립트를 실행하여 달성할 수 있습니다. 아래 설명을 명확히 하기 위해 각 Dataloader 배치는 단일 작업자가 처리합니다. 각 작업자는 batch_size 샘플을 처리하여 단일 배치를 완료한 다음 새 데이터 배치 처리를 시작합니다.

num_workers 머신(또는 Kubernetes를 사용하는 경우 포드)의 CPU 수보다 낮게 설정해야 하지만 데이터가 다음 반복을 위해 항상 준비될 수 있을 만큼 충분히 높게 설정해야 합니다. GPU가 t 초 안에 각 반복을 실행하고 각 데이터 로더 작업자가 단일 배치를 로드/처리하는 데 N*t 초가 걸린다면 num_workers 를 N 이상으로 설정해야 합니다 N CPU가 있어야 합니다.

불행히도 Dataloader가 K 스레드를 사용하는 라이브러리를 사용하는 경우 생성되는 프로세스 수는 num_workers*K = N*K 됩니다. 이는 시스템의 CPU 수보다 훨씬 많을 수 있습니다. 이렇게 하면 포드가 제한되고 Dataloader가 매우 느려집니다. 이로 인해 Dataloader가 t초마다 배치를 반환하지 않아 GPU가 중단될 수 있습니다.

K 스레드를 피하는 한 가지 방법은 OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 python train.py 메인 스크립트를 호출하는 것입니다. 이렇게 하면 각 Dataloader 작업자가 단일 스레드를 사용하도록 제한하고 시스템에 과부하가 걸리는 것을 방지할 수 있습니다. GPU 공급을 유지하려면 여전히 충분한 num_workers 가 있어야 합니다.

또한 __get_item__ 에서 코드를 최적화하여 각 작업자가 짧은 시간에 배치를 완료할 수 있도록 해야 합니다. 작업자가 배치 전처리를 완료하는 데 걸리는 시간이 디스크에서 교육 데이터를 읽는 시간(특히 네트워크 저장소에서 읽는 경우) 또는 네트워크 대역폭(네트워크에서 읽는 경우)에 의해 방해받지 않는지 확인하십시오. 디스크). 데이터세트가 작고 RAM이 충분한 경우 데이터세트를 RAM(또는 /tmpfs )으로 이동하고 빠른 액세스를 위해 읽어보세요. Kubernetes의 경우 RAM 디스크를 만들 수 있습니다(Kubernetes에서 emptyDir 검색).

__get_item__ 코드를 최적화하고 디스크 액세스/네트워크 액세스가 원인이 아님을 확인했지만 여전히 중단이 표시되는 경우 더 많은 CPU(Kubernetes 포드용)를 요청하거나 GPU를 다음으로 이동해야 합니다. CPU가 더 많은 머신.

또 다른 옵션은 batch_size 를 줄여 각 worker 가 해야 할 작업을 줄이고 사전 처리를 더 빨리 완료하도록 하는 것입니다. 유휴 GPU 메모리가 사용되지 않기 때문에 후자의 옵션은 경우에 따라 바람직하지 않습니다.

일부 사전 처리를 오프라인으로 수행하고 각 작업자의 부담을 덜어줄 수도 있습니다. 예를 들어, 각 작업자가 wav 파일을 읽고 오디오 파일에 대한 스펙트로그램을 계산하는 경우 오프라인에서 스펙트로그램을 미리 계산하고 작업자의 디스크에서 계산된 스펙트로그램을 읽을 수 있습니다. 이렇게 하면 각 작업자가 해야 하는 작업의 양이 줄어듭니다.

horovod와 같은 문제를 만나다

비슷한 문제를 만나보세요... 에포크를 끝내고 유효성 검사를 위해 데이터를 로드하기 시작하는 동안 교착 상태가 발생했습니다...

@jinhou @jackroos horovod 로 유효성 검사 시작 시 무작위로 멈췄습니다. 현재 해결 방법으로 수행하는 작업은 시간 초과를 설정하고 유효성 검사를 건너뛰는 것입니다. 해결책이 있습니까?

@jinhou @jackroos horovod 로 유효성 검사 시작 시 무작위로 멈췄습니다. 현재 해결 방법으로 수행하는 작업은 시간 초과를 설정하고 유효성 검사를 건너뛰는 것입니다. 해결책이 있습니까?

아니요. 이 경우 분산 교육을 끕니다.

비슷한 문제가 발생했습니다. 한 에포크를 마치면 데이터 로더가 중지되고 새 에포크가 시작됩니다.

잔이 왜 이렇게 많아?

나는 여전히 이 문제를 겪고 있다. pytorch 1.0 및 python 3.7 사용. 여러 data_loader를 사용할 때 이 버그가 나타납니다. 3개 미만의 data_loader를 사용하거나 단일 GPU를 사용하는 경우 이 버그가 나타나지 않습니다. 시험을 마친:

1. time.sleep(0.003)
2. pin_memory=참/거짓
3. num_workers=0/1
4. Torch.utils.data.dataloader에서 DataLoader 가져오기
5. /proc/sys/kernel/shmmni에 8192 쓰기
   그들 중 누구도 작동하지 않습니다. 해결책이 있는지 모르십니까?

0으로 설정된 num_workers가 저에게 효과적이었습니다. 사용하는 모든 곳에서 0인지 확인해야 합니다.

다른 잠재적인 솔루션:

1. 멀티프로세싱 가져오기 set_start_method에서
   set_start_method('스폰')
2. cv2.setNumThreads(0)

3~7번 정도 가는 것 같습니다.

나는 pytorch 1.3, ubuntu16에서 이 문제를 경험했습니다. 위의 모든 제안은 실행을 느리게 하는 작업자=0을 제외하고는 작동하지 않았습니다. 이것은 터미널에서 실행할 때만 발생합니다. Jupyter 노트북 내에서는 작업자가 32인 경우에도 모든 것이 정상입니다.

문제가 해결되지 않은 것 같습니다. 다시 열어야 합니까? 같은 문제를 보고하시는 분들도 많이 보이네요...

나는 여전히 이 문제를 겪고 있다. pytorch 1.0 및 python 3.7 사용. 여러 data_loader를 사용할 때 이 버그가 나타납니다. 3개 미만의 data_loader를 사용하거나 단일 GPU를 사용하는 경우 이 버그가 나타나지 않습니다. 시험을 마친:

1. time.sleep(0.003)
2. pin_memory=참/거짓
3. num_workers=0/1
4. Torch.utils.data.dataloader에서 DataLoader 가져오기
5. /proc/sys/kernel/shmmni에 8192 쓰기
   그들 중 누구도 작동하지 않습니다. 해결책이 있는지 모르십니까?

0으로 설정된 num_workers가 저에게 효과적이었습니다. 사용하는 모든 곳에서 0인지 확인해야 합니다.

다른 잠재적인 솔루션:

1. 멀티프로세싱 가져오기 set_start_method에서
   set_start_method('스폰')
2. cv2.setNumThreads(0)

3~7번 정도 가는 것 같습니다.

train.py 과 같이 수정했습니다.

from __future__ import division

import cv2
cv2.setNumThreads(0)

import argparse

...

그리고 그것은 나를 위해 작동합니다.

여러분, 제가 도울 수 있다면
나는 또한 이와 유사한이 문제가 있었지만 100 정도마다 발생합니다.

나는 그것이 CUDA를 활성화했을 때만 발생했다는 것을 알아차렸고, 또한 dmesg는 충돌할 때마다 이 로그 항목을 가지고 있습니다.

python[11240]: segfault at 10 ip 00007fabdd6c37d8 sp 00007ffddcd64fd0 error 4 in libcudart.so.10.1.243[7fabdd699000+77000]

그것은 나에게 횡설수설하지만 CUDA와 python 멀티스레딩이 제대로 작동하지 않는다고 말했습니다.

내 수정은 데이터 스레드에서 cuda를 비활성화하는 것이 었습니다. 여기 내 파이썬 항목 파일의 스니펫이 있습니다.

from multiprocessing import set_start_method
import os

if __name__ == "__main__":
  set_start_method('spawn')
else:
  os.environ["CUDA_VISIBLE_DEVICES"] = ""

import torch
import application

바라건대 그것은 내가 당시 필요로 했던 것처럼 여기에 착륙하는 누군가를 도울 수 있습니다.

@jinhou @jackroos horovod 로 유효성 검사 시작 시 무작위로 멈췄습니다. 현재 해결 방법으로 수행하는 작업은 시간 초과를 설정하고 유효성 검사를 건너뛰는 것입니다. 해결책이 있습니까?

아니요. 이 경우 분산 교육을 끕니다.

PyTorch 1.4로 업데이트한 후 OpenCV를 사용하지 않고 분산 교육에서 비슷한 문제를 만났습니다.
이제 훈련 및 검증 루프 전에 검증을 한 번 실행해야 합니다.

나는 이것 때문에 많은 어려움을 겪었다. pytorch 버전, python 버전 및 다른 물리적 시스템(동일하게 설정되었을 수 있음)에서 지속되는 것 같습니다.

매번 같은 오류가 발생합니다.

File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/site-packages/bicep/loops.py", line 73, in __call__
    for data, target in self.dataloader:
File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 345, in __next__
    data = self._next_data()
File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 830, in _next_data
    self._shutdown_workers()
File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 942, in _shutdown_workers
    w.join()
File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/multiprocessing/process.py", line 149, in join
    res = self._popen.wait(timeout)
File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/multiprocessing/popen_fork.py", line 47, in wait
    return self.poll(os.WNOHANG if timeout == 0.0 else 0)
File "/home/<me>/miniconda2/envs/<my-module>/lib/python3.8/multiprocessing/popen_fork.py", line 27, in poll
    pid, sts = os.waitpid(self.pid, flag)

내가 사용하는 컴퓨터에서 프로세스가 처리되는 방식에 분명히 몇 가지 문제가 있습니다. num_workers=0을 설정하는 것 외에는 위의 솔루션 중 어느 것도 작동하지 않는 것 같습니다.

나는 이것의 바닥에 도달할 수 있기를 정말로 원합니다. 누구든지 이것을 시작하거나 질문하는 방법을 알고 있습니까?

나도 여기.

ERROR: Unexpected segmentation fault encountered in worker.
Traceback (most recent call last):
  File "/home/miniconda/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 480, in _try_get_batch
    data = self.data_queue.get(timeout=timeout)
  File "/home/miniconda/lib/python3.6/multiprocessing/queues.py", line 104, in get
    if not self._poll(timeout):
  File "/home/miniconda/lib/python3.6/multiprocessing/connection.py", line 257, in poll
    return self._poll(timeout)
  File "/home/miniconda/lib/python3.6/multiprocessing/connection.py", line 414, in _poll
    r = wait([self], timeout)
  File "/home/miniconda/lib/python3.6/multiprocessing/connection.py", line 911, in wait
    ready = selector.select(timeout)
  File "/home/miniconda/lib/python3.6/selectors.py", line 376, in select
    fd_event_list = self._poll.poll(timeout)
  File "/home/miniconda/lib/python3.6/site-packages/torch/utils/data/_utils/signal_handling.py", line 65, in handler
    _error_if_any_worker_fails()
RuntimeError: DataLoader worker (pid 95106) is killed by signal: Segmentation fault.

한 가지 흥미로운 점은

데이터를 한 줄씩 구문 분석하면이 문제가 발생하지 않습니다.

        with open(current_file, mode='rb') as f:
            text = f.read().decode('utf-8')
            all_data.extend(text.split('\n'))

하지만 한 줄씩 읽은 후 JSON 구문 분석 논리를 추가하면 이 오류가 보고됩니다.

with open(current_file, mode='rb') as f:
            text = f.read().decode('utf-8')
            all_data.extend(text.split('\n'))

        json_data = []
        for line in all_data:
            try:
                json_data.append(json.loads(line))
            except:
                break
return json_data

약간의 JSON 메모리 오버헤드가 있다는 것을 이해하지만 작업자 수를 2로 줄이고 데이터 세트가 매우 작아도 여전히 동일한 문제가 있습니다. 나는 그것이 shm과 관련이 있는지 의심합니다. 어떤 단서?

이 문제를 다시 열어 볼까요?

우리는 그래야만 해. BTW, 일부 GDB 디버그를 수행했지만 아무 것도 발견되지 않았습니다. 그래서 공유 메모리 문제인지 확실하지 않습니다.

(gdb) run

Starting program: /home/miniconda/bin/python performance.py

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

[New Thread 0x7fffa60a6700 (LWP 61963)]

[New Thread 0x7fffa58a5700 (LWP 61964)]

[New Thread 0x7fffa10a4700 (LWP 61965)]

[New Thread 0x7fff9e8a3700 (LWP 61966)]

[New Thread 0x7fff9c0a2700 (LWP 61967)]

[New Thread 0x7fff998a1700 (LWP 61968)]

[New Thread 0x7fff970a0700 (LWP 61969)]

[New Thread 0x7fff9489f700 (LWP 61970)]

[New Thread 0x7fff9409e700 (LWP 61971)]

[New Thread 0x7fff8f89d700 (LWP 61972)]

[New Thread 0x7fff8d09c700 (LWP 61973)]

[New Thread 0x7fff8a89b700 (LWP 61974)]

[New Thread 0x7fff8809a700 (LWP 61975)]

[New Thread 0x7fff85899700 (LWP 61976)]

[New Thread 0x7fff83098700 (LWP 61977)]

[New Thread 0x7fff80897700 (LWP 61978)]

[New Thread 0x7fff7e096700 (LWP 61979)]

[New Thread 0x7fff7d895700 (LWP 61980)]

[New Thread 0x7fff7b094700 (LWP 61981)]

[New Thread 0x7fff78893700 (LWP 61982)]

[New Thread 0x7fff74092700 (LWP 61983)]

[New Thread 0x7fff71891700 (LWP 61984)]

[New Thread 0x7fff6f090700 (LWP 61985)]

[Thread 0x7fff7e096700 (LWP 61979) exited]

[Thread 0x7fff6f090700 (LWP 61985) exited]

[Thread 0x7fff74092700 (LWP 61983) exited]

[Thread 0x7fff7b094700 (LWP 61981) exited]

[Thread 0x7fff80897700 (LWP 61978) exited]

[Thread 0x7fff83098700 (LWP 61977) exited]

[Thread 0x7fff85899700 (LWP 61976) exited]

[Thread 0x7fff8809a700 (LWP 61975) exited]

[Thread 0x7fff8a89b700 (LWP 61974) exited]

[Thread 0x7fff8d09c700 (LWP 61973) exited]

[Thread 0x7fff8f89d700 (LWP 61972) exited]

[Thread 0x7fff9409e700 (LWP 61971) exited]

[Thread 0x7fff9489f700 (LWP 61970) exited]

[Thread 0x7fff970a0700 (LWP 61969) exited]

[Thread 0x7fff998a1700 (LWP 61968) exited]

[Thread 0x7fff9c0a2700 (LWP 61967) exited]

[Thread 0x7fff9e8a3700 (LWP 61966) exited]

[Thread 0x7fffa10a4700 (LWP 61965) exited]

[Thread 0x7fffa58a5700 (LWP 61964) exited]

[Thread 0x7fffa60a6700 (LWP 61963) exited]

[Thread 0x7fff71891700 (LWP 61984) exited]

[Thread 0x7fff78893700 (LWP 61982) exited]

[Thread 0x7fff7d895700 (LWP 61980) exited]

total_files = 5040.  //customer comments

[New Thread 0x7fff6f090700 (LWP 62006)]

[New Thread 0x7fff71891700 (LWP 62007)]

[New Thread 0x7fff74092700 (LWP 62008)]

[New Thread 0x7fff78893700 (LWP 62009)]

ERROR: Unexpected segmentation fault encountered in worker.

ERROR: Unexpected segmentation fault encountered in worker.

Traceback (most recent call last):

File "/home/zhrui/.local/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 761, in _try_get_data

data = self._data_queue.get(timeout=timeout)

File "/home/miniconda/lib/python3.6/multiprocessing/queues.py", line 104, in get

if not self._poll(timeout):

File "/home/miniconda/lib/python3.6/multiprocessing/connection.py", line 257, in poll

return self._poll(timeout)

File "/home/miniconda/lib/python3.6/multiprocessing/connection.py", line 414, in _poll

r = wait([self], timeout)

File "/home/miniconda/lib/python3.6/multiprocessing/connection.py", line 911, in wait

ready = selector.select(timeout)

File "/home/miniconda/lib/python3.6/selectors.py", line 376, in select

fd_event_list = self._poll.poll(timeout)

File "/home/zhrui/.local/lib/python3.6/site-packages/torch/utils/data/_utils/signal_handling.py", line 66, in handler

_error_if_any_worker_fails()

RuntimeError: DataLoader worker (pid 62005) is killed by signal: Segmentation fault.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "performance.py", line 62, in <module>

main()

File "performance.py", line 48, in main

for i,batch in enumerate(rl_data_loader):

File "/home/zhrui/.local/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 345, in __next__

data = self._next_data()

File "/home/zhrui/.local/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 841, in _next_data

idx, data = self._get_data()

File "/home/zhrui/.local/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 808, in _get_data

success, data = self._try_get_data()

File "/home/zhrui/.local/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 774, in _try_get_data

raise RuntimeError('DataLoader worker (pid(s) {}) exited unexpectedly'.format(pids_str))

RuntimeError: DataLoader worker (pid(s) 62005) exited unexpectedly

[Thread 0x7fff78893700 (LWP 62009) exited]

[Thread 0x7fff74092700 (LWP 62008) exited]

[Thread 0x7fff71891700 (LWP 62007) exited]

[Thread 0x7fff6f090700 (LWP 62006) exited]

[Inferior 1 (process 61952) exited with code 01]

(gdb) backtrace

No stack.

그리고 충분한 공유 메모리가 있다고 생각합니다. 적어도 segfault까지 꽤 오랜 시간 동안 공유 메모리가 충분할 것으로 예상하지만 데이터 로더 작업을 시작한 직후에 세그먼트 오류가 발생합니다.

------ Messages Limits --------

max queues system wide = 32000

max size of message (bytes) = 8192

default max size of queue (bytes) = 16384

------ Shared Memory Limits --------

max number of segments = 4096

max seg size (kbytes) = 18014398509465599

max total shared memory (kbytes) = 18014398509481980

min seg size (bytes) = 1

------ Semaphore Limits --------

max number of arrays = 32000

max semaphores per array = 32000

max semaphores system wide = 1024000000

max ops per semop call = 500

semaphore max value = 32767

안녕하세요 @soumith @apaszke , 이 문제를 다시 열 수 있습니까 ? shm 크기 및 세그먼트를 늘리는 것과 같은 제안된 모든 솔루션을 시도했지만 아무 것도 작동하지 않습니다. 저는 opencv 정도를 사용하지 않고 단순한 JSON 구문 분석을 사용하고 있습니다. 그러나 여전히 문제가 있습니다. 모든 메모리를 공유 메모리로 여는 것을 확인했기 때문에 shm과 관련이 있다고 생각하지 않습니다. 스택 추적은 또한 위에 게시된 것처럼 아무 것도 표시하지 않습니다.

@apaszke , 귀하의 제안에 대해

"예, 이러한 문제의 대부분은 타사 라이브러리가 포크로부터 안전하지 않기 때문에 발생합니다. 한 가지 대안은 생성 시작 방법을 사용하는 것일 수 있습니다."

데이터 로더 다중 작업자를 사용하고 있습니다. 방법을 변경하려면 어떻게 해야 합니까? set_start_method('spawn') 를 main.py에 설정하고 있지만 도움이 되지 않는 것 같습니다.

또한 다중 작업자(다중 프로세스) 데이터 로더를 활성화하고 기본 교육에서 https://pytorch.org/docs/stable/notes/multiprocessing.html 에서 제안한 대로 다중 프로세스를 시작하는 경우 여기에 일반적인 질문이 있습니다.

pytorch는 데이터 로더와 기본 교육 다중 프로세스를 어떻게 관리합니까? 멀티 코어 GPU에서 가능한 모든 프로세스/스레딩을 공유합니까? 또한 다중 프로세스를 위한 공유 메모리는 데이터 로더와 메인 트레이닝 프로세스에 의해 "공유"됩니까? JSON 구문 분석, CSV 구문 분석, 팬더 기능 추출과 같은 일부 데이터 요리 작업이 있는 경우에도 마찬가지입니다. 등, 어디에 넣는 것이 가장 좋은가? 데이터 로더에서 데이터 로더 __get_item__ 를 가능한 한 간단하게 유지하기 위해 위에서 제안한 대로 데이터 로더에서 완벽하게 준비된 데이터를 생성하거나 기본 교육을 사용하여 그렇게 하십시오.

@zhangruiskyline 귀하의 문제는 실제로 교착 상태가 아닙니다. 그것은 segfault에 의해 노동자들이 살해당하는 것에 관한 것입니다. sigbus는 shm 문제를 제안하는 것입니다. 데이터세트 코드를 확인하고 거기에서 디버그해야 합니다.

다른 질문에 답하려면

1. DataLoader에서 kwarg multiproessing_context='spawn' 를 사용하면 스폰이 설정됩니다. set_start_method 도 마찬가지입니다.
2. 일반적으로 다중 프로세스 교육에서 각 프로세스에는 고유한 DataLoader가 있으므로 DataLoader 작업자가 있습니다. 명시적으로 수행되지 않는 한 프로세스 간에는 아무 것도 공유되지 않습니다.

@SsnL 감사 multiproessing_context='spawn' 했지만 동일한 실패입니다.

이전 스레드에서 지적했지만 내 코드는 매우 간단합니다.

• 이 코드 조각은 작동합니다

        with open(current_file, mode='rb') as f:
            text = f.read().decode('utf-8')
            all_data.extend(text.split('\n'))

• 하지만 한 줄씩 읽은 후 JSON 구문 분석 논리를 추가하면 이 오류가 보고됩니다.

with open(current_file, mode='rb') as f:
            text = f.read().decode('utf-8')
            all_data.extend(text.split('\n'))

        json_data = []
        for line in all_data:
            try:
                json_data.append(json.loads(line))
            except:
                break
return json_data

그래서 나는 그것이 내 코드 문제인지 의심스럽고 JSON 구문 분석을 사용하지 않고 직접 문자열 분할, 동일한 문제를 시도합니다. 데이터 로더에서 데이터 처리에 시간이 걸리는 논리가 있는 한 이 문제가 발생하는 것 같습니다.

또한

다중 프로세스 교육, 각 프로세스에는 고유한 DataLoader가 있으므로 DataLoader 작업자 명시적으로 수행되지 않는 한 프로세스 간에 공유되지 않습니다.

그럼 각각 8개의 작업자 데이터 로더가 있는 4개의 교육 프로세스가 있는지 보겠습니다. 아래에 총 32개의 프로세스가 있습니까?

@zhangruiskyline 문제를 재현하는 자체 포함된 스크립트가 없으면 우리는 당신을 도울 수 없습니다. 예, 32개의 프로세스가 있을 것입니다.

고마워, 나는 또한 비슷한 문제를 보았다
https://github.com/pytorch/pytorch/issues/4969
https://github.com/pytorch/pytorch/issues/5040

둘 다 닫혔지만 명확한 해결책이나 수정 사항이 보이지 않습니다. 이것이 여전히 광범위한 기존 문제입니까?

자체 포함된 재생성 스크립트를 제공할 수 있는지 여부를 확인하지만 이 스크립트는 당사 플랫폼 및 데이터 소스에 고도로 통합되어 있으므로 시도할 것입니다.

@zhangruiskyline 당신이 읽은 문제는 연결된 문제와 유사하지 않습니다. 해당 스레드에 대해 보고된 원래/가장 일반적인 문제가 이미 해결되었기 때문에 닫힙니다.

@SsnL 감사 Pytorch 에 익숙하지 않아서 틀릴 수 있지만, 그 모든 것을 살펴보았고, 그 중 일부는 다음으로 해결된 것 같습니다.

• 작업자 수를 0으로 줄이십시오. 너무 느리기 때문에 허용되지 않습니다.

• shm 크기를 늘리지 만 충분한 shm이 있다고 생각합니다. 문제는 시작한 직후에 거의 발생했으며 훨씬 작은 데이터 세트로 시도한 문제는 동일합니다.

• opencv와 같은 일부 lib는 다중 프로세스에서 잘 작동하지 않습니다. 우리는 JSON/CSV를 사용하고 있으므로 실제로 멋진 것은 아닙니다.

우리의 코드는 매우 간단하고 훈련 데이터 세트에는 10000개 이상의 파일이 있으며 각 파일은 여러 줄의 JSON 문자열입니다. 데이터 로더에서 __get_item__ 를 정의하여 10,000개 이상의 파일에서 각 파일을 가져오고 해당 파일의 모든 콘텐츠를 읽습니다.

솔루션 1에서 먼저 행별로 JSON 문자열 목록을 읽고 분할합니다. 즉시 반환하면 작동하며 성능이 좋습니다.

        with open(current_file, mode='rb') as f:
            text = f.read().decode('utf-8')
            all_data.extend(text.split('\n'))
            return all_data

이제 반환된 값이 여전히 JSON 문자열이므로 속도를 높이기 위해 다중 프로세스 데이터 로더를 활용하려고 하므로 여기에 JSON 구문 분석 논리를 넣으면 실패합니다.

with open(current_file, mode='rb') as f:
            text = f.read().decode('utf-8')
            all_data.extend(text.split('\n'))

        json_data = []
        for line in all_data:
            try:
                json_data.append(json.loads(line))
            except:
                break
return json_data

우리는 나중에 JSON 구문 분석이 너무 무겁고 JSON에 메모리 사용량이 너무 많다고 생각한 다음 JSON 문자열을 구문 분석하고 수동으로 기능 목록으로 변환하기로 선택했지만 동일한 실패입니다. 일부 스택 추적 분석을 수행했지만 거기에는 아무것도 없었습니다.

BTW, 우리는 Linux Docker Env, 24코어 CPU 및 1 V100에서 코드를 실행하고 있습니다.

다음에는 어디에서 조사를 시작해야 할지 모르겠습니다. 당신은 어떤 생각이 있습니까?

안녕,

https://github.com/open-mmlab/mmdetection 에서 사용되는 https://github.com/open-mmlab/mmcv 에서 흥미로운 의견을 찾았습니다.

다음 코드는 train epoch와 val epoch의 시작 부분에 사용됩니다.
time.sleep(2) # Epoch 전환 동안 가능한 교착 상태 방지

https://github.com/open-mmlab/mmcv/blob/1cb3e36a1ea33caf272d2365c7d406123122b8d0/mmcv/runner/epoch_based_runner.py#L26

당신이 그것을 시도 할 수 있습니다.

BTW, 다중 작업자 데이터 로더가 있는 각 프로세스 및 다중 프로세스로 이동하면 해당 데이터 로더가 다른 프로세스의 데이터 로더와 동일한 데이터를 읽지 않도록 하는 프로세스가 어떻게 다른가요? ti는 이미 pytorch 데이터 로더 __get_item__ 의해 처리됩니까?

안녕하세요 @SsnL , 도와주셔서 감사합니다. 이 스레드에 대한 후속 조치를 취하고 싶습니다. pytorch 다중 처리를 사용하여 교육 코드를 리팩터링하여 CPU 측에서 일부 데이터 처리 속도를 높입니다(GPU에 더 빨리 공급하기 위해), https://pytorch.org/docs/stable /notes/multiprocessing.html#multiprocessing -모범 사례

또한 각 처리 기능에서 다중 작업자 데이터 로더를 사용하여 데이터 로딩 처리 시간을 단축합니다. https://pytorch.org/docs/stable/data.html

나는 데이터 로더가 아닌 메인 트레이닝 과정에서 내 heaving CPU JSON 구문 분석을 넣었고 문제가 사라진 것처럼 보입니다. 이유는 모르겠지만 어쨌든 작동하는 것 같습니다. 그러나 후속 질문이 있습니다. N 처리가 있다고 가정하고 각각에는 M 로더 작업자가 있으므로 스레딩 아래에 총 NxM 가 있습니다.

내 데이터 로더에서 모든 데이터를 인덱스 방식으로 가져오려면 N개의 다른 처리에서 M 데이터 로더에서 __get_item__(self, idx) 가 다른 인덱스를 처리하기 위해 함께 작동할 수 있습니다. 중복 또는 일부 프로세스를 그리워?

새로운 훈련 또는 검증 에포크의 시작 부분에서 메모리를 할당할 수 없다고 불평한 후 데이터 로더가 충돌하는 동일한 문제가 있었습니다. 위의 솔루션은 (i) /dev/shm 가 32GB이고 2.5GB 이상 사용된 적이 없으며 (ii) pin_memory=False 설정이 작동하지 않았습니다.

이것은 아마도 가비지 수집과 관련이 있습니까? 내 코드는 대략 다음과 같습니다. 무한 반복자가 필요하므로 아래 next() 주위를 제외하고 시도합니다 :-)

def train():
    train_iter = train_loader.__iter__()
    for i in xrange(max_batches):
        try:
            x, y = next(train_iter)
        except StopIteration:
            train_iter = train_loader.__iter__()
        ...
    del train_iter

train_loader 는 DataLoader 개체입니다. 함수 끝에 명시적인 del train_iter 줄이 없으면 프로세스는 항상 2-3 에포크 후에 충돌합니다( /dev/shm 여전히 2.5GB를 표시함). 도움이 되었기를 바랍니다!

4 작업자(Ubuntu 16.04의 CUDA 8.0 버전 0.1.12_2 )를 사용하고 있습니다.

이것은 몇 주 동안 고군분투 한 후 문제를 해결했습니다. 로더를 직접 반복하는 대신 로더 반복자를 명시적으로 사용해야 하며 에포크가 끝날 때 del loader_iterator 를 사용하여 마침내 교착 상태를 제거했습니다.

나는 같은 문제에 직면하고 있다고 생각합니다. 8개의 데이터 로더(MNIST, MNISTM, SVHN, USPS, 각각 학습 및 테스트용)를 사용하려고 합니다. 6(모든 6)을 사용하면 잘 작동합니다. 8을 사용하면 6번째 MNIST-M 테스트를 로드할 때 항상 차단됩니다. 이미지 검색을 시도하고, 실패하고, 조금 기다렸다가 다시 시도하는 끝없는 루프에 갇혀 있습니다. 모든 batch_size에 대해 오류가 지속되고 사용 가능한 메모리가 많이 남아 있으며 num_workers를 0으로 설정한 경우에만 사라집니다. 다른 양이 문제의 원인입니다.

https://stackoverflow.com/questions/54013846/pytorch-dataloader-stucked-if-using-opencv-resize-method 에서 힌트를 얻었습니다.
cv2.setNumThreads(0) 넣으면 잘 작동합니다.

안녕하세요, 나는 같은 문제가있었습니다. 그리고 그것은 ulimit -n과 관련이 있었고 단순히 늘리면 문제가 해결되었습니다. 나는 ulimit -n 500000을 사용했습니다.

@SebastienEske ulimit -n Ubuntu 20.04에서도 이 문제를 해결했습니다.

아마도 set ulimit -n 이 올바른 방법일 것입니다. 모델이 증가함에 따라 교착 상태가 점점 더 자주 발생하고 cv2.setNumThreads(0) 테스트도 수행하지만 작동하지 않습니다.

기록을 위해 cv2.setNumThreads(0) 가 저에게 효과적이었습니다.