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

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

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

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

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

PHP-FPM प्रक्रिया प्रबंधक और CPU आवृत्ति नियंत्रक के बीच समानताएँ

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

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

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

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

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

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

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

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

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

top -bn1 | grep php-fpm

पीएम ऑनडिमांड और डायनामिक का उपयोग कब करें

यदि आप 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.min को पर्याप्त रूप से समायोजित करना मुश्किल है गतिशील. आमतौर पर pm का प्रयोग किया जाता है ondemand, जैसा कि उसी पोस्ट में सलाह दी गई है. लेकिन यह और भी बुरा है, क्योंकि ondemand कम या कोई ट्रैफ़िक न होने पर निष्क्रिय प्रक्रियाओं को शून्य पर समाप्त कर देता है, और आप अभी भी ट्रैफ़िक बदलने के ओवरहेड के साथ समाप्त हो जाएंगे। जब तक, निश्चित रूप से, आप एक बड़ा प्रतीक्षा समय निर्धारित नहीं करते। और फिर इसका उपयोग करना बेहतर है pm.static + उच्च संख्या pm.max_requests.

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

निष्कर्ष

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

युपीडी बेंचमार्क चार्ट जोड़ा गया ab. यदि PHP-FPM प्रक्रियाएं मेमोरी में हैं, तो जहां वे बैठते हैं और प्रतीक्षा करते हैं, वहां मेमोरी खपत की कीमत पर प्रदर्शन बढ़ जाता है। अपने लिए सर्वोत्तम विकल्प खोजें.

स्रोत: www.habr.com