2012-12-12 46 views
25

परिदृश्य की: मैं एक नमूना आवेदन है और मैं 3 अलग सिस्टम विन्यास है -संख्या के आधार पर थ्रेड कॉन्फ़िगरेशन। सीपीयू कोर

- 2 core processor, 2 GB RAM, 60 GB HHD, 
- 4 core processor, 4 GB RAM, 80 GB HHD, 
- 8 core processor, 8 GB RAM, 120 GB HHD 

आदेश में प्रभावी रूप अपने आवेदन के लिए एच/डब्ल्यू क्षमताओं का दोहन करने में, मैं कोई कॉन्फ़िगर करना चाहते हैं। आवेदन स्तर पर धागे के। हालांकि, मैं सिस्टम क्षमताओं की पूरी तरह समझने के बाद ही ऐसा करना चाहता हूं।

अधिकतम और न्यूनतम संख्या के संदर्भ में सिस्टम कौशल निर्धारित करने के लिए कुछ तरीका (सिस्टम/मोडस/टूल) हो सकता है। धागे की यह दक्षता और प्रदर्शन में किसी भी नुकसान के बिना & सेवा कर सकता है। इसके द्वारा, मैं केवल अपने मूल्य के लिए उन मानों को कॉन्फ़िगर कर सकता हूं जो पूर्ण न्याय करेंगे और संबंधित हार्डवेयर कॉन्फ़िगरेशन के लिए सर्वश्रेष्ठ प्रदर्शन प्राप्त करेंगे।

Edited1: किसी भी एक कैसे/एक विशेष ज के लिए एक आधार रेखा सेट करने के लिए डब्ल्यू config पर किसी भी पढ़ने-अप की सलाह कृपया सकते हैं।

Edited2: बनाने के लिए इसे और अधिक प्रत्यक्ष - सीखना/किसी भी संसाधन/लिखने-अप है कि मैं एक सामान्य/समग्र स्तर पर धागे की सीपीयू प्रबंधन पर कुछ समझ हासिल करने के पढ़ सकते हैं के बारे में पता करने के लिए कामना करते हैं। है दुर्भाग्य से नहीं तुच्छ तथापि

Runtime.getRuntime().availableProcessors() 

उपलब्ध प्रोसेसर की संख्या से धागे के इष्टतम संख्या की गणना:

+0

मैं न्यूनतम संख्या के लिए इष्टतम मान खोजना चाहता हूं। थ्रेड/अधिकतम संख्या का। सर्वोत्तम प्रदर्शन और पूर्ण संसाधन उपयोग प्राप्त करने के लिए उपर्युक्त सिस्टम कॉन्फ़िगरेशन के आधार पर नमूना अनुप्रयोग के लिए थ्रेड का। – Santosh

+1

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

उत्तर

57

उपयोग करने के लिए धागे की इष्टतम संख्या कई कारकों पर निर्भर करती है, लेकिन अधिकांशतः उपलब्ध प्रोसेसर की संख्या और आपके कार्यों को सीपीयू-गहन कैसे किया जाता है।

N_threads = N_cpu * U_cpu * (1 + W/C) 

कहाँ:

  • N_threads धागे की इष्टतम संख्या
  • N_cpu prcessors की संख्या है, जो आप प्राप्त कर सकते हैं है Java Concurrency in Practice धागे की इष्टतम संख्या का अनुमान लगाने के लिए निम्न औपचारिक सूत्र का प्रस्ताव Runtime.getRuntime().availableProcessors(); से
  • U_cpu (आप पूर्ण उपलब्ध संसाधनों का उपयोग करना चाहते हैं 1) लक्ष्य CPU उपयोग है
  • डब्ल्यू/सी टी है वह समय गणना करने के लिए प्रतीक्षा समय का अनुपात (सीपीयू-बाध्य कार्य के लिए 0, शायद धीमी I/O कार्यों के लिए 10 या 100)

तो उदाहरण के लिए, एक सीपीयू-बाउंड परिदृश्य में, आपके पास कई धागे होंगे सीपीयू के रूप में (कुछ वकील उस नंबर + 1 का उपयोग करने के लिए लेकिन मैंने कभी नहीं देखा है कि यह एक महत्वपूर्ण अंतर बना है)।

धीमी आई/ओ प्रक्रिया के लिए, उदाहरण के लिए एक वेब क्रॉलर, डब्ल्यू/सी एक पृष्ठ डाउनलोड करने पर 10 हो सकता है, इसे प्रोसेस करने से 10 गुना धीमा है, इस मामले में 100 धागे का उपयोग करना उपयोगी होगा।

नोट तथापि है कि वहाँ व्यवहार में एक ऊपरी बाध्य (10,000 धागे का उपयोग कर आम तौर पर चीज़ों को गति नहीं होगा, और आप शायद एक OutOfMemoryError मिल इससे पहले कि आप सामान्य स्मृति सेटिंग्स के साथ वैसे भी उन सब को शुरू कर सकते हैं होगा)।

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

हालांकि सख्ती से संबंधित नहीं है, तो आपको Amdahl's law में भी रुचि हो सकती है, जिसका उद्देश्य अधिकतम गति-माप को मापना है जिसे आप प्रोग्राम के समानांतर करने की अपेक्षा कर सकते हैं।

+2

आह, अच्छा बिंदु, मेरी पिछली टिप्पणी को हटा रहा है। –

+0

मैं डब्ल्यू/सी का अनुमान कैसे प्राप्त करूं? क्या मुझे सटीक समय I/O बनाम कंप्यूटिंग लेने की आवश्यकता है? – AgentX

14

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

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

+0

खान एक सीपीयू गहन प्रक्रिया है। साथ ही, क्या मुझे किसी विशेष एच/डब्ल्यू कॉन्फ़िगरेशन के लिए बेसलाइन सेट करने के बारे में कोई भी पढ़ा जा सकता है। कोई भी तरीका जिसमें मैं यह पता लगा सकता हूं कि कोई विशेष प्रोसेसर अपने सभी उपलब्ध संसाधनों का उपयोग कर सकता है या किसी अन्य सॉफ़्टवेयर के चलते अवरुद्ध हो सकता है। – Santosh

+3

@ सैंटोश यदि यह सीपीयू गहन है, तो 'उपलब्ध प्रोसेसर()' थ्रेड की संख्या का उपयोग इष्टतम के करीब होना चाहिए। – assylias

+0

मैं आमतौर पर आईओओ या कुछ पर थ्रेड को अवरुद्ध होने पर शेड्यूलिंग ढलान लेने के लिए एक छोटा स्थिर कारक जोड़ता हूं ... –

2

धागे की निगरानी के लिए VisualVm उपकरण का उपयोग करें। सबसे पहले कार्यक्रम में न्यूनतम धागे बनाएं और इसके प्रदर्शन को देखें। फिर प्रोग्राम के भीतर धागे की संख्या को फिर से बढ़ाने के प्रदर्शन का विश्लेषण करें। यह आपकी मदद कर सकता है।

15

मेरी सिफारिश प्रति मशीन थ्रेड की संख्या निर्दिष्ट करने के लिए कॉन्फ़िगरेशन और कमांड लाइन स्विच प्रदान करना है। Runtime.getRuntime() पर उपलब्ध एक ह्युरिस्टिक का उपयोग करें। उपलब्ध प्रोसेसर() जैसा कि अन्य उत्तरों द्वारा इंगित किया गया है, ऐसे मामलों में जहां उपयोगकर्ता/व्यवस्थापक ने स्पष्ट रूप से एप्लिकेशन को अलग-अलग कॉन्फ़िगर नहीं किया है। मैं दृढ़ता से खिलाफ सलाह देते हैं अनन्य अनुमानी आधारित धागा करने वाली कोर अनुमान लगा, कई कारणों से: इस तरह के इंटेल के रूप में श्रीमती मॉडल:

  • अधिकांश आधुनिक हार्डवेयर 'हार्डवेयर धागे' का तेजी से अस्पष्ट प्रकार ओर बढ़ रहा है हाइपरथ्रेडिंग और एएमडी के कंप्यूट मॉड्यूल सूत्रों को जटिल करते हैं (नीचे विवरण), और रनटाइम पर इस जानकारी को पूछना मुश्किल हो सकता है।

  • अधिकांश आधुनिक हार्डवेयर में टर्बो सुविधा होती है जो सक्रिय कोर और परिवेश तापमान के आधार पर गति को मापती है। जैसे-जैसे टर्बो तकनीक में सुधार होता है, गति की गति (ghz) बढ़ जाती है। कुछ हालिया इंटेल और एएमडी चिप्स 2.6ghz (सभी कोर सक्रिय) से 3.6ghz (एकल/दोहरी कोर सक्रिय) तक हो सकते हैं, जो एसएमटी के साथ संयुक्त हो सकता है, प्रत्येक थ्रेड का मतलब पूर्व डिजाइन में 1.6ghz - 2.0ghz throughput प्रभावी हो सकता है। रनटाइम पर इस जानकारी को क्वेरी करने का कोई तरीका नहीं है।

  • यदि आपके पास मजबूत गारंटी नहीं है कि आपका आवेदन लक्ष्य प्रणाली पर चलने वाली एकमात्र प्रक्रिया होगी, तो सभी सीपीयू संसाधनों को अंधाधुंध रूप से उपभोग करने से उपयोगकर्ता या सर्वर व्यवस्थापक को खुश नहीं किया जा सकता है (यदि सॉफ्टवेयर उपयोगकर्ता है ऐप या सर्वर ऐप)।

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

  • आधुनिक वायरस स्कैनर आधुनिक ऑपरेटिंग सिस्टम द्वारा प्रदान किए गए विशेष प्राथमिकता ध्वज को सेट करके आजकल काम करते हैं। उन्होंने ओएस को बताया कि "सिस्टम निष्क्रिय है"। ओएस केवल सीपीयू लोड से अधिक पर अपना निर्णय रखता है: यह उपयोगकर्ता इनपुट और मल्टीमीडिया झंडे को भी मानता है जो मूवी प्लेयर आदि द्वारा निर्धारित किए जा सकते हैं।यह ज्यादातर निष्क्रिय कार्यों के लिए ठीक है, लेकिन आपके जैसे सीपीयू गहन कार्य के लिए उपयोगी नहीं है।

  • वितरित घर कंप्यूटिंग ऐप्स (BOINC, Folding @ Home, आदि) चल रही प्रक्रियाओं और सिस्टम CPU लोड समय-समय पर क्वेरी करके काम करते हैं - एक बार हर सेकेंड या आधे सेकेंड में। यदि पंक्तियों में कई प्रश्नों के लिए ऐप से संबंधित प्रक्रियाओं पर लोड नहीं पता है तो ऐप गणना को निलंबित कर देगा। एक बार जब लोड कुछ प्रश्नों के लिए कम हो जाता है, तो यह फिर से शुरू होता है। एकाधिक प्रश्नों की आवश्यकता है क्योंकि सीपीयू लोड रीडआउट संक्षिप्त स्पाइक्स के लिए कुख्यात हैं। अभी भी चेतावनी हैं: 1. उपयोगकर्ताओं को अभी भी BOINC को मैन्युअल रूप से पुन: कॉन्फ़िगर करने के लिए प्रोत्साहित किया जाता है ताकि वे अपनी मशीन की चश्मा फिट कर सकें। 2. यदि BOINC व्यवस्थापक विशेषाधिकारों के बिना चलाया जाता है तो यह अन्य उपयोगकर्ताओं (कुछ सेवा प्रक्रियाओं सहित) द्वारा शुरू की गई प्रक्रियाओं से अवगत नहीं होगा, इसलिए यह CPU संसाधनों के लिए उन लोगों के साथ अनुचित रूप से प्रतिस्पर्धा कर सकता है।

के बारे में श्रीमती (हाइपरथ्रेडिंग, कंप्यूट मॉड्यूल):

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

के बारे में टर्बो विशेषताएं:

अधिकांश सीपीयू इन दिनों बहुत प्रभावी निर्मित टर्बो समर्थन आगे कम है कि है मूल्य प्राप्त की प्रणाली के सभी कोर भर में स्केलिंग से। इससे भी बदतर, टर्बो सुविधा कभी-कभी सिस्टम के वास्तविक तापमान पर जितनी अधिक होती है क्योंकि यह सीपीयू लोड पर होती है, इसलिए टावर की शीतलन प्रणाली सीपीयू चश्मे जितनी गति को प्रभावित करती है। एक विशेष एएमडी ए 10 (बुलडोजर) पर, उदाहरण के लिए, मैंने देखा कि यह दो धागे पर 3.7ghz पर चल रहा है। जब यह तीसरा धागा शुरू होता है, तो चौथाई शुरू होने पर 3.4ghz तक गिर जाता है। चूंकि यह एक एकीकृत जीपीयू भी है, इसलिए यह लगभग 3.0ghz तक गिर गया जब चार धागे और जीपीयू काम कर रहे थे (ए 10 सीपीयू आंतरिक रूप से उच्च लोड परिदृश्यों में जीपीयू को प्राथमिकता देता है); लेकिन अभी भी 2 धागे और जीपीयू सक्रिय के साथ 3.6ghz जरूरी हो सकता है। चूंकि मेरा एप्लिकेशन सीपीयू और जीपीयू दोनों का इस्तेमाल करता है, यह एक महत्वपूर्ण खोज थी। मैं प्रक्रिया को दो सीपीयू-बाउंड धागे तक सीमित करके समग्र प्रदर्शन में सुधार करने में सक्षम था (अन्य दो साझा कोर अभी भी सहायक थे, उन्होंने GPU सर्विसिंग थ्रेड्स के रूप में कार्य किया - जीपीयू को नए डेटा को धक्का देने के लिए जागने और प्रतिक्रिया देने में सक्षम, जैसी जरूरत थी)।

... लेकिन साथ ही, 4x थ्रेड पर मेरा एप्लिकेशन उच्च गुणवत्ता वाले शीतलन डिवाइस के साथ सिस्टम पर बहुत बेहतर प्रदर्शन कर सकता है। यह सब बहुत जटिल है।

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

4

मैं अन्य उत्तरों के साथ सहमत हूं जो सर्वोत्तम अनुमान दृष्टिकोण की सिफारिश करते हैं, और डिफ़ॉल्ट को ओवरराइड करने के लिए कॉन्फ़िगरेशन प्रदान करते हैं।

इसके अतिरिक्त, यदि आपका एप्लिकेशन विशेष रूप से सीपीयू-गहन है, तो आप अपने आवेदन को विशेष प्रोसेसर को "पिनिंग" करना चाहते हैं।

आप यह नहीं कहते कि आपका प्राथमिक ऑपरेटिंग सिस्टम क्या है, या आप कई ऑपरेटिंग सिस्टम का समर्थन कर रहे हैं, लेकिन अधिकांश को ऐसा करने का कोई तरीका है। उदाहरण के लिए, लिनक्स में taskset है।

एक सामान्य दृष्टिकोण सीपीयू 0 (हमेशा ओएस द्वारा उपयोग किया जाता है) से बचने के लिए है, और उसी सॉकेट में मौजूद CPUs के समूह में अपने एप्लिकेशन के सीपीयू एफ़िनिटी सेट करने के लिए है।

ऐप के धागे को cpu 0 से दूर रखना (और, यदि संभव हो, तो अन्य अनुप्रयोगों से दूर) अक्सर कार्य स्विचिंग की मात्रा को कम करके प्रदर्शन में सुधार करता है।

एक सॉकेट पर एप्लिकेशन को रखने से कैश अमान्यता को कम करके प्रदर्शन में वृद्धि हो सकती है क्योंकि आपके ऐप के थ्रेड सीपीयू के बीच स्विच होते हैं।

अन्य सभी चीज़ों के साथ, यह उस मशीन के आर्किटेक्चर पर अत्यधिक निर्भर है जिस पर आप चल रहे हैं, साथ ही साथ अन्य एप्लिकेशन क्या चल रहे हैं।

1

मैं अपने जावा एप्लिकेशन को इष्टतम पैरामीटर और एर्गोनॉमिक्स के साथ लॉन्च करने के लिए कोर (और मेमोरी इत्यादि) की संख्या निर्धारित करने के लिए यहां इस पायथन स्क्रिप्ट का उपयोग करता हूं। PlatformWise on Github

यह इस तरह काम करता है: एक अजगर स्क्रिप्ट जो कोर की संख्या प्राप्त करने ऊपर स्क्रिप्ट में getNumberOfCPUCores() कॉल लिखें, और getSystemMemoryInMB() रैम मिलता है। आप कमांड लाइन तर्कों के माध्यम से अपने प्रोग्राम को सूचित कर सकते हैं। आपका प्रोग्राम कोर की संख्या के आधार पर धागे की उचित संख्या का उपयोग कर सकता है।

1

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

मैं क्या लगता है कि:

  1. एक समय एक कार्यक्रम का केवल 1 धागा 1 कोर पर निष्पादित करेंगे पर।
  2. 2 धागे के साथ वही आवेदन 2 कोर पर आधे समय पर निष्पादित होगा।
  3. 4 थ्रेड के साथ वही एप्लिकेशन 4 कोर पर अधिक तेज़ी से निष्पादित करेगा।

तो आवेदन आप विकासशील सूत्रण स्तर < = कोर का कोई होना चाहिए।

थ्रेड निष्पादन समय ऑपरेटिंग सिस्टम द्वारा प्रबंधित किया जाता है और यह एक अत्यधिक अप्रत्याशित गतिविधि है। सीपीयू निष्पादन समय को समय स्लाइस या क्वांटम के रूप में जाना जाता है। यदि हम अधिक से अधिक धागे बनाते हैं तो ऑपरेटिंग सिस्टम इस समय का एक अंश खर्च करता है कि यह तय करने में कि कौन सा धागा पहले जाता है, इस प्रकार प्रत्येक थ्रेड को वास्तविक निष्पादन समय को कम करता है। दूसरे शब्दों में यदि थ्रेड कतार में बड़ी संख्या में थे तो प्रत्येक थ्रेड कम काम करेगा।

वास्तव में सीपीयू कोर का उपयोग करने के तरीके को पढ़ने के लिए इसे पढ़ें। फैंटास्टिक सामग्री। csharp-codesamples.com/2009/03/threading-on-multi-core-cpus/

1

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