2008-09-19 13 views
19

मुझे आश्चर्य है, जावा 1.6 x64 में प्रतीक्षा स्थिति में कई धागे कितना महंगा है।कितने संसाधन सोते हैं और प्रतीक्षा थ्रेड

अधिक विशिष्ट होने के लिए, मैं ऐसे एप्लिकेशन लिख रहा हूं जो कई कंप्यूटरों पर चलता है और डेटा को एक से दूसरे में भेजता/प्राप्त करता है। मुझे प्रत्येक कनेक्टेड मशीन और कार्य के लिए अलग थ्रेड रखने में अधिक सहज महसूस होता है, जैसे 1) डेटा भेजना, 2) डेटा प्राप्त करना, 3) इसे छोड़ने पर कनेक्शन को पुन: स्थापित करना। इसलिए, क्लस्टर में एन नोड्स दिए गए हैं, प्रत्येक मशीन में प्रत्येक एन-पड़ोसी पड़ोसियों के लिए 3 धागे होंगे। आम तौर पर 12 मशीनें होंगी, जो 33 संचार धागे पर आती हैं।

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

तो क्या कई सोने के थ्रेड होने पर कोई महत्वपूर्ण प्रभाव पड़ता है?

उत्तर

15

ज्यादातर मामलों के लिए, सोने के धागे से खपत संसाधन इसकी स्टैक स्पेस होंगे। एक 2-थ्रेड्स-प्रति-कनेक्शन-मॉडल का उपयोग करना, जो मुझे लगता है कि आप जो वर्णन कर रहे हैं उसके समान है, इस कारण के लिए बड़ी स्केलेबिलिटी समस्याएं पैदा होती हैं जब कनेक्शन की संख्या बड़ी हो जाती है।

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

यदि आपको बड़ी संख्या में कनेक्शन की आवश्यकता है, तो जावा एनआईओ (नया आईओ या जो कुछ भी) जाने का तरीका है, जिससे एक ही धागे में कई कनेक्शन को संभालना संभव हो जाता है।

ऐसा कहकर, आपको एक उचित आधुनिक सर्वर पर 100 धागे के तहत किसी समस्या का सामना नहीं करना चाहिए, भले ही यह अभी भी संसाधनों का अपशिष्ट हो।

+0

JRocikt JVM का उपयोग नहीं करना चाहिए इन समस्याओं को हल करें - जैसा कि मैंने पढ़ा है इसे हजारों धागे को संभालने के लिए डिज़ाइन किया गया था। –

+0

मुझे जेआरॉकिट जेवीएम के साथ कोई अनुभव नहीं है, इसलिए मैं वास्तव में उस पर टिप्पणी नहीं कर सकता। ऐसा कहकर, मुझे पता है कि अधिकांश ऑपरेटिंग सिस्टम हजारों धागे से खराब प्रदर्शन करेंगे, इसलिए मुझे नहीं पता कि जेआरॉकिट उस समस्या के आसपास कैसे हो जाता है ... – Liedman

+0

64 बिट सर्वर अब मानक हैं। मुझे आश्चर्य है कि ओओएम बड़े पते के कारण अंतरिक्ष आवश्यकताओं के कारण कोई मुद्दा नहीं है। – Raedwald

1

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

+1

क्या आप सुनिश्चित हैं कि डब्ल्यूएआईटी राज्य में धागे संदर्भ-स्विचिंग ओवरहेड बढ़ाते हैं? – Grigory

1

बहुत सारे धागे बहुत सारी स्टैक स्पेस के बराबर हैं, जो आपकी याददाश्त खाएंगे - गणित करने के लिए अपनी -Xss सेटिंग्स को देखें, फिर गणित करें।

और यदि आपको किसी कारण से सभी को सूचित करना है, तो निश्चित रूप से आप अतिरिक्त धागे के भार को जाग रहे हैं - हालांकि आपको अपने प्रस्तावित वास्तुकला में ऐसा करने की आवश्यकता नहीं हो सकती है।

मुझे यकीन नहीं है कि आप आसानी से इस मॉडल में एक थ्रेड प्रति सुनने सॉकेट रखने से बच सकते हैं (हालांकि मुझे एनआईओ के बारे में बहुत कम पता है - जो उस मुद्दे को भी ठीक कर सकता है), लेकिन java.util.concurrent.Executor इंटरफ़ेस और इसके कार्यान्वयन पर नज़र डालें चारों ओर लटकने वाले बहुत से अतिरिक्त धागे होने से बचने के लिए एक सभ्य तरीके से कक्षाएं। दरअसल, ThreadPoolExecutor आपके सुनने वाले धागे को प्रबंधित करने का एक अच्छा तरीका भी हो सकता है, इसलिए आप थ्रेड को असफल रूप से बनाने और नष्ट करने में बहुत अधिक समय नहीं लगाते हैं।

2

हम एनआईओ पर स्विच करने से पहले हमें एक ही समस्या थी, इसलिए मैं उस ढांचे के साथ जाने के लिए दूसरी लीडमैन की सिफारिश करूंगा।आपको एक ट्यूटोरियल ढूंढने में सक्षम होना चाहिए, लेकिन यदि आप विवरण चाहते हैं, तो मैं रॉन हिचेन्स द्वारा Java NIO की सिफारिश कर सकता हूं।

एनआईओ को स्विथस करने से कनेक्शन की संख्या में वृद्धि हुई जो हम बहुत संभाल सकते थे, जो हमारे लिए वास्तव में महत्वपूर्ण था।

0

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

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