Nodeload2: इंजन डाउनलोड करें - रिबूट

नोडलैड, पहला गिटहब टीम प्रोजेक्ट ने नोड का उपयोग किया, जो हाल ही में 1 वर्ष का हो गया । Nodeload एक सेवा है, जो Git रिपॉजिटरी की सामग्री को ज़िप अभिलेखागार और टारबॉल में पैक करती है। तब से, सेवा पर भार पूरे वर्ष बढ़ रहा है, और हमने विभिन्न समस्याओं का सामना किया है। नोदेलैड की उत्पत्ति के बारे में पढ़ें यदि आपको याद नहीं है कि यह जिस तरह से काम करता है, तो यह क्यों काम करता है।

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

अब Nodeload सर्वर केवल एक साधारण प्रॉक्सी एप्लिकेशन के रूप में काम करता है। यह प्रॉक्सी एप्लिकेशन अनुरोध किए गए रिपॉजिटरी के उपयुक्त फ़ाइल सर्वरों के लिए खोज करता है, और फ़ाइल सर्वर से सीधे डेटा को प्रॉक्सी करता है। फ़ाइल संग्रहकर्ता अब फ़ाइल सर्वर पर चलता है, जो मूल रूप से git archive लिए HTTP इंटरफ़ेस है। कैश्ड रिपॉजिटरी अब डेटा इनपुट / आउटपुट सबसिस्टम (IO) पर लोड को कम करने के लिए TMPFS सेक्शन को लिखा जाता है। Nodeload प्रॉक्सी भी सक्रिय फ़ाइल सर्वर के बजाय फ़ाइल बैकअप सर्वर का उपयोग करने की कोशिश करता है, अधिकांश लोड को अनलोड किए गए बैकअप सर्वर में स्थानांतरित करता है।



Node.js अपने उत्कृष्ट स्ट्रीमिंग API के कारण इस एप्लिकेशन के लिए बहुत अच्छा है। किसी भी प्रकार के परदे के पीछे को लागू करते समय, आपको उन ग्राहकों से निपटना होगा जो डेटा को उतनी तेजी से नहीं पढ़ सकते हैं जितना आप उन्हें भेज सकते हैं। जब HTTP सर्वर प्रतिक्रिया स्ट्रीम आपके हिस्से पर अधिक डेटा नहीं भेज सकती है, तो write() गलत है। इस मान के साथ, आप अनुमानित HTTP अनुरोध स्ट्रीम को तब तक रोक सकते हैं जब तक कि प्रतिक्रिया ऑब्जेक्ट एक drain घटना उत्पन्न न कर दे। drain घटना का मतलब है कि प्रतिक्रिया ऑब्जेक्ट अधिक डेटा भेजने के लिए तैयार है, और अब आप अनुमानित HTTP अनुरोध स्ट्रीम को फिर से शुरू कर सकते हैं। यह तर्क ReadableStream.pipe() विधि में पूरी तरह से समझाया गया है।

 // proxy the file stream to the outgoing HTTP response var reader = fs.createReadStream('some/file'); reader.pipe(res); 

भारी प्रक्षेपण

लॉन्च के बाद, हम सप्ताहांत पर कुछ अजीब समस्याओं के साथ आए:

• नोडेलैड सर्वर में अभी भी इनपुट / आउटपुट सिस्टम (IO) पर भारी भार था;
• फ़ाइल बैकअप सर्वर सभी उपलब्ध रैम का उपयोग करते हैं;
• नोडेलैड सर्वर ने सभी उपलब्ध रैम का उपयोग किया;
• top और ps ने नहीं दिखाया कि नोडेलैड प्रक्रियाएं उनके कब्जे वाले आकार को बदल देती हैं। नोडेलैड प्रक्रियाओं ने अच्छी तरह से काम किया, लेकिन हमने देखा कि उपलब्ध सर्वर मेमोरी धीरे-धीरे आकार में कम हो रही थी।

हमने proxy_buffering विकल्प के संबंध में एक उच्च IO मनाया। जैसे ही हमने इसे बंद किया, आईओ तेजी से गिर गया। इसका मतलब है कि थ्रेड क्लाइंट की गति से बह रहे हैं। यदि क्लाइंट संग्रह को तेज़ी से डाउनलोड नहीं कर सकते हैं, तो प्रॉक्सी HTTP अनुरोध स्ट्रीम को रोक देता है। यह अभिलेखीय अनुप्रयोग पर दिया जाता है, जो फ़ाइल स्ट्रीम को रोक देता है।

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

तब तक, @ tmm1 , @rtomayko और @rodjek कई संभावित समस्याओं का पता लगाने में मंथन के लिए बचाव में आए थे। उन्होंने अंततः प्रक्रियाओं पर एफडी फ़ाइल विवरणकों के संचय के रूप में एक रिसाव को ट्रैक किया।

 tmm1 @ arch1: ~ $ sudo lsof -nPp 17655 |  grep ": 7005 ("
 नोड 17655 git 16u IPv4 8057958 टीसीपी 172.17.1.40:49232->172.17.0.148:7005 (ESTABLISHED)
 नोड 17655 git 21u IPv4 8027784 TCP 172.17.1.40 54 8054-> 172.17.0.133:7005 (ESTABLISHED)
 नोड 17655 git 22u IPv4 8058226 TCP 172.17.1.40rige2498-> 172.17.0.134:7005 (ESTABLISHED)

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

इस समस्या का हल सर्वर पर HTTP अनुरोध ऑब्जेक्ट की close घटना को संभाल रहा है। pipe() वास्तव में इस मामले को संभालता नहीं है, क्योंकि यह एक पठनीय धारा के सामान्य एपीआई के लिए लिखा गया है। नज़दीकी घटना अधिक सामान्य अंत घटना से अलग है क्योंकि पहली घटना का अर्थ है कि HTTP अनुरोध स्ट्रीम response.end() से पहले बाधित हो गई थी। response.end() कहा जाता था।

 // check to see if the request is closed already if (req.connection.destroyed) { return; } var reader = fs.createReadStream('/some/file'); req.on('close', function() { reader.destroy(); }); reader.pipe(res); 

निष्कर्ष

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