एक अत्यधिक भरे हुए संसाधन के विकास और अनुकूलन का इतिहास

परिचय

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

* वैसे, उस समय मुझे * nix सिस्टम में कुछ भी समझ में नहीं आया था, हालाँकि मुझे जो भी सर्वर मिले थे, वे सब मुझे जल्दी-जल्दी पता थे।



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

nginx + php-fpm

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

eAccelerator

उच्च प्रदर्शन की दिशा में अगला कदम एक php त्वरक स्थापित करना है। उनके काम का सार स्क्रिप्ट के बाइनरी कोड को कैश करना है। वास्तव में, कीमती प्रोसेसर समय को हर कॉल के साथ बाइनरी कोड में स्क्रिप्ट का अनुवाद करने में क्यों समय बर्बाद करना चाहिए? प्रति सेकंड एक ही स्क्रिप्ट पर 100 तक कॉल आ सकते हैं, इसलिए eAccelerator काम में आया। इसे स्थापित करने के बाद, सिस्टम का प्रदर्शन फिर से बढ़ गया, लोड में गिरावट आई, पेज पीढ़ी का समय तेजी से कम हो गया, और उपयोगकर्ता फिर से त्वरित संसाधन के साथ संतुष्ट होने लगे।

MySQL सूचकांक

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

memcached

जब तक लोड वापस शेल्फ में था, तब तक अधिकारियों ने संसाधन के लिए एक पूर्ण सर्वर आवंटित किया था। लेकिन मैंने पहले ही स्पोर्ट्स इंटरेस्ट खेला है। जब पेज पीढ़ी का समय 2 सेकंड से 0.5 सेकंड तक कम हो जाता है, तो यह बहुत, बहुत प्रेरणादायक है, लेकिन मैं और अधिक चाहता था। मैं भारी एसक्यूएल प्रश्नों से पूरी तरह छुटकारा पाना चाहता था, केवल एक महत्वपूर्ण न्यूनतम। विशालता को देखते हुए, मुझे आंद्रेई स्मिरनोव की एक रिपोर्ट आई: "वेब, कैशिंग और मेमकेच्ड" (हाईलाड ++ 2008 में प्रस्तुति)। वास्तव में, यह वही है जो आपको चाहिए! Memcached - सबसे सरल और एक ही समय में उच्च-प्रदर्शन कैशिंग सर्वर livejournal.com के लिए एक समय में विकसित हुआ, मेरी योजना में बहुत अच्छी तरह से फिट बैठता है। दुर्भाग्य से, मेमेचे को पूर्ण रूप से उपयोग करना मेरे लिए संभव नहीं था, क्योंकि मेरा काम इस वेब संसाधन तक सीमित नहीं था, लेकिन फिर भी बहुत कुछ किया गया था। मैंने sql प्रश्नों के परिणाम को कैश करने के लिए, या तैयार किए गए रेंडर ब्लॉक को स्टोर करने के लिए मेमेकैच्ड का उपयोग किया। साइट के कई पन्नों पर, उनकी पीढ़ी का समय बहुत कम संख्या में कम हो गया था - 0.009s! यह अब तक की सबसे बड़ी खोज और उपलब्धि थी।

Sysctl और यूनिक्स-सॉकेट

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

गूढ़ व्यक्ति

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

MySQL tmpfs के लिए

मेरे सभी ट्यूनिंग और अनुकूलन के बाद से बहुत समय बीत चुका है। कंपनी के लिए संसाधन महत्वपूर्ण हो गया, इसके समर्थन के लिए धन आवंटित किया गया और 2 सर्वर पहले से ही इसकी सेवा दे रहे थे। पहले ने एक वेब सर्वर के रूप में काम किया और php प्रोसेस किया, दूसरे का उपयोग MySQL के तहत किया गया। लेकिन विकास अभी भी खड़ा नहीं हुआ और अब संसाधन प्रति सेकंड 600 कॉल तक पहुंच जाता है, संसाधन के दोनों हिस्से सामना करने के लिए संघर्ष करते हैं। दोनों php स्तर पर और MySQL स्तर पर प्लगइन्स। तीसरा सर्वर प्राप्त करने के बाद, इसके स्केलिंग के बारे में सवाल उठे, लेकिन मैं एक आदर्श विकल्प के बारे में नहीं सोच सकता था। और हब के पन्नों पर मैंने tmpfs में MySQL के बारे में एक विषय देखा। और मैंने सोचा, क्यों नहीं। आधार के साथ कुछ तैयारी का काम किया। जितना संभव हो उतना महत्वहीन लेकिन "ग्लूटोनस" कार्यों को हटाकर एक DB को कम किया। डेटाबेस में कुछ लॉगिंग कार्यों को हटा दिया। अंततः, डेटाबेस का वजन 11 से 2.5 जीबी तक कम हो गया था। और इसलिए, यह php के तहत 2 सर्वरों का उपयोग करने का निर्णय लिया गया था, और डोपिंग के साथ 3 लॉन्च MySQL पर। मानक mysqlhotcopy उपयोगिता बैकअप के साथ बहुत अच्छी तरह से मुकाबला करती है (1.5 सेकंड और आप कर रहे हैं!)। मैंने ऐसा किया। MySQL पर लोड 4 गुना कम हो गया, उत्पादकता भी बढ़ गई।

निष्कर्ष

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



काम की प्रक्रिया में, मेरे सहयोगी ( CentAlt ) ने मेरी बहुत मदद की, जिन्होंने सभी प्रयासों में हर संभव तरीके से मेरा समर्थन किया, और इसके लिए मैं उनका बहुत आभारी हूं। वैसे, शायद आप में से कुछ उसे जानते हैं। यह एक बहुत ही उपयोगी सेंटोस रिपॉजिटरी रखता है जहाँ आप नगनेक्स, php-fpm, अनबाउंड, क्लैमाव, पोस्टफिक्स, डॉककोट, आदि के नवीनतम संस्करण पा सकते हैं।



लेख बेहतर या लोकप्रिय होने का दावा नहीं करता है। यह कैसे या नहीं किया जाना चाहिए पर एक निर्देश नहीं है। यह एक अत्यधिक भरी हुई परियोजना की कहानी है, जिसे मैंने विकसित और प्रशासित करने के लिए किया।



अंत तक पढ़ने के लिए धन्यवाद!