हमारा अनुभव वीडियो सामग्री वितरित करने के लिए nginx का अनुकूलन करता है

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


तो, निश्चित रूप से, हर कोई जानता है कि नग्नेक्स स्टैटिक्स को सबसे अच्छे से संभालता है। बेशक, उचित कॉन्फ़िगरेशन अनुकूलन के साथ। यह परियोजना कोई अपवाद नहीं थी - नग्नेक्स और सभी स्टैटिक्स वितरित करता है। असल में, यह ग्राफिक और ऑडियो / वीडियो सामग्री है, विशेष रूप से 50 एमबी से 2 जीबी तक की वीडियो फ़ाइलों में। नग्नेक्स अपने कार्य के साथ पूरी तरह से मुकाबला करता है, इसके अलावा, हमारी टीम ने पहले से ही इसे ठीक करने में बहुत अनुभव प्राप्त किया है। लेकिन, एक तरह से या किसी अन्य, समस्याएं हमेशा पैदा होती हैं, और उनके समाधान हमेशा सतह पर नहीं होते हैं। हमारे मामले में, पीक लोड में कठिनाइयाँ उत्पन्न होने लगीं, जब पोर्टल पर वीडियो सामग्री का "ताज़ा भाग" अपलोड कर दिया गया। सरल शब्दों में, सिस्टम ने डिस्क पर आराम किया। डिस्क सबसिस्टम पर एक सौ प्रतिशत लोड एक पंक्ति में कई घंटों तक रह सकता है, जैसा कि नीचे दिए गए ग्राफ़ में देखा जा सकता है।


परिणामस्वरूप - सामग्री वितरण और असंतुष्ट उपयोगकर्ताओं की बहुत कम गति।

उस समय स्टैटिक्स के वितरण के लिए जिम्मेदार कॉन्फ़िगरेशन फ़ाइल का हिस्सा:

location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp3|mp4|3gp)$ { aio on; directio 512; output_buffers 1 512k; root /srv/www/htdocs; } 

ऐसे मामलों में स्थिति को कैसे बेहतर बनाया जा सकता है? इस विषय पर हैबे (और न केवल) पर कई लेख हैं और उनसे टिप्पणियों में कई उपयोगी युक्तियां हैं। यह माना जाता है कि स्टैटिक को वितरित करने के लिए एक तेज़ एसएसडी कैश सबसे अच्छा उपाय है। किसी को लगता है कि वीएफएस में कैश बड़ी संख्या में छोटी फ़ाइलों के लिए अच्छा है, जबकि यह चयनित अनुभाग की सीमाओं में फिट बैठता है। एसएसडी विकल्प शायद अच्छा है, लेकिन सभी के लिए उपयुक्त नहीं है, क्योंकि कभी-कभी बस एक और ड्राइव को जोड़ने की शारीरिक क्षमता नहीं होती है, एक जोड़े का उल्लेख नहीं करना है। RAM को कैश विभाजन में आवंटित करना एक अच्छा समाधान नहीं है, लिनक्स कर्नेल (हम केवल लिनक्स का उपयोग करते हैं) कैशिंग का एक अच्छा काम करता है, और मुफ्त रैम हमेशा पर्याप्त नहीं होता है।
हमारे मामले में, बहुत सारी मुफ्त रैम थी (प्रत्येक सर्वर पर 16 जीबी तक 90%)। लेकिन इसका सही इस्तेमाल कैसे किया जा सकता है? यह अपलोड बफर को 512 केबी से बढ़ाकर 8 एमबी करने का निर्णय लिया गया था:

 location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|js|swf|flv|avi|djvu|mp3|mp4|3gp)$ { aio on; directio 512; output_buffers 1 8m; root /srv/www/htdocs; } 

यह औसतन डेढ़ से दो बार डिस्क पर लोड को कम करने के लिए पर्याप्त निकला। वेब सर्वर की मेमोरी खपत में काफी वृद्धि हुई है (औसतन, कुल के 70 से 90% तक)।
नीचे दिया गया ग्राफ़ दिखाता है कि अनुकूलन के बाद डिस्क लोड कैसे बदला गया:


नेटवर्क लोड ग्राफ। आउटगोइंग ट्रैफ़िक औसतन डेढ़ से दो गुना बढ़ा:


अनुकूलन के बाद रैम की खपत में परिवर्तन का ग्राफ:



बफर सेटिंग्स के साथ प्रयोगों के परिणामस्वरूप, लोड शिखरों तक सामग्री वितरण की गति औसतन 1 एमबी / एस प्रति उपयोगकर्ता है, जो एक स्वीकार्य परिणाम है। सेवा स्थिर है, ग्राहक संतुष्ट है, उपयोगकर्ता भी।

उपयोगी लेख:
नग्नेक्स विकी
ट्यूनिंग नग्नेक्स
5 मिनट में Nginx को गति दें
Nginx सुरक्षित वेब सर्वर