2010-06-30 8 views
6

मेरे पास एक जावा एप्लिकेशन है जिसमें पंद्रह का एक निश्चित थ्रेड पूल है, मशीन, सोलारिस 10 एसपीएआरसी में सोलह सीपीयू हैं। पूल जोड़ने से प्रदर्शन में काफी वृद्धि हुई है, लेकिन मुझे आश्चर्य है कि मेरे पास पूल में बहुत सारे धागे हैं। प्रदर्शन कम धागे के साथ बेहतर होगा या सोलारिस थ्रेड शेड्यूलिंग का अच्छा काम करेगा।सॉलारिस पर जावा थ्रेड्स से सीपीयू का अच्छा अनुपात क्या है?

कहें कि पूल पंद्रह सीपीयू का उपयोग कर भारी है, तो अन्य अनुप्रयोग धागे विभिन्न कारणों से सीपीयू की मांग करते हैं, समवर्ती कचरा संग्रह एक अच्छा उदाहरण है। अब, पूल और अन्य अनुप्रयोग धागे के बीच पांच सीपीयू साझा किए जाते हैं। फिर सीपीयू एक से सात मुक्त हो जाते हैं, क्या सोलारिस व्यस्त सीपीयू पर मुफ्त CPUs पर साझा करने वाले थ्रेड को स्थानांतरित कर देगा?

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

+0

@paxdiablo: ओह हाँ, संपादन के लिए धन्यवाद, मैं यह पता लगाने के लिए अपने सिर खरोंच कर रहा था कि "सोलारिस 10 स्पार्क" क्या था ... @ कैज़ेन सोज: प्रति सीपीयू कितने कोर? @ एसओ समुदाय: कोर विश्लेषण के लिए धागे प्रदर्शन विश्लेषण के लिए कम प्रासंगिक है? – bakkal

+0

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

उत्तर

4

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

आईओ करने वाले थ्रेड के लिए यह वास्तव में आसान नहीं है, आपको सर्वोत्तम आकार का परीक्षण करना होगा।
पुस्तक Java concurrency in practice प्रारंभिक बिंदु के रूप में इस एल्गोरिथ्म पता चलता है:

N = number of CPUs 
U = target CPU utilization (0 <= U <= 1) 
W/C = ration of wait time to cpu time (measured through profiling) 

threads = N * U * (1 + W/C) 

आईबीएम उनके लेख Java theory and practice: Thread pools and work queues में एक ही एल्गोरिथ्म का उपयोग करता, एक निश्चित यू = 1 के साथ। एनएस 1 तथ्य दोनों आईबीएम लेख में भी पढ़ा जा सकता है, दोनों सिद्धांतों के लिए मूल प्रदान करने के लिए।

-3

आम तौर पर, यदि आप थ्रेड और सीपीयू के बीच 1 से 1 मैपिंग स्थापित कर सकते हैं, तो आपको इष्टतम प्रदर्शन मिलेगा। यह माना जा रहा है कि उपयोगकर्ता थ्रेड को कर्नेल थ्रेड के साथ 1 से 1 मैप किया जाता है। अगर मुझे सही ढंग से याद किया जाता है, तो सोलारिस एकाधिक कर्नेल धागे के साथ-साथ उपयोगकर्ता धागे की अनुमति देता है, इसलिए आपको इस संबंध में ठीक होना चाहिए। जब आप एक से अधिक धागे एक ही सीपीयू का उपयोग कर रहे हों तो आप बाधाओं में भाग लेंगे।

हमेशा के रूप में, थ्रेड पूल आकार को कम करने के बारे में आपके प्रश्न की सबसे अच्छी सलाह है: "इसे आज़माएं और बेंचमार्क करें।" (लेकिन मुझे संदेह है कि इस मामले में और बेहतर होगा।)

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

संपादित करें: Here सूर्य से एक लिंक है कि कैसे सोलारिस और जावा थ्रेड मॉडल इंटरैक्ट करते हैं।

+0

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

1

आमतौर पर सीपीयू की तुलना में कुछ और धागे होने के लिए ठीक है, यह वास्तव में समग्र थ्रूपुट में मदद कर सकता है।

इसका कारण यह है कि आईओ पर कई धागे अवरुद्ध किए जा सकते हैं या किसी भी समय सो रहे हैं। इसलिए निष्पादित करने के लिए तैयार कुछ और धागे कभी दर्द नहीं करते हैं।

+0

पी। दूसरी बात यह है कि थ्रेड ओवरहेड आजकल बहुत छोटा है, मामूली कैश कोहेरेंसी प्रभाव के अलावा थ्रेड गिनती को कम रखने के लिए बहुत कम वास्तविक लाभ है। – mikera

+0

धागे का उपयोग करने में मुख्य लागत सॉफ़्टवेयर की जटिलता है, क्योंकि अचानक आपको समवर्तीता के बारे में सोचना पड़ता है। – samoz

+2

@samoz - सच है, लेकिन "विचार जटिलता" लागत मोटे तौर पर समान है चाहे आप 2, 16, या 1000 धागे का उपयोग कर रहे हों। लगभग सभी थ्रेडस्फीटी मुद्दे एक साधारण बाइनरी चीज हैं जो * एक से अधिक * धागे पर निर्भर करता है। यह एक असामान्य मुद्दा है जो हमेशा 32 धागे के साथ काम करेगा लेकिन (संभावित रूप से) 33 या उससे अधिक के साथ तोड़ देगा ... –

संबंधित मुद्दे