PHP-FPM सेटअप: जास्तीत जास्त कामगिरीसाठी pm स्टॅटिक वापरा

या लेखाची असंपादित आवृत्ती मूळतः प्रकाशित झाली होती haydenjames.io आणि तिच्या परवानगीने येथे प्रकाशित केले लेखक.

थ्रोपुट वाढवण्यासाठी, लेटन्सी कमी करण्यासाठी आणि CPU आणि मेमरी अधिक सुसंगतपणे वापरण्यासाठी PHP-FPM कसे कॉन्फिगर करायचे ते मी थोडक्यात सांगेन. डीफॉल्टनुसार, PHP-FPM मधील PM (प्रक्रिया व्यवस्थापक) लाइन आहे डायनॅमिक, आणि आपल्याकडे पुरेशी मेमरी नसल्यास, स्थापित करणे चांगले आहे मागणी. चला php.net दस्तऐवजीकरणावर आधारित 2 नियंत्रण पर्यायांची तुलना करू आणि माझे आवडते त्यांच्यापेक्षा कसे वेगळे आहेत ते पाहू. स्थिर हाय व्हॉल्यूम रहदारीसाठी pm:

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

तपशीलांसाठी, पहा जागतिक निर्देशांची संपूर्ण यादी php-fpm.conf.

PHP-FPM प्रक्रिया व्यवस्थापक आणि CPU वारंवारता नियंत्रक यांच्यातील समानता

हे ऑफटॉपिक वाटू शकते, परंतु मी हे PHP-FPM कॉन्फिगरेशनच्या विषयाशी जोडणार आहे. लॅपटॉप, व्हर्च्युअल मशीन किंवा समर्पित सर्व्हरवर किमान एकदा तरी प्रोसेसर मंदावलीचा अनुभव कोणाला आला नाही? CPU वारंवारता स्केलिंग लक्षात ठेवा? साठी हे पर्याय उपलब्ध आहेत पासून प्रोसेसर थ्रॉटल सेटिंग बदलून nix आणि Windows सिस्टम कार्यप्रदर्शन आणि प्रतिसाद सुधारू शकतात मागणी वर कामगिरी*. या वेळी, वर्णनांची तुलना करू आणि समानता पाहू:

राज्यपाल = मागणी — सध्याच्या लोडवर अवलंबून प्रोसेसर फ्रिक्वेंसीचे डायनॅमिक स्केलिंग. वेगाने जास्तीत जास्त वारंवारतेवर उडी मारते आणि नंतर निष्क्रियतेचा कालावधी वाढल्याने तो कमी होतो.
राज्यपाल = पुराणमतवादी = वर्तमान लोडवर अवलंबून डायनॅमिक वारंवारता स्केलिंग. ऑनडिमांडपेक्षा अधिक सहजतेने वारंवारता वाढते आणि कमी होते.
राज्यपाल = कामगिरी - वारंवारता नेहमी जास्तीत जास्त असते.

तपशीलांसाठी, पहा प्रोसेसर फ्रिक्वेंसी रेग्युलेटर पॅरामीटर्सची संपूर्ण यादी.

समानता पहा? वापरणे उत्तम आहे हे पटवून देण्यासाठी मला ही तुलना दाखवायची होती pm स्थिर PHP-FPM साठी.

प्रोसेसर रेग्युलेटर पॅरामीटरसाठी कामगिरी सुरक्षितपणे कार्यप्रदर्शन वाढवण्यास मदत करते कारण ते जवळजवळ पूर्णपणे सर्व्हरच्या CPU मर्यादेवर अवलंबून असते. या व्यतिरिक्त, अर्थातच, तापमान, बॅटरी चार्ज (लॅपटॉपमध्ये) आणि प्रोसेसर 100% वर सतत चालवण्याचे इतर दुष्परिणाम यासारखे घटक देखील आहेत. कार्यप्रदर्शन सेटिंग सर्वात वेगवान प्रोसेसर कार्यप्रदर्शन सुनिश्चित करते. वाचा, उदाहरणार्थ, बद्दल रास्पबेरी पाई मध्ये force_turbo पॅरामीटर, ज्यासह RPi पॅनेल रेग्युलेटर वापरेल कामगिरी, जेथे कमी CPU घड्याळ गतीमुळे कार्यप्रदर्शन सुधारणा अधिक लक्षणीय असेल.

जास्तीत जास्त सर्व्हर कार्यप्रदर्शन प्राप्त करण्यासाठी pm स्टॅटिक वापरणे

PHP-FPM पर्याय pm स्थिर मुख्यत्वे सर्व्हरवरील विनामूल्य मेमरीवर अवलंबून असते. मेमरी कमी असल्यास, निवडणे चांगले आहे मागणी किंवा डायनॅमिक. दुसरीकडे, तुमच्याकडे मेमरी असल्यास, तुम्ही pm सेट करून PHP प्रक्रिया व्यवस्थापक ओव्हरहेड टाळू शकता स्थिर कमाल सर्व्हर क्षमतेपर्यंत. दुसऱ्या शब्दांत, सर्वकाही व्यवस्थित मोजले असल्यास, आपल्याला स्थापित करणे आवश्यक आहे pm.static PHP-FPM प्रक्रियेच्या जास्तीत जास्त व्हॉल्यूमपर्यंत ज्या कार्यान्वित केल्या जाऊ शकतात, कमी मेमरी किंवा कॅशेमध्ये समस्या निर्माण न करता. परंतु इतके उच्च नाही की ते प्रोसेसरला ओलांडून टाकते आणि PHP-FPM ऑपरेशन्सची अंमलबजावणी होण्याची प्रतीक्षा करते..

वरील स्क्रीनशॉटमध्ये, सर्व्हरकडे आहे pm = स्थिर आणि pm.max_children = 100, आणि हे उपलब्ध 10 पैकी अंदाजे 32 GB घेते. हायलाइट केलेल्या स्तंभांकडे लक्ष द्या, येथे सर्वकाही स्पष्ट आहे. या स्क्रीनशॉटमध्ये 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 आणि प्रति सेकंद विनंत्यांची संख्या.

स्क्रीनशॉट कमांड दाखवतो लिनक्स शीर्ष, u (वापरकर्ता) आणि PHP-FPM वापरकर्तानावाद्वारे फिल्टर केलेले. फक्त पहिल्या 50 किंवा त्यापेक्षा जास्त प्रक्रिया दाखवल्या जातात (मी नेमके मोजले नाही), परंतु मुख्यत: शीर्षस्थानी टर्मिनल विंडोमध्ये बसणारी शीर्ष आकडेवारी दर्शवते. या प्रकरणात % CPU (% CPU) नुसार क्रमवारी लावली आहे. सर्व 100 PHP-FPM प्रक्रिया पाहण्यासाठी, कमांड चालवा:

top -bn1 | grep php-fpm

pm ondemand आणि dynamic कधी वापरायचे

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

PM डायनॅमिक आणि विशेषतः मागणी तुमच्याकडे एकापेक्षा जास्त PHP-FPM पूल असल्यास ते उपयोगी पडू शकते. उदाहरणार्थ, तुम्ही वेगवेगळ्या पूलमध्ये एकाधिक cPanel खाती किंवा एकाधिक वेबसाइट होस्ट करता. माझ्याकडे 100+ cpanel खाती आणि सुमारे 200 डोमेन असलेला सर्व्हर आहे आणि pm.static किंवा अगदी डायनॅमिक मला वाचवू शकणार नाही. आपल्याला येथे आवश्यक आहे मागणी, शेवटी, दोन तृतीयांश पेक्षा जास्त वेबसाइटना कमी किंवा कमी रहदारी प्राप्त होते आणि त्यासह मागणी सर्व बाल प्रक्रिया बंद होतील, ज्यामुळे आपली बरीच स्मरणशक्ती वाचेल! सुदैवाने, cPanel विकासकांनी हे लक्षात घेतले आणि मूल्य डीफॉल्टवर सेट केले मागणी. पूर्वी, जेव्हा डीफॉल्ट होते डायनॅमिक, PHP-FPM व्यस्त सामायिक सर्व्हरसाठी अजिबात योग्य नव्हते. अनेकांनी वापरले आहेत suPHP, कारण दुपारी डायनॅमिक निष्क्रिय पूल आणि cPanel PHP-FPM खात्यांसह देखील मेमरी वापरली. बहुधा, रहदारी चांगली असल्यास, तुम्हाला मोठ्या संख्येने PHP-FPM पूल (शेअर होस्टिंग) असलेल्या सर्व्हरवर होस्ट केले जाणार नाही.

निष्कर्ष

तुम्ही PHP-FPM वापरत असल्यास आणि तुमची रहदारी जास्त असल्यास, प्रक्रिया व्यवस्थापक मागणी и डायनॅमिक PHP-FPM साठी त्यांच्या अंतर्निहित ओव्हरहेडमुळे मर्यादित थ्रूपुट असेल. तुमची प्रणाली समजून घ्या आणि कमाल सर्व्हर क्षमतेनुसार PHP-FPM प्रक्रिया कॉन्फिगर करा. पहिला सेट pm.max_children जास्तीत जास्त pm वापरावर अवलंबून डायनॅमिक किंवा मागणी, आणि नंतर हे मूल्य अशा स्तरावर वाढवा जेथे मेमरी आणि प्रोसेसर ओव्हरलोड न होता कार्य करतील. सह तुमच्या लक्षात येईल pm स्थिर, तुमच्याकडे सर्व काही मेमरीमध्ये असल्याने, ट्रॅफिक स्पाइकमुळे कालांतराने कमी CPU स्पाइक्स होतील आणि सर्व्हर आणि CPU लोडची सरासरी पातळी कमी होईल. सरासरी PHP-FPM प्रक्रियेचा आकार वेब सर्व्हरवर अवलंबून असतो आणि त्यासाठी मॅन्युअल कॉन्फिगरेशन आवश्यक असते, त्यामुळे अधिक स्वयंचलित प्रक्रिया व्यवस्थापक आहेत डायनॅमिक и मागणी - अधिक लोकप्रिय. मला आशा आहे की लेख उपयुक्त होता.

DUP बेंचमार्क चार्ट जोडला ab. PHP-FPM प्रक्रिया मेमरीमध्ये असल्यास, मेमरी वापराच्या खर्चावर कार्यप्रदर्शन वाढते जेथे ते बसतात आणि प्रतीक्षा करतात. स्वतःसाठी सर्वोत्तम पर्याय शोधा.

स्त्रोत: www.habr.com