PHP-FPM ट्यूनिंग: अधिकतम प्रदर्शन के लिए pm स्टेटिक का उपयोग करना

लेख का एक संयुक्त संस्करण मूल रूप से haydenjames.io पर प्रकाशित किया गया था और अपने लेखक की अनुमति से यहाँ प्रकाशित किया गया है।

संक्षेप में, मैं थ्रूपुट को कम करने के लिए PHP-FPM को कॉन्फ़िगर करने के लिए सबसे अच्छा कैसे करूंगा, विलंबता को कम करने और प्रोसेसर संसाधनों और स्मृति के अधिक स्थिर उपयोग के बारे में बात करूँगा। डिफ़ॉल्ट रूप से, PHP-FPM में स्ट्रिंग PM (प्रोसेस मैनेजर) गतिशील है , और यदि आपके पास पर्याप्त मेमोरी नहीं है, तो ondemand को स्थापित करना बेहतर है। आइए php.net प्रलेखन के आधार पर 2 नियंत्रण विकल्पों की तुलना करें और देखें कि बड़ी मात्रा में ट्रैफ़िक के लिए मेरा पसंदीदा स्थिर दोपहर उनसे कैसे भिन्न है:

दोपहर = गतिशील - निम्नलिखित प्रक्रियाओं के आधार पर बाल प्रक्रियाओं की संख्या को गतिशील रूप से कॉन्फ़िगर किया गया है: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_sersers ।
pm = ondemand - माँग पर प्रक्रियाएँ बनाई जाती हैं (डायनामिक निर्माण के विपरीत, जब pm.start_servers सेवा शुरू होने पर शुरू की जाती है)।
pm = static - चाइल्ड प्रॉसेस की संख्या पैरामीटर pm.max_children द्वारा निर्धारित और निर्दिष्ट है।

विवरण के लिए वैश्विक php-fpm.conf निर्देशों की पूरी सूची देखें ।

प्रोसेसर आवृत्ति नियंत्रक के साथ PHP-FPM प्रक्रिया प्रबंधक की समानताएं

यह अपमानजनक लग सकता है, लेकिन मैं इसे PHP-FPM कॉन्फ़िगरेशन विषय से संबंधित करने जा रहा हूं। जो कोई भी कम से कम एक बार प्रोसेसर को धीमा नहीं करता है - एक लैपटॉप, वर्चुअल मशीन या एक समर्पित सर्वर पर। प्रोसेसर आवृत्ति की स्केलिंग याद है? निक्स और विंडोज के लिए उपलब्ध ये विकल्प, प्रोसेसर कंट्रोलर सेटिंग को ऑनडेमैंड से प्रदर्शन * में बदलकर सिस्टम प्रदर्शन और जवाबदेही को बेहतर बना सकते हैं । इस बार, आइए विवरणों की तुलना करें और समानताएं देखें:

गवर्नर = ऑनडेमैंड - वर्तमान लोड के आधार पर प्रोसेसर आवृत्ति की गतिशील स्केलिंग। तेजी से अधिकतम आवृत्ति पर स्विच करता है, और फिर निष्क्रिय अवधि बढ़ने पर इसे कम कर देता है।
राज्यपाल = रूढ़िवादी = वर्तमान लोड के आधार पर गतिशील आवृत्ति स्केलिंग। Ondemand की तुलना में आवृत्ति चिकनी बढ़ जाती है और घट जाती है।
राज्यपाल = प्रदर्शन - आवृत्ति हमेशा अधिकतम होती है।

विवरण के लिए प्रोसेसर आवृत्ति नियंत्रक मापदंडों की पूरी सूची देखें।

समानता देखें? मैं आपको यह समझाने के लिए तुलना करना चाहता था कि PHP-FPM के लिए pm स्टेटिक का उपयोग करना सबसे अच्छा है।

प्रोसेसर नियंत्रक के लिए, प्रदर्शन पैरामीटर सुरक्षित रूप से प्रदर्शन को बढ़ाने में मदद करता है क्योंकि यह लगभग पूरी तरह से सर्वर प्रोसेसर की सीमा पर निर्भर करता है। इसके अलावा, निश्चित रूप से, तापमान, बैटरी चार्ज (एक लैपटॉप में) और 100% पर निरंतर प्रोसेसर संचालन के अन्य दुष्प्रभावों जैसे कारक भी हैं। प्रदर्शन ट्यूनिंग सबसे तेज़ प्रोसेसर प्रदर्शन प्रदान करता है। उदाहरण के लिए, रास्पबेरी पाई में बल_टर्बो पैरामीटर के बारे में पढ़ें, जिसके साथ आरपीआई पैनल प्रदर्शन नियामक का उपयोग करेगा, जहां सीपीयू की कम घड़ी की गति के कारण प्रदर्शन में सुधार अधिक ध्यान देने योग्य होगा।

सर्वर प्रदर्शन को अधिकतम करने के लिए pm स्टेटिक का उपयोग करना

PHP-FPM pm स्टैटिक पैरामीटर काफी हद तक सर्वर पर मुफ्त मेमोरी पर निर्भर करता है। यदि मेमोरी कम है, तो ऑनडैमैंड या डायनामिक चुनना बेहतर है। दूसरी ओर, यदि आपके पास मेमोरी है, तो आप अधिकतम सर्वर क्षमता के लिए दोपहर स्थिर सेट करके PHP प्रक्रिया प्रबंधक के ओवरहेड से बच सकते हैं। दूसरे शब्दों में, यदि सब कुछ अच्छी तरह से गणना की जाती है, तो आपको पीएसपी-एफपीएम प्रक्रियाओं की अधिकतम मात्रा में सेट करने की आवश्यकता है जो अपर्याप्त मेमोरी या कैश के साथ समस्याएं पैदा किए बिना निष्पादित की जा सकती हैं । लेकिन प्रोसेसर को ओवरलोड करने के लिए इतना अधिक नहीं है और निष्पादन की प्रतीक्षा में PHP-FPM संचालन का एक गुच्छा जमा करता है ।

ऊपर दिए गए स्क्रीनशॉट में, सर्वर में pm = static और pm.max_children = 100 स्थापित है, और यह 32 में से लगभग 10 GB उपलब्ध है। हाइलाइट किए गए कॉलम पर ध्यान दें, यहाँ सब कुछ स्पष्ट है। इस स्क्रीनशॉट में, Google Analytics में लगभग 200 सक्रिय उपयोगकर्ता (60 सेकंड से अधिक) थे। इस स्तर पर, PHP-FPM बाल प्रक्रियाओं का लगभग 70% अभी भी निष्क्रिय है। इसका अर्थ है कि PHP-FPM हमेशा वर्तमान ट्रैफ़िक की परवाह किए बिना, सर्वर संसाधनों की अधिकतम मात्रा के लिए सेट है। एक निष्क्रिय प्रक्रिया ट्रैफ़िक चोटियों की प्रतीक्षा करती है और तुरंत प्रतिक्रिया देती है। बाल प्रक्रियाएं बनाने के लिए आपको पीएम का इंतजार करने की जरूरत नहीं है और जब पी.एम.प्रोसेस_डल_टाइम समाप्त हो जाता है तो उन्हें समाप्त कर दें। मैंने pm.max_requests के लिए बहुत अधिक मूल्य निर्धारित किया है, क्योंकि यह PHP में मेमोरी लीक के बिना एक काम करने वाला सर्वर है। यदि आप मौजूदा और भविष्य की PHP स्क्रिप्ट में पूरी तरह से आश्वस्त हैं, तो आप pm.max_requests = 0 को स्थैतिक के साथ सेट कर सकते हैं। लेकिन समय के साथ लिपियों को फिर से शुरू करना बेहतर है। बड़ी संख्या में क्वेरीज़ स्थापित करें, क्योंकि हम दोपहर के अनावश्यक ओवरहेड से बचना चाहते हैं। उदाहरण के लिए, कम से कम pm.max_requests = 1000 - pm.max_children की संख्या और प्रति सेकंड अनुरोधों की संख्या के आधार पर।

स्क्रीनशॉट यू (उपयोगकर्ता) और PHP-FPM उपयोगकर्ता नाम से फ़िल्टर किए गए लिनक्स शीर्ष कमांड को दिखाता है। केवल पहले 50 या तो प्रक्रियाओं को दिखाया गया है (मैं बिल्कुल गणना नहीं करता), लेकिन, वास्तव में, शीर्ष उन शीर्ष आँकड़ों को दिखाता है जो टर्मिनल विंडो में रखे गए हैं। इस स्थिति में,% CPU (% CPU) द्वारा सॉर्ट किया जाता है। सभी 100 PHP-FPM प्रक्रियाओं को देखने के लिए, कमांड चलाएँ:

top -bn1 | grep php-fpm 

दोपहर का उपयोग कब करें ondand और गतिशील

यदि आप pm डायनामिक का उपयोग करते हैं, तो आपको समान त्रुटियाँ मिलती हैं:

 WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children 

पैरामीटर बदलने की कोशिश करें, त्रुटि कहीं भी नहीं जाएगी, जैसा कि सर्वरफॉल्ट पर इस पोस्ट में वर्णित है । इस स्थिति में, pm.min का मान बहुत छोटा था, और चूंकि वेब ट्रैफ़िक बहुत बदल जाता है और ऊंची चोटियाँ और गहरी बूंदें होती हैं, इसलिए पर्याप्त रूप से pm डायनामिक रूप से कॉन्फ़िगर करना मुश्किल है। यह आमतौर पर pm ondand का उपयोग करता है, जैसा कि एक ही पोस्ट में सलाह दी गई है । लेकिन यह और भी बुरा है, क्योंकि ondemand निष्क्रिय प्रक्रियाओं को तब शून्य करता है जब ट्रैफ़िक बहुत कम या बिल्कुल नहीं होता है, और परिणामस्वरूप, ट्रैफ़िक में परिवर्तन होने पर भी आप लागतों से ग्रस्त होंगे। जब तक, निश्चित रूप से, आपने एक विशाल प्रतीक्षा समय निर्धारित किया है। और फिर pm.static + pm.max_requests की उच्च संख्या का उपयोग करना बेहतर है।

यदि आपके पास कई PHP-FPM पूल हैं, तो पीएम डायनामिक और विशेष रूप से ऑनडेमैंड काम में आ सकता है। उदाहरण के लिए, आप विभिन्न पूलों में कई cPanel खातों या कई वेबसाइटों की मेजबानी करते हैं। मेरे पास एक सर्वर है, उदाहरण के लिए, 100+ cpanel खाते और लगभग 200 डोमेन, और pm.static या डायनामिक भी मुझे नहीं बचाएंगे। यहाँ केवल ondemand की आवश्यकता है, क्योंकि दो तिहाई से अधिक वेबसाइटों को बहुत कम या बिल्कुल भी ट्रैफ़िक प्राप्त नहीं होता है, और ondemand के साथ सभी चाइल्ड प्रोसेस बंद हो जाएंगे, जिससे हमारी बहुत सारी मेमोरी बच जाएगी! सौभाग्य से, cPanel डेवलपर्स ने इस पर ध्यान दिया और डिफ़ॉल्ट मान को ondemand पर सेट किया। पहले, जब डिफ़ॉल्ट मान गतिशील था, PHP-FPM व्यस्त साझा सर्वर के लिए बिल्कुल भी उपयुक्त नहीं था। कई ने suPHP का इस्तेमाल किया क्योंकि शाम को गतिशील खपत भी बेकार पूल और cPanel PHP-FPM खातों के साथ स्मृति। सबसे अधिक संभावना है, अच्छे ट्रैफ़िक के साथ, आपको बड़ी संख्या में PHP-FPM पूल (साझा होस्टिंग) वाले सर्वर पर होस्ट नहीं किया जाएगा।

निष्कर्ष

यदि आप PHP-FPM का उपयोग करते हैं और आपके पास भारी ट्रैफ़िक है, तो PHP-FPM के लिए ondemand और डायनेमिक प्रक्रिया प्रबंधक उनकी अंतर्निहित लागत के कारण बैंडविड्थ को सीमित कर देंगे। अपने सिस्टम की जांच करें और अपनी अधिकतम सर्वर क्षमता से मिलान करने के लिए अपने PHP-FPM प्रक्रियाओं को कॉन्फ़िगर करें। सबसे पहले pm.max_children को pm डायनामिक या ऑनडेमैंड के अधिकतम उपयोग के आधार पर सेट करें, और फिर इस मान को उस स्तर तक बढ़ाएं जहां मेमोरी और प्रोसेसर अत्यधिक अधिभार के बिना काम करेंगे। आप देखेंगे कि pm स्टैटिक के साथ, चूंकि सब कुछ मेमोरी में संग्रहीत है, समय के साथ ट्रैफ़िक चोटियां प्रोसेसर के लिए कम चोटियों का कारण बनेंगी, और औसत सर्वर और प्रोसेसर लोड मान बराबर हो जाएंगे। औसत PHP-FPM प्रक्रिया का आकार वेब सर्वर पर निर्भर करता है और मैन्युअल कॉन्फ़िगरेशन की आवश्यकता होती है, इसलिए अधिक स्वचालित प्रक्रिया प्रबंधक - डायनामिक और ऑनडेमैंड - अधिक लोकप्रिय हैं। आशा है कि लेख उपयोगी था।

UPD ने बेंचमार्क आरेख को जोड़ा। यदि PHP-FPM प्रक्रियाएं स्मृति में हैं, तो मेमोरी का उपभोग करने से प्रदर्शन में सुधार होता है जहां वे बैठते हैं और प्रतीक्षा करते हैं। अपने लिए सबसे अच्छा विकल्प खोजें।