2012-05-18 27 views
12

पर मेरे पास एक सी # सर्वर विजुअल स्टूडियो 2010 और मोनो डेवलपमेंट 2.8 दोनों पर विकसित हुआ है। नेट फ्रेमवर्क 4.0सी # सर्वर स्केलेबिलिटी मुद्दा लिनक्स

ऐसा लगता है कि यह सर्वर लिनक्स की तुलना में विंडोज पर बहुत बेहतर (स्केलेबिलिटी के मामले में) व्यवहार करता है। मैंने अपाचे के एबी टूल का उपयोग करते हुए मूल विंडोज (12 भौतिक कोर) पर सर्वर स्केलेबिलिटी और 8 और 12 कोर विंडोज और उबंटू वर्चुअल मशीनों का परीक्षण किया।

विंडोज प्रतिक्रिया समय काफी सुंदर है। जब यह समेकन स्तर कोर की संख्या तक पहुंचता है/उससे अधिक होता है तो यह उठना शुरू होता है।

किसी कारण से लिनक्स प्रतिक्रिया समय बहुत खराब है। वे समेकन के स्तर 5 से बहुत अधिक रैखिक रूप से बढ़ते हैं। इसके अलावा 8 और 12 कोर लिनक्स वीएम समान व्यवहार करते हैं।

तो मेरा सवाल है: यह लिनक्स पर क्यों खराब प्रदर्शन करता है? (और मैं इसे कैसे ठीक कर सकता हूं?)।

कृपया संलग्न ग्राफ पर एक नज़र डालें, यह अनुरोधों के एक समारोह के रूप में 75% अनुरोधों को पूरा करने के लिए औसत समय दिखाता है (रेंज बार 50% और 100% पर सेट है)। time to fulfill 75% of the request as a function of the request concurrency

मुझे लगता है कि यह मोनो कचरा कलेक्टर के कारण हो सकता है। मैंने जीसी सेटिंग्स के साथ खेलने की कोशिश की लेकिन मुझे कोई सफलता नहीं मिली। कोई सुझाव?

कुछ अतिरिक्त पृष्ठभूमि जानकारी: सर्वर एक HTTP श्रोता पर आधारित है जो जल्दी से अनुरोधों को पार करता है और उन्हें थ्रेड पूल पर कतार देता है। थ्रेड पूल कुछ गहन गणित (~ 10secs में एक उत्तर की गणना) के साथ उन अनुरोधों का उत्तर देने का ख्याल रखता है।

+1

"सी # सर्वर" क्या है? क्या यह सर्वर से अलग है? मेरा मतलब है, आपके शीर्षक में, "सी #" एक विशेषण के रूप में इस्तेमाल किया जा रहा है? एक "सी # सर्वर" एक प्रकार का सर्वर है? –

+0

> कुछ गहन गणित (~ 10secs में एक उत्तर की गणना)। मुझे लगता है कि आपकी समस्या है .. यह सर्वर के लिए सामान्य परिदृश्य नहीं है। आपके भौतिक हार्डवेयर के कितने कोर हैं, 12? ग्राफ 10 समवर्ती अनुरोधों के बाद कैसा दिखता है? – Soonts

+0

जैसा कि मुझे पता है, मोनो इन उपयोगों के लिए उपयुक्त नहीं है। मोनो का विकास छोटे डेस्कटॉप अनुप्रयोगों में केंद्रित है। मुझे यह जानकारी मोनो के डेवलपर से मिलती है, मैं अधिक जानकारी ढूंढने की कोशिश करूंगा और अगर मुझे लगता है तो यहां पोस्ट करेंगे। – LawfulHacker

उत्तर

4

आपको समस्या को पहले स्थानांतरित करने की आवश्यकता है। HeapShot के साथ अपने मेमोरी उपयोग की निगरानी करके शुरू करें। यदि यह स्मृति नहीं है, तो समय लेने वाली विधियों को इंगित करने के लिए अपने कोड को प्रोफाइल करें।

यह पृष्ठ, Performance Tips: Writing better performing .NET and Mono applications, इसमें मोनो प्रोफाइलर का उपयोग करने सहित कुछ उपयोगी जानकारी शामिल हैं।

अत्यधिक स्ट्रिंग मैनिपुलेशन और बॉक्सिंग अक्सर कोड के 'छिपा' अपराधी होते हैं जो अच्छी तरह से स्केल नहीं करते हैं।

+0

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

+0

मैंने जीसी व्यवहार को प्रोफाइल करने के लिए आपके द्वारा सुझाए गए टूल (हेपशॉट) का उपयोग किया था। ऐसा लगता है कि सर्वर पर भेजे गए प्रत्येक 20 अनुरोधों के लिए ~ 10 कचरा संग्रह हैं। इनमें से प्रत्येक जीसी घटनाएं 10 एमबी रैम से कम हैंडल करती हैं। अधिकांश काम सिस्टम को मुक्त कर दिया जाता है। सिंगल []। वैसे भी यह मुझे लगता है कि सर्वर स्केलेबिलिटी को प्रभावित करने के लिए ये स्मृति घटनाएं बहुत दुर्लभ हैं। तुम क्या सोचते हो? – Enio

1

sgen कचरा कलेक्टर (और इसके लिए, मोनो 2.11.x की अनुशंसा की जाती है) आज़माएं। अधिक जानकारी के लिए मोनो मैन पेज देखें।

+0

धन्यवाद। मैंने मोनो - जीसी = एसजेएन के साथ दौड़ने की कोशिश की। दुर्भाग्यवश व्यवहार अभी भी वही है – Enio

+0

मोनो का कौन सा संस्करण? – knocte

+0

एक अन्य विकल्प जिसे आप कोशिश कर सकते हैं वह है एलएलवीएम बैकएंड – knocte

1

मुझे विश्वास नहीं है कि यह जीसी की वजह से है। AFAIK जीसी साइड इफेक्ट्स को धागे में समान रूप से वितरित किया जाना चाहिए।

मेरा अंधा अनुमान है: आप इसे थ्रेडपूल.SetMinThreads/SetMaxThreads API के साथ खेलकर ठीक कर सकते हैं।

+0

मैंने न्यूनतम/अधिकतम काम/आईओ धागे की संख्या को अलग करने की कोशिश की और ऐसा लगता है कि स्केलेबिलिटी पर एक (सकारात्मक) प्रभाव नहीं है। लेकिन फिर भी धन्यवाद। बीटीडब्ल्यू प्रभाव सभी धागे में समान रूप से वितरित किया जाता है: कृपया समयावधि 9-10 पर ब्राउन और नारंगी घटता (मोनो पर वाले) पर त्रुटि बार देखें। आप देख सकते हैं कि सभी अनुरोधों के लिए उत्तर समय कितना ही समान है। – Enio

+0

ठीक है, मेरा अंधेरा अनुमान # 2: आई/ओ पूरा करने वाले बंदरगाहों (.NET CLR थ्रेड पूल द्वारा उपयोग किया गया) का आविष्कार 1 99 3 (विंडोज एनटी 3.5) में किया गया था और उस समय से ठीक ट्यून और डिबग किया गया है। ओटीओएच, एपोल (आईओसीपी क्लोन, जो मोनो द्वारा उसी उद्देश्य के लिए उपयोग किया जाता है) 2002 से ही यहां है, इसलिए विंडोज आईओसीपी बस बेहतर है। लिनक्स पर, समवर्ती अनुरोध * 2 Soonts

+0

बीटीडब्लू, जब बेंचमार्किंग, क्या आप सभी अनुरोध एक साथ शुरू करते हैं? यदि आप उन्हें 1-2 सेकंड अंतराल में एक दूसरे के बाद लॉन्च करेंगे तो क्या परिवर्तन होंगे? – Soonts

0

आप कोड अपवाद का एक बहुत फेंकता है, तो मोनो 10x नेट

+2

यह कमाल है! लेकिन मेरी समस्या विपरीत है: सर्वर स्केलेबिलिटी मोनो/लिनक्स की तुलना में विंडोज़ पर बहुत बेहतर है। – Enio

1

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

1

मेरा मानना ​​है कि यह वही समस्या हो सकती है जिसे हमने थ्रेड पूल और नए धागे के लिए प्रारंभिक व्यवहार, साथ ही साथ सेटमिन थ्रेड के मोनो कार्यान्वयन में एक बग को ट्रैक किया है।अधिक जानकारी के लिए कृपया उस धागे पर मेरा उत्तर देखें: https://stackoverflow.com/a/12371795/1663096