👩🏾‍🤝‍👩🏽 😢 🙌🏿 Node.js पर लिटिल बफ़र्स के लिए बड़े भूखंड ⌚️ 🤘🏻 👆🏽

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

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

हम प्रोफाइलर के आंतों में डूब गए और BufferNode.js के साथ काम करने की कुछ विशेषताएं मिलीं , जिसके ज्ञान से आपके समय और सर्वर संसाधनों को बचाया जा सकता है।

सीपीयू लोड

प्रोसेसर के अधिकांश समय को आने वाली लॉग स्ट्रीम को संसाधित करने में खर्च किया गया था, जो समझ में आता है। लेकिन जो स्पष्ट नहीं था वह द्विआधारी ब्लॉक की आने वाली धारा के आदिम "स्लाइसिंग" के संसाधन-गहनता द्वारा लाइनों में था \r\n:

चौकस डेवलपर तुरंत आने वाले बफर के माध्यम से एक नहीं-तो-कुशल बाइट चक्र को यहां नोटिस करेगा । खैर, चूँकि पड़ोसी ब्लॉकों के बीच लाइन "फटी हुई" हो सकती है, इसलिए पिछले संसाधित ब्लॉक से बचा हुआ एक कार्यात्मक "टेल अटैचमेंट" भी है ।

रीडलाइन की कोशिश कर रहा है

उपलब्ध समाधानों की एक त्वरित समीक्षा ने हमें नियमित रीडलाइन मॉड्यूल में लाकर लाइनों में स्लाइसिंग के लिए आवश्यक कार्यक्षमता के साथ लाया :

इसे लागू करने के बाद, प्रोफाइलर के ऊपर से "स्लाइसिंग" गहरा गया:

लेकिन, जैसा कि यह निकला, रीडलाइन स्ट्रिंग को UTF-8 में आंतरिक रूप से मजबूर करता है , जो असंभव है यदि लॉग एंट्री (अनुरोध, योजना, त्रुटि पाठ) में एक अलग स्रोत एन्कोडिंग है।

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

बाइक को मोडिफाई करना

यह एक मुसीबत है ... यह अभी भी अपने आप को काटने के लिए आवश्यक है, लेकिन Buffer.indexOf()"बाइट" स्कैनिंग जैसी अनुकूलन के साथ :

ऐसा लगता है कि सब कुछ ठीक है, परीक्षण सर्किट में लोड नहीं बढ़ा है, win1251 नामों की मरम्मत की गई है, हम लड़ाई के लिए रोल आउट कर रहे हैं ... टा-डैम! सीपीयू का उपयोग समय-समय पर छत से 100% पर टूट जाता है :

यह कैसे होता है? .. यह पता चलता है कि यह हमारी गलती Buffer.concatहै जिसके साथ हम पिछले खंड से "पूंछ को छड़ी" छोड़ते हैं:

लेकिन हमारे पास केवल एक gluing है जब हम ब्लॉक के माध्यम से एक रेखा से गुजरते हैं , लेकिन उन्हें नहीं करना चाहिए कई होने के लिए - वास्तव में, वास्तव में? .. खैर, लगभग। केवल अब कभी-कभी कई सौ 16KB खंडों के "तार" आते हैं :

साथी डेवलपर्स के लिए धन्यवाद जिन्होंने इसे उत्पन्न करने का ध्यान रखा। यह "शायद ही कभी, लेकिन सटीक रूप से" होता है, इसलिए परीक्षण सर्किट में अग्रिम रूप से देखना संभव नहीं था।

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

अब लोड ReadLine संकेतक के लिए वापस आ गया है।

मेमोरी की खपत

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

पारंपरिक "ट्विस्ट" ने वास्तव में मदद नहीं की ... "यदि बाकी सभी विफल होते हैं, तो डंप करें!" और लोक ज्ञान ने निराश नहीं किया - हमने 520MB के कुल आकार के साथ 8360 बाइट्स के बफ़र का एक बादल देखा ...

और वे CopyBinaryStream के अंदर उत्पन्न हुए - स्थिति स्पष्ट होने लगी ...

कॉपी ... बायिनरी के साथ स्टडिन से

डेटाबेस में प्रेषित ट्रैफ़िक की मात्रा को कम करने के लिए, हम बाइनरी प्रारूप COPY का उपयोग करते हैं । वास्तव में, प्रत्येक रिकॉर्ड के लिए, आपको "टुकड़े" से मिलकर धारा को एक बफर भेजना होगा - रिकॉर्ड में फ़ील्ड की संख्या (2 बाइट्स) और फिर प्रत्येक कॉलम के मानों का द्विआधारी प्रतिनिधित्व (4 बाइट्स प्रति प्रकार आईडी + डेटा)।

चूंकि तालिका की ऐसी पंक्ति में लगभग हमेशा एक चर लंबाई होती है, "सारांशित", एक निश्चित लंबाई के बफर को तुरंत आवंटित करना एक विकल्प नहीं है , अगर आकार की कमी है तो प्रदर्शन वास्तव में "खाओ" प्रदर्शन और पहले से ही अधिक हो गया है। तो, यह "टुकड़ों से गोंद" का उपयोग करने के लिए भी सार्थक है Buffer.concat()।

ज्ञापन

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

और ... बाम, एक रेक आ गया है!

यही है, हाँ, हर बार जब आप एक बफ़र बनाते हैं, तो एक 8KB मेमोरी को डिफ़ॉल्ट रूप से आवंटित किया जाता है, ताकि एक पंक्ति में बनाए गए छोटे बफ़र्स को पहले से आवंटित मेमोरी में "बगल में" स्टैक किया जा सके। और हमारे आवंटन ने "मांग पर" काम किया, और यह बिल्कुल "निकट" नहीं हुआ - यही कारण है कि हमारे प्रत्येक 1-2-4 बाइट्स बफर ने शारीरिक रूप से 8KB + हेडर पर कब्जा कर लिया है - यहाँ वे हमारे 520MB हैं!

स्मार्ट मेमो

हम्म ... हमें भी तब तक इंतजार करना होगा जब तक कि एक या दूसरे 1/2 बाइट बफर की जरूरत न हो? 4-बाइट के साथ एक अलग मुद्दा है, लेकिन कुल 256 + 65536 के लिए इन अलग-अलग विकल्पों में से कुछ हैं। इसलिए सभी को एक साथ अपनी पंक्ति में आने दें ! उसी समय, हम प्रत्येक चेक के अस्तित्व के लिए स्थिति में कटौती करते हैं - यह भी तेजी से काम करेगा, क्योंकि प्रारंभ प्रक्रिया के शुरू में ही किया जाता है।

यही है, 1/2-बाइट बफ़र्स के अलावा, हम तुरंत 4-बाइट वाले लोगों के लिए सबसे अधिक चलने वाले मूल्यों (2 बाइट्स और -1) को शुरू करते हैं। और - यह मदद मिली, 520MB के बजाय केवल 10MB!

Node.js पर लिटिल बफ़र्स के लिए बड़े भूखंड