रेडिस, हेंडिस, लिबेव, और मल्टीथ्रेड। भाग २

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

चेतावनी! यह समझने के लिए शोध नहीं किया गया कि मुझे इसकी आवश्यकता क्यों है, लेकिन यह समझने के लिए कि यह कैसे काम करता है!



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

हेरीडिस + लिबाव: मुझे लात मारो।

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

हेर्डिस + लिब्वे: स्वच्छ रहें, लेकिन कट्टरता के बिना।

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

हेरीडिस + लिब्वे + मल्टीथ्रेड: मैं डूब रहा हूं!

हैरानी की बात है, एक तरफ। जब मैंने डेटाबेस में 10 सेकंड के लिए एक थ्रेड से 10k पुश अनुरोधों को डुबाने की कोशिश की (आंकड़ा 120k अनुरोध प्रति सेकंड के घोषित रेडिस प्रदर्शन के साथ बिल्कुल भी नहीं है), तो मुझे फिर से DBMS से गिरने वाले कनेक्शन की समस्या का सामना करना पड़ा। हम फिर से आंत्र में चढ़ते हैं, एक ट्रेस बनाते हैं और ... हम वाक्यांश को महसूस करना शुरू करते हैं "मल्टीथ्रेडिंग डिफ़ॉल्ट रूप से समर्थित नहीं है, क्योंकि थ्रेड-सुरक्षित कार्यान्वयन करने के लिए कोई एकल-मूल्यवान एल्गोरिथ्म नहीं है।" क्या चल रहा है? निम्नलिखित होता है: अन्य धाराओं से अनुरोधों की बफ़र तक लिखने के लिए पहुँच को प्रतिबंधित करने वाला एक सेमाफ़र अपर्याप्त है, क्योंकि यह एक ही बफ़र (और यह भाड़े में मौजूद है और संसाधनों की अनंत मात्रा का उपभोग कर सकता है) बढ़ता है, जबकि डेटा रेडिस को नहीं भेजा जाता है, जाहिरा तौर पर एक धारा के साथ। ईवेंट लूप में बफर तक पहुंच नहीं है, जबकि रिकॉर्डिंग प्रगति पर है। प्रारंभ में, मैंने अनुरोधों के बीच एक समय सीमा निर्धारित करके समस्या को हल किया, फिर सेमीफ़ायर को बोने के लिए एडेप्टर के कटोरे में स्थानांतरित कर दिया, एक नया अनुरोध जोड़ने और सेमीफ़ोर को डीबीएमएस पर भेजने के बाद रिलीज़ करने के लिए सेमीफ़ायर के लिए प्रतीक्षा की स्थापना की। हालाँकि, मैं अभी तक अनुरोधों के बीच 1 μs के टाइमआउट की आवश्यकता की समस्या को पूरी तरह से समझ नहीं पाया हूं। शायद अगले भाग में (अगर वहाँ एक है) मैं पहले से ही नुस्खा का वर्णन करूंगा। इस सब के आधार पर:

हेरिडिस + लिब्वे + मल्टीथ्रेड: एक धागे से अधिकतम निचोड़ें।

नतीजतन, मैं सेवा में प्रारंभिक डेटा प्रसंस्करण के साथ एक एकल स्ट्रीम में रेडिस के प्रति सेकंड ~ 600 पुश अनुरोधों को प्राप्त करने में कामयाब रहा (मुझे यह गिनने में समय नहीं लगा कि कितना समय लगा)। सामान्य तौर पर, अब मेरे लिए यह शुरू करने के लिए पर्याप्त है, लेकिन मैं थ्रेड्स की संख्या में वृद्धि और बफर में अनुरोधों को जोड़ने के और भी अधिक सही सिंक्रनाइज़ेशन में खुदाई करूंगा।

हायरिस: असेंबली से पहले सावधानीपूर्वक फाइल करें।

यह कहें कि आपको क्या पसंद है, रेंटिस एक युवा पुस्तकालय है, मेरे कोड को डीबग करने की प्रक्रिया में, मैं एक से अधिक बार उसके आंत्र में चढ़ गया। मुझे इस बात से खुशी नहीं हुई कि यह तथ्य है कि अक्सर निम्न प्रकार के निर्माण होते हैं:

<some_struct> *p = (some_struct*)malloc(sizeof(*p)); //    , . 

 //    char[] - -   , ,   (err),       : ... = ... sizeof(err) ...; // ,           ... 

सामान्य तौर पर, मैंने खुद के लिए पैच किया, इसे डेवलपर्स को लिखा, जल्दी से कोई जवाब नहीं दिया, लेकिन मुझे लगता है कि वे इसे ठीक कर देंगे।

आपका ध्यान देने के लिए धन्यवाद। मैं आलोचना और टिप्पणियों के लिए तत्पर हूं।