2010-05-13 7 views
6

मैं 24 कोर के साथ साझा लिनक्स कंप्यूटर पर बड़े पैमाने पर समांतर वैज्ञानिक कंप्यूटिंग नौकरियां चलाता हूं। ज्यादातर समय मेरी नौकरियां 24 कोर तक स्केल करने में सक्षम होती हैं जब इस कंप्यूटर पर कुछ भी नहीं चल रहा है। हालांकि, ऐसा लगता है कि यहां तक ​​कि एक सिंगल थ्रेडेड जॉब जो मेरा नहीं है, मेरी 24-थ्रेड जॉब्स (जो मैंने उच्च अच्छे मूल्यों के लिए सेट की है) केवल ~ 1800% सीपीयू (लिनक्स नोटेशन का उपयोग करके) प्राप्त करने में कामयाब होती है। इस बीच, लगभग 500% CPU चक्र (फिर से, लिनक्स नोटेशन का उपयोग करके) निष्क्रिय हैं। क्या कोई इस व्यवहार को समझा सकता है और मैं उन 23 कोरों को प्राप्त करने के लिए इसके बारे में क्या कर सकता हूं जिनका उपयोग किसी और द्वारा नहीं किया जा रहा है?लिनक्स 2.6.31 शेड्यूलर और मल्टीथ्रेडेड जॉब्स

नोट्स:

  1. मामले में यह प्रासंगिक है, मैं इस पर गौर किया थोड़ा अलग कर्नेल संस्करणों, हालांकि मैं जो मेरे सिर के ऊपर से याद नहीं कर सकते।

  2. सीपीयू आर्किटेक्चर x64 है। क्या यह संभव है कि तथ्य यह है कि मेरी 24-कोर नौकरियां 32-बिट हैं और अन्य नौकरियां जो मैं प्रतिस्पर्धा कर रहा हूं/64-बिट प्रासंगिक हैं?

संपादित करें: एक बात मैंने अभी देखा है कि 30 धागे तक जाने से समस्या कुछ हद तक कम हो जाती है। यह मुझे ~ 2100% सीपीयू तक ले जाता है।

+0

केवल उन्हीं प्रक्रियाओं को पुन: नज़रअंदाज़ करते हैं जिन्हें आप _own_ करते हैं, यदि केवल एक ही प्रक्रिया चल रही है जो n धागे को स्पॉन्स करता है .. अच्छा .. आप केवल एक ही प्रक्रिया के साथ प्रतिस्पर्धा करते हैं। क्या इस मशीन पर रूट/सूडो उपलब्ध है? –

+0

क्या होता है यदि आप 23 धागे तक गिर जाते हैं, तो दूसरी नौकरी के लिए एक कोर उपलब्ध है? – caf

उत्तर

6

यह संभव है कि शेड्यूलर आपके प्रत्येक कार्य को उसी CPU पर चलने की कोशिश कर रहा है जो पहले चल रहा था (ऐसा इसलिए होता है क्योंकि कार्य संभवतः उस CPU के कैश में अपना काम सेट लाया है - यह "कैश गर्म" है)।

यहाँ कुछ विचारों है तुम कोशिश कर सकते हैं:

  • भागो दो बार के रूप में कई धागे के रूप में आप कोर है;
  • आपके पास कोर की तुलना में एक या दो कम धागे चलाएं;
  • /proc/sys/kernel/sched_migration_cost (शायद नीचे शून्य तक) के मान को कम करें;
  • करीब करने के लिए 100.
0

यह पता लगाने के लिए mpstat (sysstat पैकेज का हिस्सा) का उपयोग करने के लिए उपयुक्त हो सकता है, यह पता लगाने के लिए कि क्या आपके पास पूरे सीपीयू निष्क्रिय हैं जबकि अन्य पूरी तरह से उपयोग किए जाते हैं। यह आपको शीर्ष या vmstat की तुलना में उपयोग का अधिक विस्तृत दृश्य देना चाहिए: प्रति पंक्ति 1 लाइन देखने के लिए mpstat -P ALL चलाएं।

एक प्रयोग के रूप में, आप प्रत्येक थ्रेड पर सीपीयू एफ़िनिटी सेट करने का प्रयास कर सकते हैं जैसे प्रत्येक एक अलग CPU से बंधे हैं; यह आपको यह देखने देगा कि प्रदर्शन कैसा है जैसे कि आप कर्नेल शेड्यूलर को यह तय नहीं करते कि कौन सी सीपीयू एक कार्य निर्धारित है। यह एक अच्छा स्थायी समाधान नहीं है, लेकिन यदि यह बहुत मदद करता है तो यह आपको एक विचार देता है कि शेड्यूलर कहां कम हो रहा है।

+0

दुर्भाग्य से मेरे पास व्यवस्थापकीय विशेषाधिकार नहीं हैं और sysstat स्थापित नहीं है। – dsimcha

+1

स्रोत से sysstat बनाना मुश्किल नहीं है। –

2

क्या आपके धागे को सिंक्रनाइज़ करना है? यदि ऐसा है, तो आपको निम्न समस्या हो सकती है:

मान लें कि आपके पास 4-सीपीयू सिस्टम और 4-थ्रेड नौकरी है। अकेले भागते समय, सभी 4 कोर का उपयोग करने के लिए धागे प्रशंसक होते हैं और कुल उपयोग सही होता है (हम इसे 400% कहते हैं)।

यदि आप एक सिंगल थ्रेडेड इंटरफेयरिंग जॉब जोड़ते हैं, तो शेड्यूलर आपके 2 थ्रेड को उसी सीपीयू पर रख सकता है। इसका मतलब है कि आपके 2 धागे अब प्रभावी रूप से आधे सामान्य गति (नाटकीय सरलीकरण) पर चल रहे हैं, और यदि आपके धागे को समय-समय पर सिंक्रनाइज़ करने की आवश्यकता है, तो आपके काम की प्रगति धीमी धागे से सीमित हो सकती है, जो इस मामले में चल रही है आधा सामान्य गति। आप केवल 200% (आपके काम से 4x 50% चल रहे हैं) के साथ 100% (हस्तक्षेप नौकरी) = 300% का उपयोग देखेंगे।

इसी प्रकार, यदि आप मानते हैं कि हस्तक्षेप नौकरी केवल एक प्रोसेसर के समय का 25% उपयोग करती है, तो आप अपने एक थ्रेड और एक ही CPU पर हस्तक्षेप देख सकते हैं। उस स्थिति में सबसे धीमी धागा 3/4 सामान्य गति पर चल रहा है, जिससे कुल उपयोग 300% (4x 75%) + 25% = 325% हो सकता है। इन संख्याओं के साथ खेलें और जो कुछ आप देख रहे हैं उसके समान कुछ के साथ आना मुश्किल नहीं है।

यदि यह समस्या है, तो आप अनचाहे कार्यों को केवल उपलब्ध CPU के केवल छोटे अंशों को देने के लिए प्राथमिकताओं के साथ खेल सकते हैं (मुझे लगता है कि I/O देरी कारक नहीं हैं)। या, जैसा कि आपने पाया है, थ्रेड को बढ़ाने की कोशिश करें ताकि प्रत्येक सीपीयू में, 2 थ्रेड, सिस्टम कार्यों के लिए अनुमति देने के लिए कुछ कम करें। इस तरह एक 24 कोर सिस्टम 46 थ्रेड के साथ सबसे अच्छा चल सकता है (जो हमेशा सिस्टम कार्यों के लिए उपलब्ध 2 कोर का आधा समय छोड़ देता है)।

+0

बेशक, 23 धागे के कैफे का सुझाव संभवतः 23 धागे के 23 सुझावों के उपयोग के रूप में 46 धागे के सुझाव से बेहतर है। –

0

नीचे /proc/sys/kernel/sched_domain/.../imbalance_pct का मूल्य कम क्या आपको लगता है टोंटी आपके आवेदन या कर्नेल का समय निर्धारण एल्गोरिथ्म में है? शेड्यूलिंग पैरामीटर को ट्वीक करना शुरू करने से पहले, मेरा सुझाव है कि आप एक साधारण मल्टी-थ्रेडेड एप्लिकेशन को चलाने का प्रयास करें ताकि यह देखने के लिए कि यह आपके एप्लिकेशन के समान व्यवहार दिखाता है या नहीं।

// COMPILE WITH: gcc threads.c -lpthread -o thread 
#include <pthread.h> 
#define NUM_CORES 24 

void* loop_forever(void* argument) { 
    int a; 
    while(1) a++; 
} 

void main() { 
    int i; 
    pthread_t threads[NUM_CORES]; 

    for (i = 0; i < NUM_CORES; i++) 
     pthread_create(&threads[i], 0, loop_forever, 0); 

    for (i = 0; i < NUM_CORES; i++) 
     pthread_join(threads[i], 0); 
} 
1

क्या आपके धागे एक दूसरे के साथ संवाद करते हैं?

sched_setaffinity या pthread_setaffinity_np के साथ, प्रत्येक थ्रेड को सीपीयू में मैन्युअल रूप से बांधने का प्रयास करें। थ्रेड से संबंधित बहुत से काम करते समय शेड्यूलर गूंगा हो सकता है।