लिनक्स प्रति-प्रक्रिया संसाधन सीमाएं - एक गहरी रेड हैट रहस्य

Question

मेरे पास अपना स्वयं का बहुप्रचारित सी प्रोग्राम है जो सीपीयू कोर की संख्या के साथ आसानी से गति में स्केल करता है .. मैं इसे 1, 2, 3, आदि थ्रेड के साथ चला सकता हूं और प्राप्त कर सकता हूं रैखिक गति .. उबंटू लिनक्स बॉक्स पर 6-कोर सीपीयू पर लगभग 5.5x की गति तक।

मुझे प्रोग्राम को चलाने के लिए एक उच्च अंत सनफियर x4450 पर 4 क्वाड-कोर ज़ीऑन प्रोसेसर के साथ चलाने का अवसर था, जो Red Hat Enterprise Linux चला रहा था। मैं बेसब्री से उम्मीद कर रहा था कि 16 कोर मेरे कार्यक्रम को 16 धागे के साथ कितनी तेजी से चला सकते हैं .. लेकिन यह केवल दो धागे के समान गति से चलता है!

बाद में बहुत सारे बाल खींचने और डिबगिंग, मैं देखता हूं कि मेरा प्रोग्राम वास्तव में सभी धागे बना रहा है, वे वास्तव में एक साथ चल रहे हैं, लेकिन थ्रेड स्वयं जितना धीमा हो उतना धीमा हो। 2 धागे 1 से तेज 1.7x चलाते हैं, लेकिन 3, 4, 8, 10, 16 धागे सभी नेट 1.9x पर चलते हैं! मैं देख सकता हूं कि सभी धागे चल रहे हैं (रुक गए या सोए नहीं), वे बस धीमे हैं।

यह जांचने के लिए कि हार्डवेयरवेयर गलती नहीं है, मैं अपने कार्यक्रम की सिक्सटेन प्रतियां स्वतंत्र रूप से एक साथ चला गया। वे सभी पूरी गति से भाग गए। वास्तव में 16 कोर हैं और वे वास्तव में पूरी गति से दौड़ते हैं और वास्तव में पर्याप्त रैम है (वास्तव में इस मशीन में 64 जीबी है, और मैं केवल 1 जीबी प्रति प्रक्रिया का उपयोग करता हूं)।

तो, मेरा सवाल यह है कि अगर कुछ ऑपरेटिंग सिस्टम स्पष्टीकरण है, तो शायद कुछ प्रति-प्रक्रिया संसाधन सीमा जो स्वचालित रूप से मशीन को हॉगिंग से एक प्रक्रिया को रखने के लिए थ्रेड शेड्यूलिंग को वापस ले जाती है।

सुराग हैं:

1. मेरे कार्यक्रम डिस्क या नेटवर्क तक पहुंच नहीं है। यह सीपीयू सीमित है। उबंटू लिनक्स में के साथ 1-6 धागे के लिए एक हेक्साकोर i7 के साथ एकल सीपीयू बॉक्स पर इसकी गति स्केल रैखिक रूप से। 6 धागे प्रभावी ढंग से 6x गतिशील है।
2. मेरा प्रोग्राम इस 16 कोर सनफायर ज़ीऑन बॉक्स पर से 2-16 से 2x स्पीडअप से अधिक तेज़ नहीं चलता है।
3. की 16 प्रतियां चलाना मेरे प्रोग्राम सिंगल थ्रेडेड पूरी तरह से चलाता है, सभी 16 एक बार पूर्ण गति पर चलते हैं।
4. शीर्ष शो 1612% आवंटित CPUs दिखाता है।/proc/cpuinfo दिखाता है सभी 16 कोर पूर्ण 2.9GHz गति (कम आवृत्ति निष्क्रिय गति 1.6GHz की गति नहीं)
5. 48 जीबी रैम मुक्त है, यह स्वैपिंग नहीं है।

क्या हो रहा है? क्या कुछ प्रक्रिया सीपीयू सीमा नीति है? यदि मैं ऐसा कर सकता हूं तो मैं इसे कैसे माप सकता हूं? इस व्यवहार को और क्या समझा सकता है?

2010 के ग्रेट ज़ीऑन स्लोडाउन मिस्ट्री को हल करने के आपके विचारों के लिए धन्यवाद!

Answer 1

मेरा प्रारंभिक अनुमान स्मृति की बाधाओं को साझा किया जाएगा। आप जो कहते हैं, उससे 2 सीपीयू के बाद आपका प्रदर्शन काफी अधिक फ्लैटलाइन है। आप शुरुआत में रेडहाट को दोषी ठहराते हैं, लेकिन यह देखने के लिए उत्सुक होगा कि अगर आप उसी हार्डवेयर पर उबंटू इंस्टॉल करते हैं तो क्या होता है। मुझे लगता है कि, आप दोनों परीक्षणों में 64 बिट एसएमपी कर्नेल चला रहे हैं।

शायद यह संभव नहीं है कि मदरबोर्ड 2 CPUs का उपयोग करने पर चोटी।आपके पास एकाधिक कोर के साथ एक और मशीन है जिसने बेहतर प्रदर्शन प्रदान किया है। क्या आपके पास नई मशीन के साथ हाइपरथ्रेडिंग चालू है? (और यह जवाब पुरानी मशीन से तुलना कैसे करता है?)। आप वर्चुअलाइज्ड वातावरण में चल रहे हैं, मौके से नहीं?

कुल मिलाकर, आपका सबूत कहीं हद तक धीमी गति से धीमी गति से संकेत दे रहा है। जैसा कि आपने कहा था, आप I/O बाध्य नहीं हैं, ताकि सीपीयू और मेमोरी छोड़ दें। हार्डवेयर के साथ या तो कुछ गलत है, या हार्डवेयर के साथ कुछ गलत है। दूसरे को बदलकर परीक्षण करें, और आप अपनी संभावनाओं को जल्दी से सीमित कर देंगे।

Answer 2

rlimit पर कुछ शोध करें - यह संभव है कि आपके द्वारा चल रहे खोल/उपयोगकर्ता एक्ट में कुछ आरएच-डिफ़ॉल्ट या व्यवस्थापक-सेट संसाधन सीमाएं हों।

Answer 3

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

इसका मतलब है कि मेमोरी आर्किटेक्चर खेलना शुरू हो जाता है, और जब आप 4 अलग प्रोसेसर में समन्वय कर रहे हों, तब से सिलिकॉन के एक टुकड़े पर 6 कोर होने पर यह काफी तेज़ होगा। विशेष रूप से, एकल सीपीयू केस को लॉकिंग ऑपरेशंस के लिए मुख्य मेमोरी को हिट करने की आवश्यकता नहीं होती है - एल 3 कैश स्तर पर सबकुछ संभाला जा सकता है, जिससे सीपीयू चीजों को चालू करने की इजाजत देता है जबकि डेटा पृष्ठभूमि में मुख्य मेमोरी में फिसल जाता है ।

जबकि मुझे आशा है कि ओपी इस समय के बाद प्रश्न में रुचि खो गया है (या हार्डवेयर तक पहुंच भी नहीं हो सकता है), यह जांचने का एक तरीका यह होगा कि 4 धागे तक स्केलिंग में सुधार होता है या नहीं अगर प्रक्रिया एफ़िनिटी इसे एक भौतिक CPU पर लॉक करने के लिए सेट है। यहां तक ​​कि बेहतर होगा कि आवेदन को स्वयं ही यह देखने के लिए होगा कि यह कहां खर्च कर रहा है। जैसे आप आर्किटेक्चर बदलते हैं और कोर की संख्या में वृद्धि करते हैं, यह अनुमान लगाने के लिए कठिन और कठिन हो जाता है कि बाधाएं कहां हैं, इसलिए आपको वास्तव में चीजों को मापना शुरू करना होगा सीधे, इस उदाहरण में: http://postgresql.1045698.n5.nabble.com/Sun-Donated-a-Sun-Fire-T2000-to-the-PostgreSQL-community-td2057445.html