Highload ++: ईआरपी सिस्टम को प्रति सेकंड 500,000 अनुरोधों का सामना करने में मदद कैसे करें

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

ईआरपी एक्स 5

अब X5 13,000 से अधिक स्टोर संचालित करता है। उनमें से प्रत्येक की अधिकांश व्यावसायिक प्रक्रियाएं एकल ईआरपी प्रणाली से गुजरती हैं। प्रत्येक स्टोर में 3,000 से 30,000 उत्पाद हो सकते हैं, यह सिस्टम पर लोड की समस्या पैदा करता है, क्योंकि कीमतों की नियमित पुनर्गणना की प्रक्रियाएँ प्रचार और विधायी आवश्यकताओं और आविष्कारों की पुनःपूर्ति की गणना के अनुसार इसके माध्यम से गुजरती हैं। यह सब महत्वपूर्ण है, और अगर यह गणना नहीं की जाती है कि कल किस सामान को किस मात्रा में स्टोर तक पहुंचाया जाना चाहिए या सामानों की कीमत क्या होनी चाहिए, तो खरीदारों को वह नहीं मिलेगा जो वे अलमारियों की तलाश में थे या वे वर्तमान प्रोत्साहन की कीमत पर सामान नहीं खरीद पाएंगे। शेयरों। सामान्य तौर पर, वित्तीय लेनदेन के लिए लेखांकन के अलावा, ईआरपी प्रणाली प्रत्येक स्टोर के रोजमर्रा के जीवन में बहुत कुछ के लिए जिम्मेदार है।

एक ईआरपी सिस्टम की प्रदर्शन विशेषताओं का एक सा। इसकी वास्तुकला क्लासिक है, सेवा-उन्मुख तत्वों के साथ त्रि-स्तरीय: शीर्ष पर हमारे पास 5,000 से अधिक मोटे ग्राहक हैं और दुकानों और वितरण केंद्रों से सूचना प्रवाह की टेराबाइट्स, आवेदन परत में - 10,000 से अधिक प्रक्रियाओं के साथ SAP ABAP और अंत में, Oracle से अधिक के साथ। 100 टीबी डेटा। प्रत्येक ABAP प्रक्रिया एक सशर्त रूप से आभासी मशीन है जो ABAP व्यवसाय तर्क को अपनी DBSL और SQL बोली, कैशिंग, मेमोरी प्रबंधन, ORM, आदि के साथ निष्पादित करती है। हर दिन हमें डेटाबेस लॉग में 15 Tb से अधिक परिवर्तन मिलते हैं। लोड स्तर प्रति सेकंड 500,000 अनुरोध है।

यह वास्तुकला एक विषम वातावरण है। प्रत्येक घटक क्रॉस-प्लेटफ़ॉर्म है, हम इसे विभिन्न प्लेटफार्मों पर स्थानांतरित कर सकते हैं, इष्टतम वाले चुन सकते हैं, आदि।

तथ्य यह है कि ईआरपी प्रणाली लोड के तहत 24 घंटे एक दिन है 365 दिन एक वर्ष में आग में ईंधन जोड़ता है। उपलब्धता - पूरे वर्ष में 99.9% समय। लोड को खाली समय में रखते हुए दिन और रात के प्रोफाइल और घर में विभाजित किया गया है।

लेकिन यह सब नहीं है। सिस्टम में एक तंग और तंग रिलीज चक्र है। यह प्रति वर्ष 2,000 से अधिक बैच परिवर्तन करता है। यह एक नया बटन हो सकता है, और व्यावसायिक अनुप्रयोगों के तर्क में गंभीर परिवर्तन हो सकता है।



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

2014. द्विभाजन बिंदु

व्यावहारिक सामग्री में गोता लगाने के लिए आपको 2014 में वापस जाने की आवश्यकता है। तब सिस्टम को अनुकूलित करने के लिए सबसे कठिन कार्य थे। लगभग 5,000 स्टोर थे।

उस समय की प्रणाली ऐसी स्थिति में थी कि अधिकांश महत्वपूर्ण प्रक्रियाएं मापनीय नहीं थीं और बढ़ते लोड (यानी नए स्टोर और सामानों की उपस्थिति) के लिए पर्याप्त रूप से प्रतिक्रिया नहीं देती थीं। इसके अलावा, दो साल पहले, एक महंगा हाई-एंड खरीदा गया था, और कुछ समय के लिए एक अपग्रेड हमारी योजनाओं का हिस्सा नहीं था। इसके अलावा, ईआरपी में प्रक्रियाएं पहले से ही SLA के उल्लंघन के कगार पर थीं। वेंडर ने निष्कर्ष निकाला कि सिस्टम पर लोड स्केलेबल नहीं है। कोई नहीं जानता था कि क्या वह भार में कम से कम + 10% वृद्धि का सामना कर सकती है। और इसे तीन साल के भीतर दो बार खोलने की योजना थी।

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

अनुकूलन तकनीक क्या थी? यह एक चक्रीय प्रक्रिया है, जिसे कई चरणों में विभाजित किया गया है:

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

अगला, चक्र दोहराया गया।

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

कोड और प्रक्रिया अनुकूलन

सबसे पहले, गति पर बाधाओं के कम प्रभाव के लिए, उन्होंने सिस्टम को लोड की एक चिकनी आपूर्ति सुनिश्चित की।

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

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


हमने शेड्यूलर के तर्क को फिर से लिखा है ताकि प्रत्येक स्टोर के लिए अलग से पैकेज की श्रृंखला बनाई गई और नए पैकेज लॉन्च करने की प्राथमिकता चरणों द्वारा नहीं, बल्कि स्टोरों द्वारा बनाई गई।


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

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

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

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


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

2015. एक सेवा की समस्या

डेढ़ साल के लिए, हमने सिस्टम को अनुकूलित करने का एक बड़ा काम किया, यह अधिक अनुमानित हो गया है। फिर भी, दुकानों की संख्या को दोगुना करने की योजना प्रासंगिक बनी हुई है, इसलिए अभी भी चुनौतियों का सामना करना पड़ा है।

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

स्पष्ट करने के लिए, सेवा का कार्य अनुप्रयोग सर्वर स्तर पर तार्किक लेन-देन लाना है। ABAP में, एक एकल लेनदेन विभिन्न वर्कफ़्लो पर कई चरणों से गुजर सकता है। लेनदेन पूर्ण होने के लिए, लॉक सेवा और संबंधित तंत्र है। इसमें लॉक और अनलॉक ऑपरेशन जल्दी होते हैं, लेकिन वे परमाणु हैं, उन्हें अलग नहीं किया जा सकता है। सिंक्रोनस I / O के साथ एक समस्या थी।

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

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

लॉक सेवा के जीवन को विस्तारित करने की कोशिश करने वाले पहले विकल्पों में से एक है I / O और फ़ाइल सिस्टम पर लिखना। क्या? AIX के विकल्प के साथ प्रयोग। सबसे शक्तिशाली पावर-मशीन पर लिनक्स में सेवा स्थानांतरित की, और बहुत अधिक प्रतिक्रिया समय जीता। फ़ाइल सिस्टम के साथ सेवा अक्षम के साथ Aix के समान व्यवहार करती है। फिर हमने इस कोड को x86_64 ब्लेड में से एक में स्थानांतरित कर दिया और पहले की तुलना में और भी अधिक काल्पनिक रूप से धीरे-धीरे प्रदर्शन वक्र प्राप्त किया। यह मजाकिया लग रहा था।

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


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

फिर भी, हमने इस समस्या का पता लगाया और यह सेवा 3-4 गुना तेजी से काम करने लगी, जो कि बहुत लंबी वृद्धि के लिए पर्याप्त है।

2016. DB CPU टोंटी

वस्तुतः छह महीने बाद, डेटाबेस पर सीपीयू के साथ विदेशी समस्याएं महसूस की जाने लगीं। यह स्पष्ट प्रतीत होता है कि लोड में वृद्धि के साथ, प्रोसेसर संसाधनों की खपत बढ़ जाती है। लेकिन SysTime ने इसका अधिकांश हिस्सा लेना शुरू कर दिया, और कर्नेल में स्पष्ट रूप से समस्या थी। वे समझने लगे, सिंथेटिक लोड परीक्षण करना और महसूस किया कि हमारा थ्रूपुट प्रति सेकंड 300 हजार ऑपरेशन था, अर्थात। प्रति घंटे अरब अनुरोध, और फिर गिरावट।

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


इस तरह की चालों की मदद से, हमने हर जगह थोड़ी जीत हासिल की, लेकिन अंत में हमने गंभीरता से आधार को उतार दिया। सिस्टम में जान आ गई। इस बीच, हम ऐक्स पर उतर गए।

अन्य प्रयोगों से पता चला कि एक प्रदर्शन छत है - पहले से ही वर्णित 300,000 डेटाबेस कॉल प्रति सेकंड। समस्या की जड़ नेटवर्क इंटरफ़ेस का प्रदर्शन था, जिसमें एक दिशा में एक छत - लगभग 300 हजार पैकेट प्रति सेकंड था। जैसे-जैसे छत करीब आती गई, सिस्टम कॉल का समय बढ़ता गया। जैसा कि बाद में पता चला, यह AIX कर्नेल नेटवर्क स्टैक की विरासत भी थी।

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

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

2017. अपग्रेड करने के लिए लाइव

खैर, हमारे सिस्टम की वसूली का अंतिम चरण, 2017 में पारित हुआ। अपग्रेड होने तक यह सब थोड़ा सा रहना था और कुछ भी नहीं के लिए एसएलए को पकड़ना आवश्यक था। कोड को अनुकूलित किया गया था, लेकिन हमने देखा कि डेटाबेस सीपीयू पर लोड जितना अधिक है, प्रक्रियाओं को धीमा करता है, हालांकि उपयोग मार्जिन 10-20% था। प्रारंभ में, यह अनुमान लगाया गया था कि 100% 50% से दोगुना है। और जब 10-20% आरक्षित होता है, तो यह 10-20% होता है। वास्तव में, 67-80% से ऊपर के भार पर, कार्यों की अवधि नॉनलाइन रूप से बढ़ जाती है, अर्थात। Amdahl के कानून ने काम किया। सिस्टम में एक समानांतरकरण सीमा थी और जब इसे पार किया गया, तो काम में प्रोसेसर की बढ़ती संख्या की भागीदारी के साथ, प्रत्येक व्यक्तिगत प्रोसेसर का प्रदर्शन कम हो गया।

उस समय, हमने AIX स्तर पर मल्टीथ्रेडिंग पर विचार करते हुए 125 भौतिक प्रोसेसर या 500 तार्किक लोगों का उपयोग किया। आप क्या सुझाव देंगे? अपग्रेड करें? इसके समन्वय के अंत से पहले भी, कई महीनों के लिए बाहर रहना जरूरी था और एसएलए को छोड़ना नहीं था।

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


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

अत्यधिक भरी हुई ईआरपी के साथ काम करने वालों के लिए कुछ सुझाव

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

Highload , .

, , SAP #ITX5

, #ITX5 SAP.