7 सरल अनुकूलन जो 80% से 27% तक सीपीयू लोड को कम करते हैं

3 वर्षों से अधिक समय से, हमारी टीम ऑपरेटर के नेटवर्क के ऐसे महत्वपूर्ण घटक को पीसीआरएफ के रूप में विकसित कर रही है । पॉलिसी और चार्जिंग रूल्स फंक्शन (पीसीआरएफ) - एलटीई नेटवर्क (3 जीपीपी) में सब्सक्राइबर सर्विसिंग नीतियों के प्रबंधन के लिए एक समाधान, जो आपको वास्तविक समय में किसी विशेष पॉलिसी को असाइन करने की अनुमति देता है, इस जगह में सब्सक्राइबर, उसकी लोकेशन, नेटवर्क क्वालिटी से जुड़ी सेवाओं को ध्यान में रखते हुए। वर्तमान क्षण, दिन का समय, भस्म यातायात की मात्रा, आदि। इस संदर्भ में, एक पॉलिसी का अर्थ है सब्सक्राइबर और QoS (सेवा की गुणवत्ता) मापदंडों के लिए उपलब्ध सेवाओं का एक सबसेट। विभिन्न प्रकार के आपूर्तिकर्ताओं से इस क्षेत्र में विभिन्न उत्पादों के लिए मूल्य-गुणवत्ता अनुपात का विश्लेषण करते हुए, हमने अपने उत्पाद को विकसित करने का निर्णय लिया। और अब 2 वर्षों के लिए, हमारा पीसीआरएफ सफलतापूर्वक योटा वाणिज्यिक नेटवर्क पर काम कर रहा है। समाधान पूरी तरह से सॉफ्टवेयर है, जिसमें साधारण वर्चुअल सर्वर पर भी इंस्टॉल करने की क्षमता है। यह Red Hat Linux पर वाणिज्य में काम करता है, लेकिन सामान्य तौर पर इसे अन्य Linux सिस्टम के अंतर्गत स्थापित किया जा सकता है।

हमारे पीसीआरएफ की सभी विशेषताओं में से, सबसे सफल को मान्यता दी गई थी:

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

दरअसल, बाद में लेख में हम बाद के कई मानदंडों में से एक के बारे में बात करेंगे।

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

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

1. CCR-I - एक ग्राहक सत्र की स्थापना,
2. CCR-U - ग्राहक द्वारा उपभोग किए गए ट्रैफ़िक की मात्रा के बारे में जानकारी के साथ अद्यतन सत्र जानकारी,
3. CCR-T - ग्राहक द्वारा उपभोग किए गए ट्रैफ़िक की मात्रा के बारे में जानकारी के साथ सत्र का अंत।

3.5.2 संस्करण में, जिसे हमने पिछले साल की पहली तिमाही में जारी किया था, इस परिदृश्य में सीपीयू लोड काफी अधिक था और इसकी मात्रा 80% थी । हम इसे 3.6.0 संस्करण में 35% तक कम करने में सक्षम थे, जो वर्तमान में वाणिज्यिक नेटवर्क पर है, और संस्करण 3.6.1 में 27% तक है, जो वर्तमान में स्थिरीकरण चरण में है।

इतने बड़े अंतर के बावजूद, हमने कोई चमत्कार नहीं किया, लेकिन केवल 7 सरल अनुकूलन किए, जिनका मैं नीचे वर्णन करूंगा। शायद आपके उत्पाद में आप CPU उपयोग के संदर्भ में इसे बेहतर बनाने के लिए उपरोक्त में से किसी एक का उपयोग कर सकते हैं।

सबसे पहले, मैं यह कहना चाहता हूं कि अधिकांश अनुकूलन डेटाबेस और एप्लिकेशन लॉजिक के इंटरैक्शन से संबंधित हैं। प्रश्नों का अधिक विचारशील उपयोग और जानकारी का कैशिंग, शायद, मुख्य बात जो हमने की है। डेटाबेस के प्रश्नों के समय का विश्लेषण करने के लिए, हमें अपनी उपयोगिता बनानी होगी। तथ्य यह है कि शुरू में आवेदन में Oracle TimesTen डेटाबेस का उपयोग किया गया था, जिसमें अंतर्निहित विकसित निगरानी उपकरण नहीं हैं। और PostgreSQL को लागू करने के बाद, हमने फैसला किया कि दो डेटाबेस की तुलना करने के लिए एक उपकरण का उपयोग करना सही है, इसलिए हमने अपनी उपयोगिता छोड़ दी। इसके अलावा, हमारी उपयोगिता आपको लगातार डेटा एकत्र करने की अनुमति नहीं देती है, लेकिन इसे आवश्यकतानुसार चालू / बंद करने के लिए, उदाहरण के लिए, सीपीयू लोड में मामूली वृद्धि के साथ एक वाणिज्यिक नेटवर्क पर, लेकिन उत्पादन पर तुरंत विश्लेषण करने की क्षमता के साथ जो इस समय समस्या पैदा कर रहा है।
उपयोगिता tt_perf_info को कॉल करती है और अनुरोध के विभिन्न चरणों में बिताए गए समय को मापती है: सीधे, निष्पादन, प्रति सेकंड कॉल की संख्या, कुल समय का प्रतिशत। समय को माइक्रोसेकंड में प्रदर्शित किया जाता है। संस्करणों में शीर्ष 15 प्रश्नों को 3.5.2 और 3.6.1 पर लिंक में तालिका में देखा जा सकता है:
3.5.2 शीर्ष 15
3.6.1 शीर्ष 15 (रिक्त संस्करण इस संस्करण में मान 0 के अनुरूप हैं)

अनुकूलन 1: कम करना

यदि आप अलग-अलग संस्करणों पर tt_perf_info के आउटपुट को ध्यान से देखते हैं, तो आप देखेंगे कि pcrf.commit कॉल की संख्या 12006 प्रति सेकंड से घटाकर 1199 , यानी 10 गुना हो गई है! हमारे सिर पर आया बहुत स्पष्ट निर्णय यह जांचना था कि क्या वास्तव में डेटाबेस में कोई बदलाव हुए थे, और केवल एक सकारात्मक जवाब देने के मामले में। उदाहरण के लिए, UPDATE क्वेरी के लिए, PCRF उन रिकॉर्ड की संख्या की जाँच करता है जो बदल गए हैं। अगर यह 0 है, तो कोई कमिट नहीं किया जाता है। इसी तरह DELETE के साथ।

अनुकूलन 2: MERGE अनुरोध को हटाना

Oracle TimesTen के आधार पर, यह देखा गया कि MERGE अनुरोध पूरे टेबल पर लॉक सेट करता है। जो लगातार प्रतिस्पर्धा प्रक्रिया तालिकाओं की स्थितियों में स्पष्ट समस्याओं के लिए नेतृत्व किया। इसलिए हमने GET-UPDATE-INSERT के संयोजन के साथ सभी MERGE अनुरोधों को बदल दिया। यदि कोई रिकॉर्ड है, तो उसे अपडेट किया जाता है, यदि नहीं, तो एक नया जोड़ा जाता है। हमने लेन-देन में यह सब लपेटना शुरू नहीं किया था, लेकिन विफलता के मामले में पुनरावृत्ति को फ़ंक्शन कहा जाता है। छद्म कोड पर, यह कुछ इस तरह दिखता है:

our_db_merge_function() { if (db_get() == OK) { if (db_update() == OK) { return OK; } else { return out_db_merge_function(); } } else { if (db_insert() == OK) { return OK; } else { return out_db_merge_function(); } } } 

व्यवहार में, यह लगभग हमेशा एक पुनरावर्ती कॉल के बिना काम करता है, क्योंकि एक रिकॉर्ड पर संघर्ष अभी भी शायद ही कभी होता है।

अनुकूलन 3: ग्राहकों द्वारा खपत ट्रैफ़िक की मात्रा की गणना करने के लिए कॉन्फ़िगरेशन कैशिंग

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

अनुकूलन 4: निर्यात लुआ इंजन की संख्या कम करें

पीसीआरएफ में संसाधित CCR-I, CCR-U और RAR के प्रत्येक अनुरोध के लिए Lua इंजन को बुलाया जाता है, और एक Lua स्क्रिप्ट निष्पादित करता है जो नीति चयन एल्गोरिदम का वर्णन करता है, क्योंकि यह संभावना है कि ग्राहक का नीति अनुरोध डेटा बदलने पर बदल जाएगा। लेकिन एक चेक राशि के विचार ने यहां अपना आवेदन पाया है। 3.6.1 संस्करण में, हमने उन सभी सूचनाओं को सहेजा जिन पर एक वास्तविक नीति परिवर्तन निर्भर हो सकता है, एक अलग संरचना में और इसके लिए चेकसम की गणना करना शुरू किया। तदनुसार, इंजन वास्तविक परिवर्तनों के मामले में केवल चिकोटी लेना शुरू कर दिया।

अनुकूलन 5: डेटाबेस से नेटवर्क कॉन्फ़िगरेशन को हटाना

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

अनुकूलन 6: चयनात्मक व्यास पार्सिंग

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

अनुकूलन 7: समय कैशिंग

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

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

1. जांचें कि डेटा वास्तव में बदल रहा है;
2. पूरे तालिकाओं पर ताले की संख्या को कम करने की कोशिश करें;
3. डेटाबेस से कैश और कॉन्फ़िगरेशन डेटा हटा दें;
4. केवल उन कार्यों को करें जिनकी वास्तव में आवश्यकता है, भले ही ऐसा लगता है कि पूरी सूची बनाना आसान है।