पेश है हमारी साइडकीक क्लस्टर स्क्रिप्ट

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

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

एकाधिक साइडकीक प्रक्रियाओं को चलाने के लिए एक सरल कमांड

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

बेशक, उस स्क्रिप्ट में कुछ उधार कोड है। :) process_count . में कोड विधि शायद स्टैक ओवरफ्लो से आती है (मैं इसे हमारे यूनिकॉर्न कॉन्फ़िगरेशन में वर्षों से उपयोग कर रहा हूं) और fork_child विधि मूल रूप से sidekiq है साइडकीक रत्न से बिन।

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

क्लस्टर के साथ काम करना

जबकि प्रक्रियाओं की संख्या कोर की संख्या के लिए डिफ़ॉल्ट है (यह मानते हुए कि आप साइडकीक प्रक्रियाओं को चलाने के लिए एक उदाहरण समर्पित कर रहे हैं), आप स्क्रिप्ट चलाने से पहले SK_PROCESS_COUNT पर्यावरण चर सेट करके इसे ओवरराइड कर सकते हैं। इसी तरह, मेमोरी थ्रेशोल्ड को इंस्टेंस की कुल रैम के प्रतिशत के रूप में सेट किया जाता है (लाइन 58 पर प्रोसेस_काउंट वैल्यू में एक जोड़कर कुछ रैम को छोड़ दिया जाता है), लेकिन आप SK_MEMORY_PCT_LIMIT पर्यावरण चर के साथ जो भी प्रतिशत चाहते हैं उसे सेट कर सकते हैं। हम इन दो चरों का उपयोग साइडकीक प्रक्रियाओं की संख्या और स्मृति उपयोग को उन उदाहरणों पर सीमित करने के लिए करते हैं जो रेल ऐप चला रहे हैं जो हमारे यूआई को शक्ति देता है।

एक अतिरिक्त बोनस के रूप में, यह स्क्रिप्ट आमतौर पर साइडकीक प्रक्रियाओं को प्रबंधित करने के लिए उपयोग किए जाने वाले संकेतों को पकड़ती है और उन संकेतों को चाइल्ड प्रोसेस में पास करती है। यह हमें pkill -f -USR1 skcluster . का उपयोग करने की अनुमति देता है बच्चे की प्रक्रियाओं को नए कार्य को स्वीकार करना बंद करने के लिए (यह हमारी परिनियोजन स्क्रिप्ट में एक प्रारंभिक कार्य है), और हम pkill -f skcluster का उपयोग कर सकते हैं सब कुछ समाप्त करने के लिए।

systemd को कॉन्फ़िगर करना

सिस्टमड सेवा परिभाषा सीधी है:

चूंकि हम पोस्टग्रेज करने के लिए प्रॉक्सी कनेक्शन के लिए हर उदाहरण पर pgbouncer का उपयोग करते हैं, हम यह सुनिश्चित करते हैं कि साइडकीक प्रक्रियाओं के बूट होने से पहले pgbouncer सेवा चल रही है। यदि हम समान उदाहरणों पर रेडिस चला रहे थे, तो हम आवश्यकता और आफ्टर लाइनों में redis-server.service भी जोड़ देंगे। एनवायरनमेंटफाइल - सिस्टमड को यह बताने के लिए फ़ाइल नाम के लिए उपसर्ग का उपयोग करता है कि यह ठीक है अगर फ़ाइल मौजूद नहीं है। यह हमें उस फ़ाइल को छोड़ने की अनुमति देता है जब हम डिफ़ॉल्ट प्रक्रिया गणना और मेमोरी सीमा के साथ जाना चाहते हैं। हम --require . का उपयोग करते हैं साइडकीक को यह बताने का विकल्प है कि हमारे रेल एप्लिकेशन के कॉन्फ़िगरेशन और इनिशियलाइज़र को लोड करने के लिए कहाँ जाना है। चूंकि skcluster स्क्रिप्ट SIGTERM को पकड़ती है, हम systemctl restart skcluster.service का उपयोग कर सकते हैं सभी कर्मचारियों को पुनः आरंभ करने के लिए (यह हमारी परिनियोजन स्क्रिप्ट में देर से किया गया कार्य है)।

हम कुछ समय से इस स्क्रिप्ट का उपयोग कर रहे हैं, और इसने एक विजेता की तरह काम किया है। बूट पर बहुत अधिक प्रक्रियाओं के साथ हमें कोई और समस्या नहीं है, हमारे पास हमारी निगरानी से कोई और मेमोरी उपयोग चेतावनी नहीं है, और हम किसी भी प्रकार के ईसी 2 इंस्टेंस को लॉन्च कर सकते हैं जो हम चाहते हैं। परेशानी मुक्त ऑप्स मुझे सबसे ज्यादा पसंद है। :)