पाइथन यादृच्छिक रूप से 0% CPU उपयोग तक गिर जाता है, जिससे कोड को "लटका" होता है, जब बड़े numpy arrays को संभाला जाता है?

Question

मैं कुछ कोड चला रहा हूं, जिसमें से एक हिस्सा एक बाइनरी फ़ाइल से बड़ी 1 डी numpy सरणी में लोड करता है, और फिर numpy.where() विधि का उपयोग करके सरणी को बदल देता है।

यहाँ कोड में प्रदर्शन के संचालन का एक उदाहरण है:

import numpy as np 
num = 2048 
threshold = 0.5 

with open(file, 'rb') as f: 
    arr = np.fromfile(f, dtype=np.float32, count=num**3) 
    arr *= threshold 

arr = np.where(arr >= 1.0, 1.0, arr) 
vol_avg = np.sum(arr)/(num**3) 

# both arr and vol_avg needed later 

मैं इस में कई बार (एक नि: शुल्क मशीन पर, जिसका अर्थ है कोई अन्य बाधा CPU या स्मृति उपयोग) कोई समस्या नहीं के साथ समाप्त हो गया है। लेकिन हाल ही में मैंने देखा है कि कभी-कभी कोड एक विस्तारित अवधि के लिए लटकता है, जिससे रनटाइम लंबे समय तक परिमाण का क्रम बना देता है। इन अवसरों पर मैं% CPU और मेमोरी उपयोग (gnome सिस्टम मॉनीटर का उपयोग करके) की निगरानी कर रहा हूं, और पाया कि पायथन का CPU उपयोग 0% तक गिर जाता है।

उपरोक्त संचालन के बीच मूल प्रिंटों का उपयोग डीबग करने के लिए करते हुए, यह मनमाने ढंग से प्रतीत होता है कि किस ऑपरेशन को रोकना (यानी खुला(), np.fromfile(), np.where() प्रत्येक अलग से लटका हुआ है एक यादृच्छिक दौड़ पर)। ऐसा लगता है कि मुझे यादृच्छिक रूप से थ्रॉटल किया जा रहा है, क्योंकि अन्य रनों पर कोई लटक नहीं है।

मैंने कचरा संग्रह या this question जैसी चीजों पर विचार किया है, लेकिन मुझे मेरी समस्या का कोई स्पष्ट संबंध नहीं दिख रहा है (उदाहरण के लिए कीस्ट्रोक का कोई प्रभाव नहीं पड़ता है)।

आगे नोट्स: बाइनरी फ़ाइल 32 जीबी है, मशीन (चलने वाले लिनक्स) में 256 जीबी मेमोरी है। मैं एक एसएसएच सत्र के माध्यम से, इस कोड को दूरस्थ रूप से चला रहा हूं।

संपादित करें: यह आकस्मिक हो सकता है, लेकिन मैंने देखा है कि अगर मशीन को अभी रिबूट किया गया है तो कोड चलाने पर कोई लटका नहीं है। ऐसा लगता है कि वे कुछ रनों के बाद, या कम से कम सिस्टम के अन्य उपयोग के बाद होने लगते हैं।

Answer 1

सीपीयू उपयोग में बूंद पाइथन या numpy से असंबंधित थे, लेकिन वास्तव में साझा डिस्क से पढ़ने का नतीजा था, और नेटवर्क I/O असली अपराधी था। ऐसे बड़े सरणी के लिए, स्मृति में पढ़ना एक बड़ी बाधा हो सकती है।

Answer 2

np.where वहां एक प्रति बना रहा है और इसे arr में वापस सौंप रहा है। तो, हम स्मृति पर वहाँ एक नकल कदम से बचकर, अनुकूलन कर सकता है जिससे की तरह -

vol_avg = (np.sum(arr) - (arr[arr >= 1.0] - 1.0).sum())/(num**3) 

हम boolean-indexing उपयोग कर रहे हैं तत्वों कि 1.0 से अधिक और कर रहे हैं का चयन करने के 1.0 से उनके ऑफसेट हो रही है और उन संक्षेप और से घटाकर कुल योग उम्मीद है कि इस तरह के अधिक से अधिक तत्वों की संख्या कम है और इस तरह अब ध्यान देने योग्य स्मृति आवश्यकता नहीं होगी। मुझे लगता है कि बड़े सरणी के साथ इस लटकती हुई समस्या एक स्मृति आधारित है।