एकाधिक कर्नेल CPU एकाधिक पाइथन प्रोग्राम चलाते समय

Question

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

कोई उच्च कर्नेल CPU उपयोग को कैसे कम करेगा?

यहाँ कुछ अवलोकन जो मैंने बनाया है:

• इस आशय है कि क्या मैं 10 नौकरियों या 50. चलाने के स्वतंत्र प्रकट होता है कोर की तुलना में कम नौकरियों देखते हैं तो सभी कोर का उपयोग किया जाता है, लेकिन जो कि कर रहे हैं अभी भी गिरी
• मैं भीतरी पाश numba का उपयोग करके लागू द्वारा एक उच्च CPU उपयोग है, लेकिन समस्या यह से संबंधित नहीं है, के बाद से Numba हिस्से को हटाने समस्या हल नहीं होती
• मैं भी यह है कि यह हो सकता है problem mentioned in this SO question bu के समान python2 का उपयोग करने से संबंधित python2 से python3 में t स्विचिंग
• नहीं बदला गया था, मैंने ओएस द्वारा किए गए संदर्भ स्विच की कुल संख्या को माप लिया, जो लगभग 10000 प्रति सेकेंड है। मुझे यकीन है कि क्या यह एक बड़ी संख्या
• मैं (को Python2 के लिए) sys.setcheckinterval(10000) और sys.setswitchinterval(10) (python3 के लिए) निर्धारित कर अजगर समय स्लाइस में वृद्धि करने की कोशिश की है नहीं कर रहा हूँ, लेकिन इस में से कोई भी
• मैं चलाकर कार्य अनुसूचक को प्रभावित करने की कोशिश की मदद की schedtool -B PID लेकिन यह मदद नहीं की

संपादित करें: यहाँ है htop का स्क्रीनशॉट:

मैं भीभाग गया

Samples: 1M of event 'cycles', Event count (approx.): 1114297095227         
- 95.25%   python3 [kernel.kallsyms]       [k] _raw_spin_lock_irqsave ◆ 
    - _raw_spin_lock_irqsave                   ▒ 
     - 95.01% extract_buf                   ▒ 
      extract_entropy_user                  ▒ 
      urandom_read                    ▒ 
      vfs_read                     ▒ 
      sys_read                     ▒ 
      system_call_fastpath                  ▒ 
      __GI___libc_read                   ▒ 
- 2.06%   python3 [kernel.kallsyms]       [k] sha_transform   ▒ 
    - sha_transform                     ▒ 
     - 2.06% extract_buf                   ▒ 
      extract_entropy_user                  ▒ 
      urandom_read                    ▒ 
      vfs_read                     ▒ 
      sys_read                     ▒ 
      system_call_fastpath                  ▒ 
      __GI___libc_read                   ▒ 
- 0.74%   python3 [kernel.kallsyms]       [k] _mix_pool_bytes   ▒ 
    - _mix_pool_bytes                     ▒ 
     - 0.74% __mix_pool_bytes                  ▒ 
      extract_buf                    ▒ 
      extract_entropy_user                  ▒ 
      urandom_read                    ▒ 
      vfs_read                     ▒ 
      sys_read                     ▒ 
      system_call_fastpath                  ▒ 
      __GI___libc_read                   ▒ 
    0.44%   python3 [kernel.kallsyms]       [k] extract_buf    ▒ 
    0.15%   python3 python3.4         [.] 0x000000000004b055  ▒ 
    0.10%   python3 [kernel.kallsyms]       [k] memset     ▒ 
    0.09%   python3 [kernel.kallsyms]       [k] copy_user_generic_string ▒ 
    0.07%   python3 multiarray.cpython-34m-x86_64-linux-gnu.so [.] 0x00000000000b4134  ▒ 
    0.06%   python3 [kernel.kallsyms]       [k] _raw_spin_unlock_irqresto▒ 
    0.06%   python3 python3.4         [.] PyEval_EvalFrameEx  

ऐसा लगता है जैसे कि समय के सबसे _raw_spin_lock_irqsave बुला खर्च किया जाता है:और इस perf report -g graph द्वारा रिपोर्ट है। मुझे नहीं पता कि इसका क्या अर्थ है, यद्यपि।

Answer 1

यदि समस्या कर्नेल में मौजूद है, तो आपको OPRofile या perf जैसे प्रोफाइलर का उपयोग करके समस्या को कम करना चाहिए।

आईई। perf record -a -g चलाएं और perf report का उपयोग करके perf data में सहेजे गए प्रोफाइलिंग डेटा को पढ़ने से पहले। यह भी देखें: linux perf: how to interpret and find hotspots।

---

अपने मामले उच्च CPU उपयोग में /dev/urandom के लिए प्रतिस्पर्धा के कारण होता है - यह केवल एक धागा यह से पढ़ने के लिए अनुमति देता है, लेकिन कई अजगर प्रक्रियाओं ऐसा कर रहे हैं।

पायथन मॉड्यूल random केवल प्रारंभ के लिए इसका उपयोग कर रहा है। मैं।ई:

$ strace python -c 'import random; 
while True: 
    random.random()' 
open("/dev/urandom", O_RDONLY)  = 4 
read(4, "\16\36\366\36}"..., 2500) = 2500 
close(4)         <--- /dev/urandom is closed 

तुम भी स्पष्ट रूप से os.urandom या SystemRandom वर्ग का उपयोग करके /dev/urandom के लिए कह सकता है। तो यादृच्छिक संख्या से निपटने वाला अपना कोड जांचें।