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 मेम: 65863816 कुल, 60115084 प्रयुक्त, 5748732 मुफ़्त, 1372688 बफ़र्स
KiB स्वैप: 5917692 कुल, 620 प्रयुक्त, 5917072 निःशुल्क। 51154784 कैश्ड मेमो

पीआईडी ​​यूजर पीआर एनआई वर्ट रेस एसएचआर एस% सीपीयू% मेम टाइम+ कमांड 3067 आलरेजा 20 0 143332 101816 21300 आर 46.1 0.2 1631:44 Xvnc
16613 आलरेजा 30 10 32836 4880 3912 एस 16.9 0.0 1:06.92 फाइबरलैम्प 3221 अलरेजा 20 0 8882348 1.017g 110120 एस 1.3 1.6 579:06.87 MATLAB
1285 रूट 20 0 1404848 48252 25580 S 0.3 0.1 6:00.12 dockerd 16597 yimengz+ 20 0 25084 3252 2572 R 0.3 0.0 0:04.56 शीर्ष
1 रूट 20 0 33616 4008 2624 एस 0.0 0.0 0:01.43 init
~~~

free का आउटपुट

~yimengzh_everyday@yimengzh :~$ freeकुल उपयोग किए गए मुफ्त साझा बफर कैश किए गएमेम: 65863816 60122060 5741756 9954628 1372688 51154916-/+ बफ़र्स/कैश: 7594456 58269360स्वैप: 5917692 620 5917072~

nvidia-smi का आउटपुट

~~~
yimengzh_everyday@yimengzh :~$ nvidia-smi
मंगल अप्रैल 25 17:52:38 2017
+-------------------------------------------------------- -----------------------------+
| NVIDIA-SMI 375.39 ड्राइवर संस्करण: 375.39 |
|------------------------------------------+----------------- -----+---------------------+
| GPU नाम पर्सिस्टेंस-एम| बस-आईडी डिस्प.ए | अस्थिर ईसीसी |
| फैन टेम्प परफ पीआर: उपयोग/कैप | मेमोरी-उपयोग | जीपीयू-यूटिल कंप्यूट एम. |
|=============================================================================================================================================================== =====+======================|
| 0 GeForce GTX TIT... ऑफ | 0000:03:00.0 ऑफ | एन/ए |
| 30% 42C P8 14W / 250W | 3986MiB / 6082MiB | 0% डिफ़ॉल्ट |
+---------------------------------------------------------------------- -----+---------------------+
| 1 टेस्ला K40c ऑफ | 0000:81: 00.0 बंद | बंद |
| 0% 46C P0 57W / 235W | 0MiB / 12205MiB | 0% डिफ़ॉल्ट |
+---------------------------------------------------------------------- -----+---------------------+

+-------------------------------------------------------- -----------------------------+
| प्रक्रियाएं: जीपीयू मेमोरी |
| GPU PID प्रकार प्रक्रिया का नाम उपयोग |
|============================================ ============================|
| 0 16509 सी अजगर 3970MiB |
+-------------------------------------------------------- -----------------------------+
~~~

मुझे नहीं लगता कि यह एक स्मृति मुद्दा है।

साझा स्मृति के लिए अलग सीमाएँ हैं। क्या आप ipcs -lm या cat /proc/sys/kernel/shmall और cat /proc/sys/kernel/shmmax आज़मा सकते हैं? साथ ही, यदि आप कम श्रमिकों का उपयोग करते हैं (उदाहरण के लिए 1 कार्यकर्ता के चरम मामले के साथ परीक्षण) तो क्या यह गतिरोध करता है?

@apaszke

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

------ साझा स्मृति सीमा --------
खंडों की अधिकतम संख्या = 4096
अधिकतम seg आकार (kbytes) = 18014398509465599
अधिकतम कुल साझा स्मृति (kbytes) = 18446744073642442748
न्यूनतम सेग आकार (बाइट्स) = 1

yimengzh_everyday@yimengzh :~$ cat /proc/sys/kernel/shmall
18446744073692774399
yimengzh_everyday@yimengzh :~$ cat /proc/sys/kernel/shmmax
1844674407369274399
~~~

वे आपको कैसे ढूंढते हैं?

जहां तक ​​कम कर्मचारियों का सवाल है, मेरा मानना ​​है कि ऐसा अक्सर नहीं होगा। (मैं अभी कोशिश कर सकता हूँ)। लेकिन मुझे लगता है कि व्यवहार में मुझे इतने कार्यकर्ताओं की जरूरत है।

आपके पास अधिकतम 4096 साझा मेमोरी सेगमेंट की अनुमति है, शायद यह एक समस्या है। आप इसे बढ़ाकर /proc/sys/kernel/shmmni करने का प्रयास कर सकते हैं (शायद 8192 का प्रयास करें)। आपको सुपरयुसर विशेषाधिकारों की आवश्यकता हो सकती है।

@apaszke अच्छी तरह से ये Ubuntu और CentOS 6 दोनों द्वारा डिफ़ॉल्ट मान हैं ... क्या यह वास्तव में एक मुद्दा है?

@apaszke प्रशिक्षण कार्यक्रम ipcs -a वास्तव में कोई साझा स्मृति का उपयोग नहीं किया जा रहा है। क्या यह अपेक्षित है?

@apaszke ने साझा मेम पर निम्नलिखित सेटिंग के साथ कार्यक्रम (अभी भी 22 कार्यकर्ता) चलाने की कोशिश की, और फिर से अटक गया।

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

------ साझा स्मृति सीमा --------
खंडों की अधिकतम संख्या = 8192
अधिकतम seg आकार (kbytes) = 18014398509465599
अधिकतम कुल साझा स्मृति (kbytes) = 18446744073642442748
न्यूनतम सेग आकार (बाइट्स) = 1
~~~

एक कार्यकर्ता की कोशिश नहीं की। पहला, वह धीमा होगा; दूसरा, अगर समस्या वास्तव में डेड लॉकिंग है, तो यह निश्चित रूप से गायब हो जाएगी।

@ zym1010 डिफ़ॉल्ट सेटिंग्स को इस तरह के वर्कलोड को ध्यान में रखते हुए बनाने की ज़रूरत नहीं है, इसलिए हाँ यह एक समस्या हो सकती है। ipcs सिस्टम 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 । मैंने कोड बिल्कुल संशोधित नहीं किया।

मैंने पायथॉन 3.5 पर पाइप के माध्यम से पाइटोरच स्थापित किया। पाइटोरच संस्करण 0.1.11_5 । डॉकर में नहीं चल रहा है।

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 ज़ोंबीसीपीयू (ओं): 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 क्या आपने पहले कंप्यूटर को रिबूट करने और फिर प्रोग्राम चलाने की कोशिश की है? मेरे लिए, यह ठंड की गारंटी देता है। मैंने अभी 0.12 संस्करण की कोशिश की है, और यह अभी भी वही है।

एक बात जो मैं इंगित करना चाहता हूं वह यह है कि मैंने pip का उपयोग करके पाइटोरच स्थापित किया, क्योंकि मेरे पास ओपनबीएलएएस-लिंक्ड numpy स्थापित है और एमकेएल @soumith के एनाकोंडा क्लाउड से इसके साथ अच्छी तरह से नहीं खेलेंगे।

तो अनिवार्य रूप से pytorch MKL का उपयोग कर रहा है और numpy OpenBLAS का उपयोग कर रहा है। यह आदर्श नहीं हो सकता है, लेकिन मुझे लगता है कि इसका यहां के मुद्दे से कोई लेना-देना नहीं होना चाहिए।

मैंने इसे देखा, लेकिन मैं इसे कभी भी पुन: पेश नहीं कर सका। एमकेएल/ओपनबीएलएएस इस समस्या से असंबंधित होना चाहिए। यह शायद सिस्टम कॉन्फ़िगरेशन के साथ कुछ समस्या है

@apaszke धन्यवाद। मैंने अभी एनाकोंडा आधिकारिक रेपो और एमकेएल आधारित पाइटोरच से अजगर की कोशिश की। अभी भी वही समस्या।

डॉकर में कोड चलाने की कोशिश की। अभी भी अटक।

हमारे पास एक ही समस्या है, 4 में से 1 GPU का उपयोग करके एक nvidia-docker के अंदर पाइटोरच/उदाहरण इमेजनेट प्रशिक्षण उदाहरण (resnet18, 4 कार्यकर्ता) चलाना। अगर मैं प्रक्रिया में आने का प्रबंधन करता हूं तो मैं एक जीडीबी बैकट्रैक इकट्ठा करने का प्रयास करूंगा .

कम से कम OpenBLAS को मैट्रिक्स गुणन में एक गतिरोध समस्या के लिए जाना जाता है, जो अपेक्षाकृत कम ही होता है: https://github.com/xianyi/OpenBLAS/issues/937। यह बग कम से कम 1.12.0 numpy में पैक किए गए OpenBLAS में मौजूद था।

@jsainio मैंने शुद्ध MKL आधारित PyTorch की भी कोशिश की (numpy MKL के साथ भी जुड़ा हुआ है), और वही समस्या।

साथ ही, यह समस्या हल हो गई है (कम से कम मेरे लिए), अगर मैं डेटालोडर के लिए pin_memory बारी करता हूं।

ऐसा लग रहा है मानो दो मजदूरों की मौत हो गई हो।

सामान्य ऑपरेशन के दौरान:

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

एक अभी भी शेष श्रमिकों के लिए, जीडीबी स्टैकट्रेस की शुरुआत इस तरह दिखती है:

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()
मेरे लिए समस्या यह थी कि मैंने ओपनसीवी को इमेज लोडर के रूप में इस्तेमाल किया। और cv2.imread फ़ंक्शन इमेजनेट की एक विशेष छवि ("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 , मैं कभी-कभी पहली युग ट्रेन प्राप्त कर सकता हूं और पूरी तरह से मान्य कर सकता हूं, और यह दूसरे युग के बीच में बंद हो जाता है। इसलिए, यह डेटासेट/लोडिंग फ़ंक्शन में कोई समस्या होने की संभावना नहीं है।

यह ImageLoader में दौड़ की स्थिति जैसा कुछ दिखता है जिसे एक निश्चित हार्डवेयर/सॉफ़्टवेयर संयोजन द्वारा अपेक्षाकृत दुर्लभ रूप से ट्रिगर किया जा सकता है।

@ zym1010 सूचक के लिए धन्यवाद, मैं pin_memory = False सेट करने का प्रयास करूंगा।

दिलचस्प। मेरे सेटअप पर, pin_memory = False और num_workers = 4 को सेट करने पर इमेजनेट उदाहरण लगभग तुरंत ही लटक जाता है और तीन कार्यकर्ता ज़ोंबी प्रक्रियाओं के रूप में समाप्त हो जाते हैं:

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

मैं क्लस्टर के कंप्यूट नोड पर एक स्थानीय एसएसडी का उपयोग कर रहा हूं। कोड एक एनएफएस ड्राइव पर है, लेकिन अधिकतम लोडिंग गति के लिए डेटा स्थानीय एसएसडी पर है। NFS ड्राइव पर डेटा लोड करने का कभी प्रयास नहीं किया।

@ zym1010 जानकारी के लिए धन्यवाद। मैं इसे क्लस्टर के कंप्यूट नोड पर भी चला रहा हूं।

वास्तव में, मैं num_workers = 0 प्रयोग एक ही समय में एक ही नोड पर चला रहा हूं, जबकि num_workers = 4 विविधताओं को आजमा रहा हूं। हो सकता है कि पहला प्रयोग पर्याप्त भार उत्पन्न कर रहा हो ताकि संभावित दौड़ की स्थिति बाद में खुद को तेजी से प्रकट कर सके।

@apaszke जब आपने इसे पहले पुन: पेश करने का प्रयास किया था, तो क्या आपने दो उदाहरणों को साथ-साथ चलाने या सिस्टम पर कुछ महत्वपूर्ण अन्य लोड के साथ चलाने का प्रयास किया था?

@jsainio इसकी जांच के लिए धन्यवाद! यह अजीब है, श्रमिकों को केवल एक साथ बाहर निकलना चाहिए, और एक बार मुख्य प्रक्रिया डेटा पढ़ने के बाद। क्या आप यह निरीक्षण करने का प्रयास कर सकते हैं कि वे समय से पहले क्यों निकल जाते हैं? शायद कर्नेल लॉग ( dmesg ) जांचें?

नहीं, मैंने यह कोशिश नहीं की है, लेकिन ऐसा तब भी प्रतीत होता है जब ऐसा नहीं था IIRC

@apaszke ठीक है, यह जानकर अच्छा लगा कि श्रमिकों को बाहर नहीं जाना चाहिए था।

मैंने कोशिश की है लेकिन मुझे यह जांचने का एक अच्छा तरीका नहीं पता कि वे बाहर क्यों निकलते हैं। dmesg प्रासंगिक कुछ भी नहीं दिखाता है। (मैं एनाकोंडा पैकेज का उपयोग करके उबंटू 16.04-व्युत्पन्न डॉकर में चल रहा हूं)

एक तरीका यह होगा कि वर्कर लूप के अंदर कई प्रिंटों को जोड़ा जाए। मुझे नहीं पता कि वे चुपचाप बाहर क्यों निकल जाते हैं। यह शायद एक अपवाद नहीं है, क्योंकि इसे stderr पर मुद्रित किया गया होगा, इसलिए वे या तो लूप से बाहर हो जाते हैं, या ओएस द्वारा मारे जाते हैं (शायद सिग्नल द्वारा?)

@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

वह उपयोग बल्कि उच्च कठिन लगता है। यह दो ज़ोंबी श्रमिकों के साथ एक डॉकटर पर है।

क्या आप शम आकार बढ़ाने का प्रयास कर सकते हैं? मैंने अभी जाँच की और सर्वर पर जहाँ मैंने समस्याओं को पुन: उत्पन्न करने का प्रयास किया वह 16GB था। आप या तो डॉकर ध्वज को बदलते हैं या दौड़ते हैं

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

मैंने आकार को 512MB तक कम करने की कोशिश की, लेकिन मुझे गतिरोध के बजाय एक स्पष्ट त्रुटि मिली। अभी भी पुन: पेश नहीं कर सकता 😕

डॉकटर के साथ हम गतिरोध प्राप्त करते हैं जब shm पर्याप्त नहीं होता है, बजाय स्पष्ट त्रुटि संदेशों के, पता नहीं क्यों। लेकिन यह आमतौर पर शम को बढ़ाकर ठीक किया जाता है (और मुझे 1 जी के साथ गतिरोध मिला)।

ठीक है, ऐसा लगता है कि 10 श्रमिकों के साथ एक त्रुटि उठाई गई है, लेकिन जब मैं 4 श्रमिकों का उपयोग करता हूं तो मुझे 58%/dev/shm उपयोग पर गतिरोध मिलता है! मैंने अंत में इसे पुन: पेश किया

यह बहुत अच्छा है कि आप इस समस्या का एक रूप पुन: पेश कर सकते हैं। मैंने एक स्क्रिप्ट पोस्ट की जो #1579 में हैंग को ट्रिगर करती है, और आपने उत्तर दिया कि यह आपके सिस्टम पर हैंग नहीं हुई। मैंने वास्तव में केवल अपने मैकबुक पर इसका परीक्षण किया था। मैंने अभी लिनक्स पर कोशिश की है, और यह लटका नहीं है। इसलिए यदि आपने केवल लिनक्स पर कोशिश की है, तो यह मैक पर भी कोशिश करने लायक हो सकता है।

ठीक है, तो समस्या की जांच के बाद यह एक अजीब मुद्दा लगता है। यहां तक ​​​​कि जब मैं /dev/shm को केवल 128MB बड़ा करने के लिए सीमित करता हूं, तो लिनक्स हमें वहां 147MB फाइलें बनाने की अनुमति देता है, उन्हें पूरी तरह से मेमोरी में mmap करता है, लेकिन एक बार जब यह वास्तव में पृष्ठों तक पहुंचने का प्रयास करता है, तो कार्यकर्ता को एक घातक SIGBUS भेज देगा। ... मैं किसी भी तंत्र के बारे में नहीं सोच सकता जो हमें उन पर पुनरावृति के अलावा पृष्ठों की वैधता की जांच करने की अनुमति देगा, और हर एक को छूने के साथ, एक SIGBUS हैंडलर पंजीकृत है ...

जैसा कि मैंने ऊपर दिखाया है, अभी के लिए एक समाधान /dev/shm को mount कमांड के साथ विस्तारित करना है। 16GB के साथ प्रयास करें (यदि आपके पास पर्याप्त RAM है तो ofc)।

इसका कोई उल्लेख मिलना मुश्किल है, लेकिन यहां एक है ।

इस मुद्दे के बारे में आपके समय के लिए धन्यवाद, यह मुझे लंबे समय से पागल कर रहा है! अगर मैं सही ढंग से समझूं तो मुझे /dev/shm को 8G के बजाय 16G तक विस्तारित करने की आवश्यकता है। यह समझ में आता है लेकिन जब कोशिश में df -h , मैं देख सकता हूं कि मेरे सभी राम वास्तव में इस तरह आवंटित किए गए हैं: (मेरे पास 16 जी है)

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 का विस्तार करने में कोई समस्या नहीं होनी चाहिए, है ना?

इससे भी महत्वपूर्ण बात यह है कि मैं cgroup विभाजन और उसके उद्देश्य के बारे में हैरान हूँ क्योंकि यह मेरी RAM का लगभग आधा हिस्सा लेता है। जाहिरा तौर पर इसे कुशलतापूर्वक बहु-प्रोसेसर कार्यों को प्रबंधित करने के लिए डिज़ाइन किया गया है, लेकिन मैं वास्तव में इससे परिचित नहीं हूं कि यह क्या करता है और हमें इसकी आवश्यकता क्यों है, क्या यह सभी भौतिक रैम को शम को आवंटित करने के लिए कुछ बदल देगा (क्योंकि हमने इसका आकार 16 जी पर सेट किया है) और इसे SWAP में डालें (हालाँकि मेरा मानना ​​है कि दोनों आंशिक रूप से RAM और SWAP में एक साथ होंगे)

@apaszke धन्यवाद! बढ़िया है कि आपको अंतर्निहित कारण मिल गया। मुझे कभी-कभी डॉकटर --shm-size=1024m साथ विभिन्न "कनेक्शन रीसेट" त्रुटियां और डेडलॉक्स दोनों मिल रहे थे, इस पर निर्भर करता है कि मशीन में कौन सा लोड था। --shm-size=16384m और 4 कर्मचारियों के साथ अभी परीक्षण किया जा रहा है।

@jsainio ConnectionReset एक ही चीज़ के कारण हो सकता है। प्रक्रियाओं ने कुछ डेटा का आदान-प्रदान करना शुरू कर दिया, लेकिन एक बार जब शम अंतरिक्ष से बाहर हो गया तो कार्यकर्ता को एक सिगबस भेजा गया और उसे मार दिया गया।

@ClementPinard जहां तक ​​​​मैं समझता हूं कि आप इसे जितना चाहें उतना बड़ा बना सकते हैं, सिवाय इसके कि जब आप रैम से बाहर हो जाएंगे तो यह आपकी मशीन को फ्रीज कर देगा (क्योंकि कर्नेल भी इस मेमोरी को मुक्त नहीं कर सकता है)। आपको शायद /sys/fs/cgroup बारे में परेशान होने की आवश्यकता नहीं है। tmpfs विभाजन स्मृति को आलसी रूप से आवंटित करते हैं, इसलिए जब तक उपयोग 0B पर रहता है, यह आपको कुछ भी खर्च नहीं करता है (सीमा सहित)। मुझे नहीं लगता कि स्वैप का उपयोग करना एक अच्छा विचार है, क्योंकि यह डेटा लोडिंग को धीमा कर देगा, इसलिए आप shm आकार को 12GB कहने के लिए बढ़ाने का प्रयास कर सकते हैं, और श्रमिकों की संख्या को सीमित कर सकते हैं (जैसा कि मैंने कहा, शम के लिए अपनी सारी रैम का प्रयोग न करें!) यहाँ कर्नेल प्रलेखन से

मुझे नहीं पता कि /dev/shm उपयोग बहुत छोटा होने पर भी गतिरोध क्यों होता है (मेरी मशीन पर 20kB पर होता है)। शायद कर्नेल अत्यधिक आशावादी है, लेकिन जब तक आप इसे भर नहीं देते हैं, तब तक प्रतीक्षा नहीं करता है, और इस क्षेत्र से किसी भी चीज़ का उपयोग शुरू करने के बाद प्रक्रिया को मार देता है।

अब मेरे पास 12जी और आधे कर्मचारियों के साथ परीक्षण, और यह विफल रहा :(
यह लुआ मशाल संस्करण (समान गति, समान श्रमिकों की संख्या) में एक आकर्षण की तरह काम कर रहा था, जो मुझे आश्चर्यचकित करता है कि क्या समस्या केवल /dev/shm संबंधित है और पाइथन मल्टीप्रोसेसिंग के करीब नहीं है ...

इसके बारे में अजीब बात (जैसा कि आपने उल्लेख किया है) यह है कि /dev/shm कभी भी पूर्ण होने के करीब नहीं है। पहले प्रशिक्षण युग के दौरान, यह कभी भी 500Mo से ऊपर नहीं गया। और यह पहले युग के दौरान कभी भी लॉक नहीं होता है, और अगर मैं परीक्षण ट्रेन लोडर को बंद कर देता हूं तो सभी युगों में कभी भी विफल नहीं होता है। परीक्षण युग की शुरुआत करते समय गतिरोध केवल प्रकट होता है। ट्रेन से परीक्षण के लिए जाने पर मुझे /dev/shm का ट्रैक रखना चाहिए, हो सकता है कि डेटालोडर बदलने के दौरान चरम उपयोग हो।

@ClementPinard उच्च साझा मेमोरी के साथ भी, और डॉकर के बिना, यह अभी भी विफल हो सकता है।

यदि मशाल संस्करण == लुआ मशाल, तो यह अभी भी /dev/shm से संबंधित हो सकता है। लुआ मशाल धागे का उपयोग कर सकता है (कोई जीआईएल नहीं है), इसलिए इसे साझा मेम के माध्यम से जाने की आवश्यकता नहीं है (वे सभी एक ही पता स्थान साझा करते हैं)।

मेरे पास एक ही मुद्दा था जहां शिकायत करने के बाद डेटालोडर दुर्घटनाग्रस्त हो जाता है कि यह एक नए प्रशिक्षण या सत्यापन युग की शुरुआत में स्मृति आवंटित नहीं कर सका। ऊपर दिए गए समाधान मेरे लिए काम नहीं करते थे (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.5 जीबी दिखाता है)। उम्मीद है की यह मदद करेगा!

मैं 4 श्रमिकों का उपयोग कर रहा हूं (संस्करण 0.1.12_2 Ubuntu 16.04 पर CUDA 8.0 के साथ)।

मैं गतिरोध से भी मिला, खासकर जब वर्क_नंबर बड़ा हो। क्या इस समस्या का कोई संभावित समाधान है? मेरा /dev/shm आकार 32GB है, cuda 7.5, pytorch 0.1.12 और अजगर 2.7.13 के साथ। मृत्यु के बाद संबंधित जानकारी निम्नलिखित है। यह स्मृति से संबंधित लगता है। @apaszke

@zhengyunqq कोशिश करें pin_memory=False अगर आप इसे True सेट करते हैं। अन्यथा, मुझे किसी समाधान की जानकारी नहीं है।

num_workers बड़े होने पर मैं गतिरोध से भी मिला हूं।

मेरे लिए, समस्या यह थी कि यदि किसी कारण से एक कार्यकर्ता धागा मर जाता है, तो index_queue.put हमेशा के लिए लटक जाता है। वर्किंग थ्रेड्स के मरने का एक कारण इनिशियलाइज़ेशन के दौरान अनपिकलर फेल होना है। उस स्थिति में, मई 2017 में मास्टर में इस पायथन बगफिक्स तक, कार्यकर्ता धागा मर जाएगा और अंतहीन हैंग का कारण बनेगा। मेरे मामले में, बैच प्री-फ़ेचिंग प्राइमिंग चरण में हैंग हो रहा था।

हो सकता है कि SimpleQueue उपयोग DataLoaderIter में Queue जो एक सुंदर अपवाद संदेश के साथ टाइमआउट की अनुमति देता है।

UPD: मुझसे गलती हुई थी, यह बगफिक्स पैच Queue , न कि SimpleQueue । यह अभी भी सच है कि यदि कोई वर्कर थ्रेड ऑनलाइन नहीं है तो SimpleQueue लॉक हो जाएगा। यह जांचने का एक आसान तरीका है कि इन पंक्तियों को self.workers = [] ।

मुझे एक ही समस्या है, और मैं शम (अनुमति के बिना) नहीं बदल सकता, शायद कतार या कुछ और का उपयोग करना बेहतर है?

मुझे एक ऐसी ही समस्या है।
यह कोड फ्रीज हो जाएगा और कभी भी कुछ भी प्रिंट नहीं होगा। अगर मैं 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()

क्या किसी के पास उस समस्या का समाधान है?

मैंने इमेजनेट को प्रशिक्षित करते समय भी इसी तरह के मुद्दों में भाग लिया है। यह कुछ आर्किटेक्चर के साथ कुछ सर्वरों पर लगातार मूल्यांकन के पहले पुनरावृत्ति पर लटका रहेगा (और समान आर्किटेक्चर वाले अन्य सर्वरों या विभिन्न आर्किटेक्चर वाले एक ही सर्वर पर नहीं), लेकिन सत्यापन पर eval के दौरान हमेशा पहला iter। जब मैं मशाल का उपयोग कर रहा था, हमने पाया कि एनसीसीएल इस तरह गतिरोध पैदा कर सकता है, क्या इसे बंद करने का कोई तरीका है?

मुझे एक ही समस्या का सामना करना पड़ रहा है, पहले युग की शुरुआत में यादृच्छिक रूप से फंस गया। ऊपर वर्णित सभी कामकाज मेरे लिए काम नहीं करते हैं। जब 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

मुझे डॉकटर के अंदर एक कार्यकर्ता के साथ गतिरोध होने की एक समान समस्या थी और मैं पुष्टि कर सकता हूं कि यह मेरे मामले में साझा स्मृति समस्या थी। डिफ़ॉल्ट रूप से डॉकर केवल 64 एमबी साझा स्मृति आवंटित करता प्रतीत होता है, हालांकि मुझे 1 कार्यकर्ता के लिए 440 एमबी की आवश्यकता होती है, जो शायद @apaszke द्वारा वर्णित व्यवहार का कारण बनती है।

मुझे एक ही समस्या से परेशान किया जा रहा है, फिर भी मैं इस धागे में अधिकांश अन्य लोगों से अलग वातावरण में हूं, इसलिए शायद मेरे इनपुट अंतर्निहित कारण का पता लगाने में मदद कर सकते हैं। Windows10 के तहत peterjc123 द्वारा निर्मित उत्कृष्ट कोंडा पैकेज का उपयोग करके मेरा पाइटोरच स्थापित किया गया है।

मैं cifar10 डेटासेट पर कुछ सीएनएन चला रहा हूँ। डेटालोडर्स के लिए, num_workers 1 पर सेट है। हालांकि num_workers> 0 होने से BrokenPipeError का कारण बनता है और # 494 में सलाह दी जाती है, जो मैं अनुभव कर रहा हूं वह BrokenPipeError नहीं बल्कि कुछ मेमोरी आवंटन त्रुटि है। त्रुटि हमेशा लगभग 50 युगों में होती है, पिछले युग की मान्यता के ठीक बाद और अगले युग के लिए प्रशिक्षण शुरू होने से पहले। 90% बार यह ठीक 50 युग है, दूसरी बार यह 1 या 2 युगों से बंद हो जाएगा। इसके अलावा बाकी सब कुछ काफी सुसंगत है। num_workers=0 सेट करने से यह समस्या समाप्त हो जाएगी।

@paulguerrero सही है। मैंने साझा मेमोरी को 64M से 2G तक बढ़ाकर इस समस्या को हल किया। शायद यह डोकर उपयोगकर्ताओं के लिए उपयोगी है।

@berzjackson यह कोंडा पैकेज में एक ज्ञात बग है। नवीनतम सीआई बिल्ड में फिक्स्ड।

हमारे पास ~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. मैंने उनसे उनकी साझा मेमोरी सेटिंग्स की जांच करने के लिए कहा है - लेकिन क्या इस समस्या को दूर करने के लिए मैं कुछ कर सकता हूं (या हम पाइटोरच में कर सकते हैं)? (num_workers को कम करने के अलावा, क्योंकि इससे चीजें काफी धीमी हो जाएंगी।)

मैं कक्षा में हूँ @ jph00 (धन्यवाद जेरेमी! :)) संदर्भित। मैंने "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 फोरम पर करें, यहां नहीं।

इस ASAP में देख रहे हैं!

@soumith मैंने @apaszke को पाठ्यक्रम के निजी मंच तक पहुंच प्रदान की है और मैंने समस्या वाले छात्रों से हमें उनके बॉक्स में प्रवेश करने की अनुमति देने के लिए कहा है।

@ jph00 हाय जेरेमी, क्या किसी छात्र ने ऊपर बताए गए @apaszke के रूप में shm बढ़ाने की कोशिश की? क्या यह मददगार था?

@SsnL छात्रों में से एक ने पुष्टि की है कि उन्होंने साझा स्मृति में वृद्धि की है, और अभी भी समस्या है। मैंने कुछ अन्य लोगों से भी पुष्टि करने के लिए कहा है।

@ jph00 धन्यवाद! कम साझा स्मृति के कारण मैंने सफलतापूर्वक हैंग को पुन: प्रस्तुत किया। अगर समस्या कहीं और है तो मुझे और गहराई से जाना होगा! क्या आप मेरे साथ स्क्रिप्ट साझा करना चाहते हैं?

ज़रूर - यहाँ वह नोटबुक है जिसका हम उपयोग कर रहे हैं: https://github.com/fastai/fastai/blob/master/courses/dl1/lesson1.ipynb । छात्रों ने देखा है कि समस्या केवल तब होती है जब वे सभी कक्षों को उस क्रम में चलाते हैं जिस क्रम में वे नोटबुक में हैं। उम्मीद है कि नोटबुक स्व-व्याख्यात्मक है, लेकिन मुझे बताएं कि क्या आपको इसे चलाने में कोई परेशानी है - इसमें आवश्यक डेटा डाउनलोड करने के लिए एक लिंक शामिल है।

साझा स्मृति समस्या के आधार पर आप दोहरा सकते हैं, क्या कोई ऐसा समाधान है जिसे मैं अपनी लाइब्रेरी या नोटबुक में जोड़ सकता हूं जो इससे बच जाएगा?

@ jph00 अभी कोड में गोता लगा रहे हैं। मैं साझा स्मृति उपयोग को कम करने के तरीकों को खोजने का प्रयास करूंगा। ऐसा नहीं लगता है कि स्क्रिप्ट में बड़ी मात्रा में शम का उपयोग किया जाना चाहिए, इसलिए आशा है!

मैं एक पीआर भी भेजूंगा ताकि शम सीमा को मारने के बजाय इसे लटकाए जाने पर एक अच्छा त्रुटि संदेश दिखाया जा सके।

ठीक है, मैंने अपने CUDA 9 AMI का उपयोग करके नवीनतम Pytorch conda इंस्टॉल के साथ एक नए AWS P2 उदाहरण पर समस्या को दोहराया है। यदि आप अपनी सार्वजनिक कुंजी प्रदान करते हैं, तो मैं आपको इसे सीधे आज़माने के लिए पहुँच प्रदान कर सकता हूँ। मेरा ईमेल मेरे नाम का पहला अक्षर है fast.ai

@ jph00 ने अभी आपको एक ईमेल भेजा है :) धन्यवाद!

@ jph00 और FYI करें, स्क्रिप्ट ने मेरे बॉक्स पर 400MB साझा मेमोरी ली। तो यह उन छात्रों के लिए बहुत अच्छा होगा जिनके पास यह समस्या थी कि उनके पास पर्याप्त मुफ्त शम है।

ठीक है तो मैंने मूल मुद्दे का पता लगा लिया है, जो कि ओपनसीवी और पाइटोरच मल्टीप्रोसेसिंग कभी-कभी एक साथ अच्छा नहीं खेलते हैं। विश्वविद्यालय में हमारे बॉक्स पर कोई समस्या नहीं है, लेकिन एडब्ल्यूएस पर बहुत सारी समस्याएं (नए गहन शिक्षण CUDA 9 AMI पर P2 उदाहरण के साथ)। सभी cv2 कॉल के आसपास लॉकिंग जोड़ने से यह ठीक नहीं होता है, और cv2.setNumThreads(0) जोड़ने से ठीक नहीं होता है। यह इसे ठीक करने लगता है:

from multiprocessing import set_start_method
set_start_method('spawn')

हालाँकि यह प्रदर्शन को लगभग 15% प्रभावित करता है। ओपनसीवी जीथब मुद्दे में सिफारिश https://github.com/tomMoral/loky का उपयोग करना है। मैंने पहले उस मॉड्यूल का उपयोग किया है और इसे रॉक-सॉलिड पाया है। अत्यावश्यक नहीं, क्योंकि हमारे पास एक समाधान है जो अभी के लिए पर्याप्त रूप से काम करता है - लेकिन डेटालोडर के लिए लोकी का उपयोग करने पर विचार करने योग्य हो सकता है?

शायद अधिक महत्वपूर्ण बात यह है कि यह अच्छा होगा यदि पाइटोरच की कतार में कम से कम किसी प्रकार का समय समाप्त हो जाए ताकि ये अनंत लटके पकड़े जा सकें।

एफवाईआई, मैंने अभी एक अलग फिक्स की कोशिश की, क्योंकि 'स्पॉन' कुछ हिस्सों को 2-3x धीमा कर रहा था - जो कि मैंने उन अनुभागों में कुछ यादृच्छिक नींद जोड़ दी जो डेटालोडर के माध्यम से जल्दी से पुनरावृत्त होते हैं। इससे समस्या भी ठीक हो गई - हालांकि शायद आदर्श नहीं!

इसमें खोदने के लिए धन्यवाद! यह जानकर खुशी हुई कि आपको दो समाधान मिल गए हैं। वास्तव में डेटासेट में अनुक्रमण पर टाइमआउट जोड़ना अच्छा होगा। हम कल उस मार्ग पर चर्चा करेंगे और आपसे संपर्क करेंगे।

cc @soumith लोकी है जिसकी हम जांच करना चाहते हैं?

जो लोग उपरोक्त चर्चा के लिए इस सूत्र में आते हैं, उनके लिए https://github.com/opencv/opencv/issues/5150 पर opencv मुद्दे पर अधिक गहराई से चर्चा की गई है।

ठीक है, मुझे लगता है कि अब इसके लिए एक उचित फिक्स है - मैंने डेटालोडर को उपयोगकर्ता ProcessPoolExecutor.map() फिर से लिखा है और टेंसर के निर्माण को मूल प्रक्रिया में स्थानांतरित कर दिया है। परिणाम मूल डेटालोडर के साथ देखने की तुलना में तेज़ है, और यह उन सभी कंप्यूटरों पर स्थिर रहा है जिन पर मैंने कोशिश की है। कोड भी बहुत आसान है।

यदि किसी को इसका उपयोग करने में दिलचस्पी है, तो आप इसे https://github.com/fastai/fastai/blob/master/fastai/dataloader.py से प्राप्त कर सकते हैं।

एपीआई मानक संस्करण के समान है, सिवाय इसके कि आपके डेटासेट को एक पाइटोरच टेंसर नहीं लौटाना चाहिए - इसे numpy arrays या python सूचियों को वापस करना चाहिए। मैंने इसे पुराने पायथन पर काम करने का कोई प्रयास नहीं किया है, इसलिए अगर वहां कुछ समस्याएं हैं तो मुझे आश्चर्य नहीं होगा।

(इस पथ के नीचे जाने का कारण यह है कि मैंने हाल के GPU पर बहुत अधिक छवि प्रसंस्करण/संवर्धन करते समय पाया कि मैं GPU को व्यस्त रखने के लिए प्रसंस्करण को तेजी से पूरा नहीं कर सका, अगर मैंने Pytorch CPU का उपयोग करके प्रीप्रोसेसिंग किया था संचालन; हालाँकि opencv का उपयोग करना बहुत तेज़ था, और परिणामस्वरूप मैं GPU का पूरी तरह से उपयोग करने में सक्षम था।)

ओह, अगर यह एक ओपनसीवी मुद्दा है तो इसके बारे में हम बहुत कुछ नहीं कर सकते हैं। यह सच है कि जब आपके पास थ्रेड पूल होते हैं तो फोर्किंग खतरनाक होती है। मुझे नहीं लगता कि हम रनटाइम निर्भरता जोड़ना चाहते हैं (वर्तमान में हमारे पास कोई नहीं है), विशेष रूप से यह PyTorch टेंसर को अच्छी तरह से संभाल नहीं पाएगा। यह पता लगाना बेहतर होगा कि गतिरोध का कारण क्या है और @SsnL उस पर है।

@ jph00 क्या आपने पिलो-सिम की कोशिश की है? इसे बॉक्स से बाहर टॉर्चविज़न के साथ काम करना चाहिए और मैंने इसके बारे में कई अच्छी बातें सुनी हैं।

हाँ मैं तकिए-सिम को अच्छी तरह जानता हूँ। यह केवल आकार बदलने, धुंधला करने और RGB रूपांतरण को गति देता है।

मैं सहमत नहीं हूं कि आप यहां बहुत कुछ नहीं कर सकते। यह वास्तव में एक ओपनसीवी मुद्दा नहीं है (वे इस प्रकार के पायथन मल्टीप्रोसेसिंग को अधिक आम तौर पर समर्थन देने का दावा नहीं करते हैं, अकेले पाइटोरच के विशेष-आवरण वाले बहु-प्रसंस्करण मॉड्यूल को छोड़ दें) और वास्तव में एक पाइटोरच मुद्दा भी नहीं है। लेकिन तथ्य यह है कि पाइटोरच चुपचाप किसी भी प्रकार की त्रुटि दिए बिना प्रतीक्षा करता है (आईएमओ) कुछ ऐसा है जिसे आप ठीक कर सकते हैं, और आम तौर पर बहुत से स्मार्ट लोग पिछले कुछ सालों में बेहतर मल्टीप्रोसेसिंग दृष्टिकोण बनाने के लिए कड़ी मेहनत कर रहे हैं जो समस्याओं से बचते हैं यह एक तरह। आप बाहरी निर्भरता लाए बिना उनके द्वारा उपयोग किए जाने वाले तरीकों से उधार ले सकते हैं।

ओलिवियर ग्रिसेल, जो लोकी के पीछे के लोगों में से एक है, के पास पाइथन में मल्टीप्रोसेसिंग की स्थिति को सारांशित करने वाला एक अच्छा स्लाइड डेक है: http://ogrisel.github.io/decks/2017_euroscipy_parallelism/

मुझे किसी भी तरह से कोई फर्क नहीं पड़ता, क्योंकि मैंने अब एक नया डेटालोडर लिखा है जिसमें समस्या नहीं है। लेकिन मैं करता हूं, एफडब्ल्यूआईडब्ल्यू, संदेह है कि पाइटोरच की मल्टीप्रोसेसिंग और अन्य प्रणालियों के बीच बातचीत भविष्य में अन्य लोगों के लिए भी एक मुद्दा होगा।

इसके लायक क्या है, मेरे पास यह मुद्दा ubuntu 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 , किसी ने भी मदद नहीं की

जिस चीज़ ने मेरी समस्या को मज़बूती से ठीक किया, वह मेरे कोड को पायथन 3 में पोर्ट कर रही थी। एक पायथन 3.6 इंस्टेंस (एनाकोंडा से) के अंदर मशाल के एक ही संस्करण को लॉन्च करने से मेरी समस्या पूरी तरह से ठीक हो गई और अब डेटा लोडिंग अब और लटका नहीं है।

@apaszke यहाँ opencv के साथ अच्छी तरह से काम करना क्यों महत्वपूर्ण है, FYI करें (और क्यों मशाल नमूना एक बढ़िया विकल्प नहीं है - यह <200 छवियों/सेकंड के रोटेशन को संभाल सकता है!):

क्या किसी को इस समस्या का समाधान मिला?

@iqbalu ऊपर दी गई स्क्रिप्ट को आज़माएं: https://github.com/fastai/fastai/blob/master/fastai/dataloader.py
इसने मेरी समस्या हल कर दी लेकिन यह num_workers=0 समर्थन नहीं करता है।

@elbaro वास्तव में मैंने इसकी कोशिश की और मेरे मामले में यह कई श्रमिकों का उपयोग नहीं कर रहा था। क्या आपने वहां कुछ बदला?

@iqbalu fast.ai डेटा लोडर कभी भी कार्यकर्ता प्रक्रियाओं को नहीं बढ़ाता है। यह केवल थ्रेड्स का उपयोग करता है, इसलिए हो सकता है कि वे कुछ टूल में दिखाई न दें

@apaszke @elbaro @ jph00 Fast.ai के डेटा लोडर ने डेटा रीडिंग को 10x से अधिक धीमा कर दिया। मैं num_workers=8 का उपयोग कर रहा हूँ। कोई संकेत क्या कारण हो सकता है?

यह संभावना है कि डेटा लोडर उन पैकेजों का उपयोग करता है जो GIL को नहीं छोड़ते हैं

@apaszke कोई विचार क्यों साझा-स्मृति का उपयोग कुछ युगों के बाद बढ़ता रहता है। मेरे मामले में, यह 400 एमबी से शुरू होता है और फिर हर ~ 20 वें युग में 400 एमबी बढ़ जाता है। धन्यवाद!

@iqbalu वास्तव में नहीं। ऐसा नहीं होना चाहिए

मैंने कई चीजों की कोशिश की और cv2.setNumThreads(0) ने आखिरकार मेरी समस्या हल कर दी।

धन्यवाद @jph00

मैं हाल ही में इस समस्या से परेशान हूं। cv2.setNumThreads(0) मेरे लिए काम नहीं करता है। मैं इसके बजाय scikit-image का उपयोग करने के लिए सभी cv2 कोड भी बदलता हूं, लेकिन समस्या अभी भी मौजूद है। इसके अलावा, मेरे पास /dev/shm लिए 16G है। एकाधिक gpus का उपयोग करते समय मुझे केवल यही समस्या है। सिंगल जीपीयू पर सब कुछ ठीक काम करता है। क्या किसी के पास समाधान पर कोई नया विचार है?

वही त्रुटि। सिंगल जीपीयू का उपयोग करते समय मुझे यह समस्या है।

मेरे लिए opencv थ्रेड्स को अक्षम करने से समस्या हल हो गई:
cv2.setNumThreads(0)

इसे pytorch 0.3, cuda 8.0, ubuntu 16.04 . के साथ भी हिट करें
कोई ओपनसीवी इस्तेमाल नहीं किया।

मैं pytorch 0.3, cuda 8.0, ubuntu 14.04 का उपयोग कर रहा हूँ। मैंने cv2.resize () का उपयोग शुरू करने के बाद इस हैंग को देखा

cv2.setNumThreads(0) ने मेरी समस्या हल कर दी।

मैं दो 1080Ti और 32GB RAM वाले सिस्टम पर अजगर 3.6, pytorch 0.3.0, cuda 8.0 और ubuntu 17.04 का उपयोग कर रहा हूं।

जब मैं अपने स्वयं के डेटासेट के लिए 8 श्रमिकों का उपयोग करता हूं, तो मुझे अक्सर गतिरोध दिखाई देता है (यह पहले युग में होता है)। जब मैं श्रमिकों को 4 तक कम करता हूं, तो यह गायब हो जाता है (मैंने 80 युग चलाए)।

जब गतिरोध होता है, तब भी मेरे पास RAM पर ~ 10GB मुफ़्त है।

यहां आप स्क्रिप्ट को समाप्त करने के बाद लॉग देख सकते हैं: https://gist.github.com/milani/42f50c023cdca407115b309237d29c70

अद्यतन: मैं पुष्टि करता हूं कि मैं SHMMNI को बढ़ाकर समस्या का समाधान कर सकता हूं। उबंटू 17.04 पर, मैंने kernel.shmmni=8192 से /etc/sysctl.conf जोड़ा।

साथ ही इस समस्या का अनुभव करते हुए, Ubuntu 17.10, Python 3.6, Pytorch 0.3.1, CUDA 8.0। जब गतिरोध होता है और समय असंगत लगता है तो बहुत सी RAM बची होती है - 1-सेंट युग के बाद, या 200-वें के बाद हो सकती है।

ऐसा लगता है कि kernel.shmmni=8192 और cv2.setNumThreads(0) संयोजन ने इसका उपचार किया है, जबकि वे व्यक्तिगत रूप से काम नहीं करते थे।

मेरे मामले में वही। अगर मैं num_workers=4 सेट करता हूं तो मुझे एक गतिरोध का अनुभव हुआ। मैं उबंटू 17.10, पाइटोरच 0.3.1, सीयूडीए 9.1, पायथन 3.6 का उपयोग करता हूं। यह देखा गया है कि 4 अजगर धागे हैं, जिनमें से प्रत्येक में 1.6 जीबी मेमोरी है जबकि सीपीयू (4 कोर) निष्क्रिय रहता है। num_workers=0 सेट करना इस समस्या को हल करने में मदद करता है।

मुझे एक ही समस्या है, ठीक एक युग के बाद जमा देता है, लेकिन वास्तव में छोटे डेटासेट के लिए पुन: उत्पन्न नहीं होता है। मैं डोकर वातावरण में CUDA 9.1, Pytorch 0.3.1, Python 3.6 का उपयोग कर रहा हूं।
मैंने @ jph00 के Dataloader की कोशिश की, हालांकि मैंने पाया कि यह मेरे उपयोगकेस के लिए बहुत धीमा था। मेरा समाधान वर्तमान में प्रत्येक युग से पहले Pytorch DataLoader को फिर से बनाना है। यह काम करने लगता है, लेकिन वास्तव में बदसूरत है।

मेरे पास Ubuntu 17.10, CUDA 9.1, Pytorch मास्टर (19/04 सुबह संकलित) पर बिल्कुल यही मुद्दा था। मेरे डेटासेट सबक्लास में ओपनसीवी का भी उपयोग करना।

तब मैं मल्टीप्रोसेसिंग स्टार्ट विधि को 'फोर्कसेवर' से 'स्पॉन' में बदलकर गतिरोध से बचने में सक्षम था:

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

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

मैंने लगभग उपरोक्त सभी तरीकों की कोशिश की! उनमें से कोई भी काम नहीं किया!
यह समस्या हार्डवेयर आर्किटेक्चर के साथ कुछ असंगतियों से संबंधित हो सकती है और मुझे नहीं पता कि पाइटोरच इसे कैसे उत्तेजित कर सकता है! यह पाइटोरच समस्या हो भी सकती है और नहीं भी!

तो यहां बताया गया है कि मेरी समस्या का समाधान कैसे हुआ:
_मैं BIOS को अपडेट करता हूं!

इसे मार दें। कम से कम इससे मेरी समस्या का समाधान हो जाए।

मेरा भी यही विचार है। उबंटू पायटोरच 0.4, पायथन 3.6।

ऐसा लगता है कि समस्या अभी भी pytorch 0.4 और अजगर 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 पर भी यही समस्या है।
और मैंने पिन_मेमोरी स्विच करने, साझा मेमोरी के आकार को बदलने के लिए सभी दृष्टिकोणों से ऊपर की कोशिश की, और मैं स्कीमेज लाइब्रेरी का उपयोग करता हूं (मैं सीवी 2 का उपयोग नहीं कर रहा हूं !!), लेकिन मुझे अभी भी समस्या है।

यह समस्या अनायास ही उठ जाती है। इस समस्या को नियंत्रित करना सिर्फ कंसोल देखना और प्रशिक्षण को फिर से शुरू करना है।

@ jinh574 मैंने अभी डेटा लोडर श्रमिकों की संख्या 0 पर सेट की है, और यह काम करता है।

@Shuailong मुझे बड़े आकार की छवि का उपयोग करना है, इसलिए मैं गति के कारण उस पैरामीटर का उपयोग नहीं कर सकता। मुझे इस समस्या के बारे में और अधिक निरीक्षण करने की आवश्यकता है

मुझे Python 3.6/Pytorch 0.4.0 पर एक ही समस्या है। क्या pin_memory विकल्प कुछ प्रभावित करता है?

यदि आप PyTorch संस्करण <0.4 के साथ Collate_fn, और num_workers>0 का उपयोग कर रहे हैं:

सुनिश्चित करें कि आप अपने __getitem__() फ़ंक्शन से शून्य मंद टेन्सर वापस नहीं करते हैं।
या उन्हें numpy Arrays के रूप में वापस करें।

मेरे पास 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 में
निष्पादन (कोड, 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, प्रतीक्षा में
(पीआईडी, एसटीएस) = स्वयं._try_wait(0)
फ़ाइल "/opt/conda/envs/pytorch-py3.6/lib/python3.6/subprocess.py", लाइन 1404, _try_wait में
(पीआईडी, एसटीएस) = ओएस वेटपिड (सेल्फ.पिड, वेट_फ्लैग्स)
कीबोर्ड इंटरप्ट

फ़ाइल "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/process.py", लाइन 258, _bootstrap में
सेल्फ.रन ()
फ़ाइल "/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 में
आर = index_queue.get (समयबाह्य = MANAGER_STATUS_CHECK_INTERVAL)
फ़ाइल "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/queues.py", लाइन 104, प्राप्त करने में
यदि स्वयं नहीं।_पोल (समयबाह्य):
फ़ाइल "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/connection.py", लाइन 257, पोल में
स्वयं लौटें._पोल (समय समाप्त)
फ़ाइल "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/connection.py", लाइन 414, _poll में
आर = प्रतीक्षा करें ([स्वयं], समय समाप्त)
फ़ाइल "/opt/conda/envs/pytorch-py3.6/lib/python3.6/multiprocessing/connection.py", लाइन 911, प्रतीक्षा में
तैयार = चयनकर्ता। चयन करें (समयबाह्य)
फ़ाइल "/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 रूप में अनुभव कर रहे हैं, क्या पीआर को अभी तक वहां विलय नहीं किया गया है?

@Evpok इसे वहीं मिला दिया गया है। आपके पास यह पैच निश्चित रूप से होना चाहिए। आश्चर्य है कि क्या कोई और अधिक गतिरोध संभव है। क्या आपके पास एक आसान रेप्रो है जिसे हम देखने की कोशिश कर सकते हैं?

मैंने वास्तव में इसे अपनी तरफ से एक असंबंधित मल्टीप्रोसेसिंग गड़बड़ी का पता लगाया, असुविधा के लिए खेद है।

नमस्ते @Evpok
मैं torch_nightly-1.0.0 उपयोग करता हूं, और इस समस्या को पूरा करता हूं। क्या आपने इस समस्या का समाधान किया है?

यदि आप PyTorch संस्करण <0.4 के साथ Collate_fn, और num_workers>0 का उपयोग कर रहे हैं:

सुनिश्चित करें कि आप अपने __getitem__() फ़ंक्शन से शून्य मंद टेन्सर वापस नहीं करते हैं।
या उन्हें numpy Arrays के रूप में वापस करें।

मैंने ज़ीरो डिम टेंसर लौटने की अपनी बग तय की और समस्या अभी भी मौजूद है।

@ zimenglan-sysu-512 मुख्य मुद्दा मल्टीप्रोसेसिंग की सीमाओं के साथ था: spawn या forkserver (जो CPU-GPU संचार के लिए आवश्यक है) का उपयोग करते समय प्रक्रिया के बीच वस्तुओं को साझा करना बल्कि सीमित है और नहीं मैं हेरफेर करने के लिए वस्तुओं की तरह के लिए उपयुक्त है।

इनमें से किसी ने भी मेरे लिए काम नहीं किया। हालांकि, नवीनतम ओपनसीवी काम करता है ( 3.4.0.12 से 3.4.3.18 बदलने के लिए और कुछ नहीं):
sudo pip3 install --upgrade opencv-python

@ देखें - यह जानकर खुशी हुई कि ओपनसीवी ने उनकी बात तय कर दी :)

मैं ओपनसीवी 3.4.3.18 पर पायथन 2.7 के साथ हूं, और मुझे अभी भी डेडलॉक हो रहा है। :/

कृपया निम्नलिखित प्रयास कीजिए:

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/मशाल/बर्तन/डेटा/dataloader.py

लाइन 816 में 656बी565
सुपर (डेटा लोडर, स्वयं)। __setattr__ (attr, वैल)

क्या यह सिर्फ एक उपनाम नहीं है? Torch.utils.data.__init__ में वे dataloader.DataLoader आयात करते हैं

मैं भी num_workers > 0 के साथ लटक रहा था। मेरे कोड में कोई opencv नहीं है, और /dev/shm की स्मृति उपयोग कोई समस्या नहीं है। ऊपर दिए गए किसी भी सुझाव ने मेरे लिए काम नहीं किया। मेरा फिक्स 1.14.1 से 1.14.5 तक numpy को अपडेट करना था:
conda install numpy=1.14.5
आशा है कि यह मददगार है।

हम्म, मेरा सुन्न संस्करण 1.15.4 है, इसलिए 1.14.5 से नया है... तो ठीक होना चाहिए?

हम्म, मेरा सुन्न संस्करण 1.15.4 है, इसलिए 1.14.5 से नया है... तो ठीक होना चाहिए?

Idk, मेरे अपडेट ऑफ numpy ने भी mkl को अपडेट किया।

आपके पास कौन सा एमकेएल संस्करण है? मेरा 2019 है (बिल्ड 144) और अन्य पैकेज जिनमें उनके नाम पर एमकेएल शामिल है:

एमकेएल-सेवा 1.1.2 py37he904b0f_5
mkl_fft 1.0.6 py37hd81dba3_0
mkl_random 1.0.2 py37hd81dba3_0

आपके पास कौन सा एमकेएल संस्करण है? मेरा 2019 है (बिल्ड 144) और अन्य पैकेज जिनमें उनके नाम पर एमकेएल शामिल है:

एमकेएल-सेवा 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

यदि आप अभी भी नवीनतम पाइटोरच में हैंग देखते हैं, तो यह बहुत मददगार होगा यदि आप एक छोटी स्क्रिप्ट प्रदान कर सकते हैं जो समस्या को पुन: उत्पन्न करती है। धन्यवाद!

मैं अभी भी इस गतिरोध को देख रहा हूं, मैं देखूंगा कि क्या मैं एक ऐसी स्क्रिप्ट बना सकता हूं जो पुन: उत्पन्न हो।

pin_memory=True ने मेरे लिए इस मुद्दे को हल किया।

मेरे लिए pin_memory=True साथ काम नहीं कर रहा है, अभी भी 70 युगों के बाद अटक गया है। केवल एक चीज जिसने मेरे लिए अब तक काम किया है वह num_workers=0 , लेकिन यह काफी धीमी है।

मैं भी गतिरोध का अनुभव कर रहा हूं (बहुत बेतरतीब ढंग से होता है)। pin_memory कोशिश की और Numpy को अपडेट किया। मैं इसे एक अलग मशीन पर चलाने की कोशिश करूंगा।

यदि आप डेटा लोडर के साथ कई थ्रेड्स का उपयोग कर रहे हैं, तो मल्टीथ्रेडिंग के बजाय मल्टीप्रोसेसिंग का उपयोग करने का प्रयास करें। इसने मेरे लिए इस मुद्दे को पूरी तरह से हल कर दिया (और वैसे, यह GIL के कारण पायथन में कम्प्यूटेशनल रूप से गहन कार्यों के लिए भी बेहतर है)

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)

मुझे लगता है कि देरी ने कुछ गतिरोध से बचने में मदद की?

मैं अभी भी इस समस्या से मिल रहा हूं। पाइटोरच 1.0 और पायथन 3.7 का उपयोग करना। जब मैं एकाधिक डेटा_लोडर का उपयोग कर रहा था, तो यह बग दिखाई देगा। यदि मैं 3 से कम डेटा_लोडर का उपयोग करता हूं या एकल GPU का उपयोग करता हूं, तो यह बग दिखाई नहीं देगा। कोशिश की:

1. समय सो जाओ (0.003)
2. pin_memory=सही/गलत
3. num_workers=0/1
4. मशाल से.utils.data.dataloader आयात DataLoader
5. 8192 को /proc/sys/kernel/shmmni . पर लिखना
   उनमें से कोई भी काम नहीं करता है। पता नहीं क्या कोई उपाय है?

मेरे समाधान प्रीप्रोसेस प्रोग्राम में cv2.setNumThreads(0) जोड़ें
मेरे पास 2 डेटालोडर हैं, जो ट्रेन और वैल के लिए हैं
मैं केवल एक बार मूल्यांकनकर्ता चला सकता था।

मैंने अभी इस बग का सामना pytorch 1.1 के साथ किया है। एक ही जगह पर दो बार अटक गया: 99वें युग का अंत। pin_memory को False सेट किया गया था।

श्रमिकों का उपयोग करते समय एक ही समस्या> 0, पिन मेमोरी ने समस्या का समाधान नहीं किया।

मेरे समाधान प्रीप्रोसेस प्रोग्राम में cv2.setNumThreads(0) जोड़ें
मेरे पास 2 डेटालोडर हैं, जो ट्रेन और वैल के लिए हैं
मैं केवल एक बार मूल्यांकनकर्ता चला सकता था।

यह समाधान मेरे लिए काम करता है, धन्यवाद

जब मैं एक युग समाप्त करता हूं तो डेटा लोडर बंद हो जाता है और एक नया युग शुरू करेगा।

एक ही समस्या से मिलो। मेरे मामले में, समस्या तब उत्पन्न होती है जब मैं opencv-python स्थापित करता हूं (मैंने पहले opencv3 स्थापित किया है)। opencv-python ले जाने के बाद, प्रशिक्षण बंद नहीं होगा।

यह भी एक अच्छा विचार है

2019/06/20 10:51:02 पर, "hongzhenwang" [email protected] लिखा है:

जब मैं एक युग समाप्त करता हूं तो डेटा लोडर बंद हो जाता है और एक नया युग शुरू करेगा।

एक ही समस्या से मिलो। मेरे मामले में, समस्या तब उत्पन्न होती है जब मैं opencv-python स्थापित करता हूं (मैंने पहले opencv3 स्थापित किया है)। opencv-python ले जाने के बाद, प्रशिक्षण बंद नहीं होगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

मैं अभी भी इस समस्या से मिल रहा हूं। पाइटोरच 1.0 और पायथन 3.7 का उपयोग करना। जब मैं एकाधिक डेटा_लोडर का उपयोग कर रहा था, तो यह बग दिखाई देगा। यदि मैं 3 से कम डेटा_लोडर का उपयोग करता हूं या एकल 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 को सेट करना सीपीयू के संपूर्ण डेटा को धीमा कर देता है और GPU उपयोग दर बहुत कम होगी।

मेरे लिए, इसका कारण यह था कि मेरे सिस्टम में पर्याप्त CPU नहीं थे या पर्याप्त num_workers Dataloader में निर्दिष्ट नहीं थे। अगर डेटालोडर में __get_item__ विधि numpy , librosa या opencv जैसी थ्रेडेड लाइब्रेरी का उपयोग करती है तो डेटालोडर श्रमिकों में थ्रेडिंग को अक्षम करना भी एक अच्छा विचार हो सकता है। OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 python train.py साथ चलाकर प्राप्त किया जा सकता है। नीचे चर्चा के लिए एक स्पष्टीकरण के रूप में, कृपया ध्यान दें कि प्रत्येक डाटालोडर बैच को एक ही कार्यकर्ता द्वारा नियंत्रित किया जाता है: प्रत्येक कार्यकर्ता एक बैच को पूरा करने के लिए batch_size नमूने संभालता है, और फिर डेटा के एक नए बैच को संसाधित करना शुरू करता है।

आपको मशीन में सीपीयू की संख्या से कम num_workers सेट करने की आवश्यकता है (या यदि आप कुबेरनेट्स का उपयोग कर रहे हैं तो पॉड), लेकिन इतना अधिक है कि डेटा हमेशा अगले पुनरावृत्ति के लिए तैयार है। यदि GPU प्रत्येक पुनरावृत्ति को t सेकंड में चलाता है, और प्रत्येक dataloader कार्यकर्ता एक बैच को लोड/प्रोसेस करने के लिए N*t सेकंड लेता है, तो आपको num_workers को कम से कम N पर सेट करना चाहिए। N CPU होना चाहिए।

दुर्भाग्य से, यदि Dataloader किसी पुस्तकालय का उपयोग करता है जो K धागे का उपयोग करता है, तो उत्पन्न प्रक्रियाओं की संख्या num_workers*K = N*K । यह मशीन में सीपीयू की संख्या से काफी अधिक हो सकता है। यह पॉड को थ्रॉटल करता है, और डेटालोडर बहुत धीमा हो जाता है। यह Dataloader को हर t सेकंड में एक बैच वापस नहीं करने का कारण बन सकता है, जिससे GPU स्टाल हो जाता है।

K थ्रेड से बचने का एक तरीका मुख्य स्क्रिप्ट को OMP_NUM_THREADS=1 MKL_NUM_THREADS=1 python train.py द्वारा कॉल करना है। यह प्रत्येक डाटालोडर कार्यकर्ता को एक ही धागे का उपयोग करने के लिए प्रतिबंधित करता है, और मशीन को भारी होने से बचाता है। GPU को चालू रखने के लिए आपके पास अभी भी पर्याप्त num_workers होना चाहिए।

आपको अपना कोड __get_item__ में भी अनुकूलित करना चाहिए ताकि प्रत्येक कार्यकर्ता कम समय में अपना बैच पूरा कर सके। कृपया सुनिश्चित करें कि कार्यकर्ता द्वारा बैच पूर्व-प्रसंस्करण को पूरा करने का समय डिस्क से प्रशिक्षण डेटा पढ़ने के समय में बाधा नहीं है (विशेषकर यदि आप नेटवर्क स्टोरेज से पढ़ रहे हैं), या नेटवर्क बैंडविड्थ (यदि आप नेटवर्क से पढ़ रहे हैं) डिस्क)। यदि आपका डेटासेट छोटा है और आपके पास पर्याप्त RAM है, तो डेटासेट को RAM (या /tmpfs ) में ले जाने पर विचार करें और त्वरित पहुंच के लिए वहां से पढ़ें। कुबेरनेट्स के लिए, आप एक रैम डिस्क बना सकते हैं (कुबेरनेट्स में emptyDir खोजें)।

यदि आपने अपना __get_item__ कोड अनुकूलित किया है, और यह सुनिश्चित किया है कि डिस्क एक्सेस/नेटवर्क एक्सेस अपराधी नहीं हैं, लेकिन फिर भी स्टॉल देखते हैं, तो आपको अधिक CPU (कुबेरनेट्स पॉड के लिए) का अनुरोध करना होगा या अपने GPU को एक अधिक CPU के साथ मशीन।

एक अन्य विकल्प batch_size को कम करना है ताकि प्रत्येक worker पास करने के लिए कम काम हो, और पूर्व-प्रसंस्करण जल्दी समाप्त हो जाएगा। बाद वाला विकल्प कुछ मामलों में वांछनीय नहीं है, क्योंकि निष्क्रिय GPU मेमोरी का उपयोग नहीं किया जा रहा होगा।

आप कुछ पूर्व-प्रसंस्करण ऑफ़लाइन करने पर भी विचार कर सकते हैं, और प्रत्येक कार्यकर्ता का वजन कम कर सकते हैं। उदाहरण के लिए, यदि प्रत्येक कार्यकर्ता एक wav फ़ाइल में पढ़ रहा है और ऑडियो फ़ाइल के लिए स्पेक्ट्रोग्राम की गणना कर रहा है, तो आप स्पेक्ट्रोग्राम को ऑफ़लाइन पूर्व-गणना करने पर विचार कर सकते हैं और कार्यकर्ता में डिस्क से गणना किए गए स्पेक्ट्रोग्राम को पढ़ सकते हैं। इससे प्रत्येक कार्यकर्ता को काम करने की मात्रा कम हो जाएगी।

होरोवोड के साथ एक ही मुद्दे को पूरा करें

मिलते-जुलते मुद्दे को पूरा करें... बस एक युग की समाप्ति और सत्यापन के लिए डेटा लोड करना प्रारंभ करते समय गतिरोध...

@jinhou @jackroos वही बात, बेतरतीब ढंग से होरोवोड के साथ सत्यापन की शुरुआत में अटक गई। वर्कअराउंड के रूप में मैं वर्तमान में जो करता हूं वह टाइमआउट सेट करना और सत्यापन छोड़ना है। क्या आपके पास एक समाधान है?

@jinhou @jackroos वही बात, बेतरतीब ढंग से होरोवोड के साथ सत्यापन की शुरुआत में अटक गई। वर्कअराउंड के रूप में मैं वर्तमान में जो करता हूं वह टाइमआउट सेट करना और सत्यापन छोड़ना है। क्या आपके पास एक समाधान है?

नहीं, मैं उस मामले में वितरित प्रशिक्षण बंद कर देता हूं।

मैं एक समान मुद्दे से मिला: जब मैं एक युग समाप्त करता हूं तो डेटा लोडर बंद हो जाता है और एक नया युग शुरू करेगा।

इतना ज़ान क्यों?

मैं अभी भी इस समस्या से मिल रहा हूं। पाइटोरच 1.0 और पायथन 3.7 का उपयोग करना। जब मैं एकाधिक डेटा_लोडर का उपयोग कर रहा था, तो यह बग दिखाई देगा। यदि मैं 3 से कम डेटा_लोडर का उपयोग करता हूं या एकल GPU का उपयोग करता हूं, तो यह बग दिखाई नहीं देगा। कोशिश की:

1. समय सो जाओ (0.003)
2. pin_memory=सही/गलत
3. num_workers=0/1
4. मशाल से.utils.data.dataloader आयात DataLoader
5. 8192 को /proc/sys/kernel/shmmni . पर लिखना
   उनमें से कोई भी काम नहीं करता है। पता नहीं क्या कोई उपाय है?

num_workers 0 पर सेट मेरे लिए काम किया। आपको यह सुनिश्चित करना चाहिए कि आप इसका उपयोग कर रहे हर जगह 0 पर हैं।

कुछ अन्य संभावित समाधान:

1. मल्टीप्रोसेसिंग आयात से set_start_method
   set_start_method ('स्पॉन')
2. cv2.setNumThreads(0)

ऐसा लगता है कि 3 या 7 जाने का रास्ता है।

मैं इस मुद्दे को pytorch 1.3, ubuntu16 के साथ अनुभव करता हूं, उपरोक्त सभी सुझाव काम नहीं करते हैं सिवाय श्रमिकों = 0 के जो निष्पादन को धीमा कर देता है। यह केवल तब होता है जब टर्मिनल से चल रहा हो, जुपिटर नोटबुक के भीतर सब कुछ ठीक है, यहां तक ​​​​कि श्रमिकों = 32 के साथ भी।

मसला सुलझता नहीं दिख रहा, क्या इसे फिर से खोलना चाहिए? मैं कई अन्य लोगों को भी इसी समस्या की रिपोर्ट करते हुए देखता हूं...

मैं अभी भी इस समस्या से मिल रहा हूं। पाइटोरच 1.0 और पायथन 3.7 का उपयोग करना। जब मैं एकाधिक डेटा_लोडर का उपयोग कर रहा था, तो यह बग दिखाई देगा। यदि मैं 3 से कम डेटा_लोडर का उपयोग करता हूं या एकल GPU का उपयोग करता हूं, तो यह बग दिखाई नहीं देगा। कोशिश की:

1. समय सो जाओ (0.003)
2. pin_memory=सही/गलत
3. num_workers=0/1
4. मशाल से.utils.data.dataloader आयात DataLoader
5. 8192 को /proc/sys/kernel/shmmni . पर लिखना
   उनमें से कोई भी काम नहीं करता है। पता नहीं क्या कोई उपाय है?

num_workers 0 पर सेट मेरे लिए काम किया। आपको यह सुनिश्चित करना चाहिए कि आप इसका उपयोग कर रहे हर जगह 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]

यह मेरे लिए अस्पष्ट है, लेकिन उसने मुझे बताया कि सीयूडीए और पायथन मल्टीथ्रेडिंग अच्छा नहीं खेल रहे थे।

मेरा फिक्स डेटाथ्रेड्स में क्यूडा को अक्षम करना था, यहां मेरी पायथन प्रविष्टि फ़ाइल का एक स्निपेट है।

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 वही बात, बेतरतीब ढंग से होरोवोड के साथ सत्यापन की शुरुआत में अटक गई। वर्कअराउंड के रूप में मैं वर्तमान में जो करता हूं वह टाइमआउट सेट करना और सत्यापन छोड़ना है। क्या आपके पास एक समाधान है?

नहीं, मैं उस मामले में वितरित प्रशिक्षण बंद कर देता हूं।

मैं PyTorch 1.4 को अपडेट करने के बाद OpenCV का उपयोग किए बिना वितरित प्रशिक्षण में एक समान समस्या को पूरा करता हूं।
अब मुझे प्रशिक्षण और सत्यापन लूप से पहले एक बार सत्यापन चलाना है।

मुझे इससे बहुत परेशानी हुई है। ऐसा लगता है कि पाइटोरच के संस्करणों, अजगर के संस्करणों और विभिन्न भौतिक मशीनों (जो संभवतः समान रूप से स्थापित किए गए होंगे) के संस्करणों में बनी रहती है।

हर बार वही त्रुटि होती है:

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 में घटा देता हूं, और डेटा सेट बहुत छोटा है, यह अभी भी एक ही समस्या है। मुझे संदेह है कि यह शम से संबंधित है। कोई सुराग?

क्या हम इस मुद्दे को फिर से खोलेंगे?

मेरा ख्याल है हमें करना चाहिए। बीटीडब्लू, मैंने कुछ जीडीबी डीबग किया और वहां कुछ भी नहीं मिला। इसलिए मुझे सच में यकीन नहीं है कि यह साझा स्मृति समस्या है या नहीं,

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

और मुझे लगता है कि मेरे पास पर्याप्त साझा स्मृति है, कम से कम मुझे उम्मीद है कि साझा स्मृति काफी लंबे समय तक सेगफॉल्ट तक पर्याप्त है, लेकिन डेटालोडर नौकरी लॉन्च करने के तुरंत बाद सेगमेंट गलती होती है

------ 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 , क्या हम इस मुद्दे को फिर से खोल सकते हैं, मैंने शम आकार और सेगमेंट को बढ़ाने जैसे प्रस्तावित सभी समाधानों की कोशिश की, कुछ भी काम नहीं करता, मैं ओपनसीवी का उपयोग नहीं कर रहा हूं, बस साधारण JSON पार्सिंग। लेकिन मुद्दा अभी भी वहीं है। और मुझे नहीं लगता कि यह चेक से संबंधित शम से संबंधित है, मैं सभी मेमोरी को साझा मेमोरी के रूप में खोलता हूं। जैसा कि ऊपर पोस्ट किया गया है स्टैक ट्रेस भी वहां कुछ भी नहीं दिखाता है।

@apaszke , आपके सुझाव के संबंध में

"हां, उनमें से बहुत से मुद्दे तीसरे पक्ष के पुस्तकालयों के कांटे सुरक्षित नहीं होने के कारण हैं। एक वैकल्पिक समाधान स्पॉन स्टार्ट विधि का उपयोग करना हो सकता है।"

मैं डेटालोडर मल्टी वर्कर का उपयोग कर रहा हूं, मैं विधि कैसे बदल सकता हूं? मैं अपने main.py में set_start_method('spawn') कर रहा हूं, लेकिन खुराक मददगार नहीं है

इसके अलावा, मेरा यहां एक सामान्य प्रश्न है, यदि मैं मल्टी वर्कर (मल्टी प्रोसेस) डेटा लोडर को सक्षम करता हूं, और मुख्य प्रशिक्षण में मैं https://pytorch.org/docs/stable/notes/multiprocessing.html में सुझाए गए अनुसार मल्टी प्रोसेस भी शुरू करता हूं।

pytorch कैसे dataloader और मुख्य प्रशिक्षण बहु-प्रक्रिया दोनों का प्रबंधन करता है? क्या वे मल्टी कोर जीपीयू पर हर संभव प्रक्रिया/थ्रेडिंग साझा करेंगे? मल्टी प्रोसेस के लिए साझा की गई मेमोरी डेटा लोडर और मुख्य प्रशिक्षण प्रक्रिया द्वारा "साझा" की जाती है? अगर मेरे पास जेएसओएन पार्सिंग, सीएसवी पार्सिंग, पांडा फीचर निष्कर्षण जैसे कुछ डेटा कुक जॉब भी हैं। आदि, डालने का सबसे अच्छा तरीका कहां है? डेटा लोडर में तैयार डेटा के लिए एकदम सही उत्पन्न करने के लिए या ऐसा करने के लिए मुख्य प्रशिक्षण का उपयोग करें जैसा कि ऊपर कुछ सुझाव दिया गया है ताकि डेटा लोडर __get_item__ यथासंभव सरल रखा जा सके

@zhangruiskyline आपकी समस्या वास्तव में गतिरोध नहीं है। यह सेगफॉल्ट द्वारा मारे जा रहे श्रमिकों के बारे में है। सिगबस वह है जो शम मुद्दों का सुझाव देता है। आपको अपना डेटासेट कोड जांचना चाहिए और वहां डीबग करना चाहिए।

आपके अन्य प्रश्नों का उत्तर देने के लिए,

1. डेटा लोडर में kwarg multiproessing_context='spawn' का उपयोग करें स्पॉन सेट करेगा। set_start_method भी यही करता है।
2. आमतौर पर मल्टीप्रोसेस प्रशिक्षण में, प्रत्येक प्रक्रिया का अपना डेटालोडर होता है, और इस प्रकार डेटालोडर कार्यकर्ता। प्रक्रियाओं के बीच कुछ भी साझा नहीं किया जाता है जब तक कि स्पष्ट रूप से ऐसा नहीं किया जाता है।

धन्यवाद @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 पार्सिंग का उपयोग नहीं करने का प्रयास करता हूं, लेकिन सीधे स्ट्रिंग स्प्लिट, एक ही समस्या। ऐसा लगता है कि जब तक मेरे पास डेटा लोडर में डेटा प्रक्रिया के लिए कुछ समय लेने वाला तर्क है, तब तक यह समस्या होती है

इसके बारे में भी

मल्टीप्रोसेस प्रशिक्षण, प्रत्येक प्रक्रिया का अपना डेटालोडर होता है, और इस प्रकार डेटालोडर कार्यकर्ता प्रक्रियाओं के बीच कुछ भी साझा नहीं किया जाता है जब तक कि स्पष्ट रूप से ऐसा नहीं किया जाता है।

तो आइए देखें कि मेरे पास प्रशिक्षण के लिए 4 प्रक्रियाएँ हैं, प्रत्येक में 8 कार्यकर्ता डेटा लोडर है, इसलिए कुल 32 प्रक्रिया नीचे है?

@zhangruiskyline इस मुद्दे को पुन: पेश करने के लिए स्वयं निहित स्क्रिप्ट के बिना, हम आपकी मदद नहीं कर सकते हैं। हाँ 32 प्रक्रियाएँ होंगी

धन्यवाद, मैंने भी इसी तरह का मुद्दा देखा
https://github.com/pytorch/pytorch/issues/4969
https://github.com/pytorch/pytorch/issues/5040

दोनों बंद हैं लेकिन मुझे स्पष्ट समाधान या समाधान नहीं दिख रहा है, क्या यह अभी भी एक व्यापक मौजूदा समस्या है?

मैं देखूंगा कि क्या मैं स्वयं निहित पुनरुत्पादन स्क्रिप्ट प्रदान कर सकता हूं लेकिन यह हमारे मंच और डेटा स्रोत के लिए अत्यधिक एकीकृत है, इसलिए कोशिश करेंगे

@zhangruiskyline आपकी समस्या किसी भी जुड़े हुए मुद्दे के समान नहीं है, अगर आप उन्हें पढ़ते हैं। वे बंद हैं क्योंकि उन थ्रेड्स पर रिपोर्ट की गई मूल/सबसे आम समस्या पहले से ही संबोधित है।

धन्यवाद @ एसएसएनएल , मैं

• कार्यकर्ता की संख्या को घटाकर 0 कर दें, यह हमारे लिए अस्वीकार्य है क्योंकि यह बहुत धीमा है,

• शम आकार बढ़ाएं, लेकिन हमारे पास पर्याप्त शम है, मुझे विश्वास है, और समस्या शुरू होने के लगभग तुरंत बाद हुई, और मैंने बहुत छोटे डेटा सेट समस्या के साथ प्रयास किया

• ओपनसीवी खुराक जैसे कुछ काम बहु-प्रक्रिया में अच्छी तरह से काम नहीं करते हैं, हम सिर्फ JSON/CSV का उपयोग कर रहे हैं, इसलिए वास्तव में फैंसी सामान नहीं है

हमारा कोड काफी सरल है, प्रशिक्षण डेटा सेट में 10000+ फ़ाइलें हैं, प्रत्येक फ़ाइल JSON स्ट्रिंग्स की कई पंक्तियाँ हैं। डेटालोडर में, हम प्रत्येक फ़ाइल को 10K+ फ़ाइलों से बाहर निकालने के लिए __get_item__ को परिभाषित करते हैं और उस फ़ाइल की सभी सामग्री को पढ़ते हैं।

समाधान 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/mmcv में एक दिलचस्प टिप्पणी मिली, जिसका उपयोग https://github.com/open-mmlab/mmdetection में किया जाता है:

निम्नलिखित कोड का उपयोग ट्रेन युग और वैल युग दोनों की शुरुआत में किया जाता है।
time.sleep(2) # युग परिवर्तन के दौरान संभावित गतिरोध को रोकें

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

हो सकता है आप इसे आजमा सकते हैं।

बीटीडब्लू, अगर मैं बहु प्रक्रिया और बहु ​​कार्यकर्ता डेटा लोडर के साथ प्रत्येक प्रक्रिया में जाता हूं, तो अलग-अलग प्रक्रिया कैसे सुनिश्चित कर सकती है कि उनके संबंधित डेटालोडर अन्य प्रक्रिया के डेटालोडर के समान डेटा नहीं पढ़ेंगे? क्या पहले से ही pytorch dataloader __get_item__ द्वारा नियंत्रित किया जाता है?

हाय @ एसएसएनएल , आपकी मदद के लिए धन्यवाद। बस इस धागे पर थोड़ा सा पालन करना चाहता हूं, मैं सीपीयू पक्ष में कुछ डेटा प्रोसेसिंग को तेज करने के लिए पाइटोरच मल्टी प्रोसेसिंग का उपयोग करके प्रशिक्षण कोड को दोबारा प्रतिक्रिया देता हूं (जीपीयू को तेजी से खिलाने के लिए), https://pytorch.org/docs/stable /notes/multiprocessing.html#multiprocessing -best-practices

प्रत्येक प्रोसेसिंग फंक में, मैं डेटा लोडिंग प्रोसेसिंग समय को तेज करने के लिए मल्टी-वर्कर डेटा लोडर का भी उपयोग करता हूं। https://pytorch.org/docs/stable/data.html

मैंने अपने हीविंग सीपीयू JSON को डेटालोडर में नहीं, बल्कि मुख्य प्रशिक्षण प्रक्रिया में रखा है, और समस्या दूर हो गई है, मुझे नहीं पता कि क्यों लेकिन वैसे भी यह काम कर रहा है। लेकिन एक अनुवर्ती प्रश्न है: मान लीजिए कि मेरे पास N प्रसंस्करण है, प्रत्येक में M डेटालोडर कार्यकर्ता है, इसलिए वहां थ्रेडिंग के नीचे कुल NxM है।

अगर मेरे डेटालोडर में, मैं सभी डेटा को इंडेक्स तरीके से प्राप्त करना चाहता हूं, जिसका मतलब है कि एम डेटा लोडर में __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.5 जीबी दिखाता है)। उम्मीद है की यह मदद करेगा!

मैं 4 श्रमिकों का उपयोग कर रहा हूं (संस्करण 0.1.12_2 Ubuntu 16.04 पर CUDA 8.0 के साथ)।

हफ्तों के संघर्ष के बाद इसने मेरे लिए समस्या हल कर दी। मुझे लोडर को सीधे लूप करने के बजाय लोडर इटरेटर का स्पष्ट रूप से उपयोग करना होगा और युग के अंत में del loader_iterator का उपयोग करके अंत में गतिरोध को हटा दिया

मुझे लगता है कि मुझे एक ही समस्या का सामना करना पड़ रहा है। 8 डेटा लोडर (MNIST, MNISTM, SVHN, USPS, ट्रेन और प्रत्येक परीक्षण के लिए) का उपयोग करने का प्रयास कर रहा है। 6 (कोई भी 6) का उपयोग करना ठीक काम करता है। 6वां एमएनआईएसटी-एम परीक्षण लोड करते समय 8 का उपयोग हमेशा ब्लॉक करता है। यह छवि को पुनः प्राप्त करने, असफल होने, थोड़ा इंतजार करने और फिर से प्रयास करने के कुछ अंतहीन पाश में फंस गया है। त्रुटि किसी भी बैच_साइज़ के लिए बनी रहती है, मेरे पास बहुत सारी खाली मेमोरी बची है, और यह केवल तभी चली जाती है जब मैं 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 पर तय किया है

शायद सेट ulimit -n एक सही तरीका है, मॉडल की वृद्धि के साथ, गतिरोध अधिक से अधिक बार-बार हो जाता है, मैं भी परीक्षण करता हूं cv2.setNumThreads(0) , लेकिन यह काम नहीं करता है।

रिकॉर्ड के लिए, cv2.setNumThreads(0) ने मेरे लिए काम किया।