إعداد PHP-FPM: استخدم pm static لأقصى أداء

تم نشر نسخة غير محررة من هذه المقالة في الأصل على haydenjames.io ونشرت هنا بإذنها автора.

سأخبرك باختصار عن أفضل السبل لتكوين PHP-FPM لزيادة الإنتاجية وتقليل زمن الوصول واستخدام وحدة المعالجة المركزية والذاكرة بشكل أكثر اتساقًا. افتراضيًا، يكون سطر PM (مدير العمليات) في PHP-FPM هو ديناميكيوإذا لم يكن لديك ذاكرة كافية فمن الأفضل التثبيت على الطلب. دعونا نقارن بين خيارين للتحكم بناءً على وثائق php.net ونرى كيف يختلف خياري المفضل عنهما ساكن مساءً لحركة المرور ذات الحجم الكبير:

مساء = ديناميكي - يتم تكوين عدد العمليات الفرعية ديناميكيًا بناءً على التوجيهات التالية: 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 ووحدة التحكم في تردد وحدة المعالجة المركزية

قد يبدو هذا خارج الموضوع، ولكنني سأربط هذا بموضوع تكوين PHP-FPM. من منا لم يواجه تباطؤًا في المعالج مرة واحدة على الأقل - على جهاز كمبيوتر محمول أو جهاز افتراضي أو خادم مخصص؟ تذكر تحجيم تردد وحدة المعالجة المركزية؟ هذه الخيارات متاحة ل يمكن لـ nix وWindows تحسين أداء النظام واستجابته عن طريق تغيير إعداد دواسة الوقود للمعالج من على الطلب في أداء*. هذه المرة، دعونا نقارن الأوصاف وننظر إلى أوجه التشابه:

محافظ=حسب الطلب - التحجيم الديناميكي لتردد المعالج حسب الحمل الحالي. يقفز بسرعة إلى الحد الأقصى للتردد ثم يقلله مع زيادة فترات عدم النشاط.
المحافظ=المحافظ= تحجيم التردد الديناميكي اعتمادا على الحمل الحالي. يزيد ويقلل التردد بشكل أكثر سلاسة من عند الطلب.
الحاكم = الأداء - التردد هو الحد الأقصى دائمًا.

لمزيد من التفاصيل، انظر القائمة الكاملة لمعلمات منظم تردد المعالج.

انظر أوجه التشابه؟ أردت أن أظهر هذه المقارنة لإقناعك بأنه الأفضل للاستخدام مساء ثابت ل PHP-FPM.

لمعلمة منظم المعالج أداء يساعد على زيادة الأداء بأمان لأنه يعتمد بشكل كامل تقريبًا على حد وحدة المعالجة المركزية للخادم. بالإضافة إلى ذلك، بالطبع، هناك أيضًا عوامل مثل درجة الحرارة وشحن البطارية (في الكمبيوتر المحمول) وغيرها من الآثار الجانبية لتشغيل المعالج باستمرار بنسبة 100%. يضمن إعداد الأداء أسرع أداء للمعالج. اقرأ، على سبيل المثال، عن معلمة force_turbo في Raspberry Pi، والتي ستستخدم بها لوحة RPi المنظم أداء، حيث سيكون تحسن الأداء أكثر وضوحًا بسبب انخفاض سرعة ساعة وحدة المعالجة المركزية.

استخدام PM static لتحقيق أقصى أداء للخادم

خيار PHP-FPM مساء ثابت يعتمد إلى حد كبير على الذاكرة الحرة على الخادم. إذا كانت الذاكرة منخفضة، فمن الأفضل أن تختار على الطلب أو ديناميكي. من ناحية أخرى، إذا كانت لديك ذاكرة، فيمكنك تجنب الحمل الزائد لمدير عمليات PHP عن طريق ضبط PM ساكن إلى الحد الأقصى لسعة الخادم. وبعبارة أخرى، إذا تم حساب كل شيء بشكل جيد، فأنت بحاجة إلى إنشاء مساء.ثابت إلى الحد الأقصى لحجم عمليات PHP-FPM التي يمكن تنفيذها، دون خلق مشاكل مع انخفاض الذاكرة أو ذاكرة التخزين المؤقت. ولكنها ليست عالية لدرجة أنها تطغى على المعالجات وتراكم مجموعة من عمليات PHP-FPM في انتظار تنفيذها.

في لقطة الشاشة أعلاه، الخادم لديه مساء = ثابت وpm.max_children = 100، وهذا يستغرق حوالي 10 غيغابايت من أصل 32 غيغابايت المتاحة. انتبه إلى الأعمدة المميزة، كل شيء واضح هنا. في لقطة الشاشة هذه، كان هناك ما يقرب من 200 مستخدم نشط (أكثر من 60 ثانية) في Google Analytics. على هذا المستوى، ما يقرب من 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). لرؤية جميع عمليات PHP-FPM الـ 100، قم بتشغيل الأمر:

top -bn1 | grep php-fpm

متى تستخدم مساءً عند الطلب وديناميكيًا

إذا كنت تستخدم مساء ديناميكي، تحدث أخطاء مثل هذا:

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

حاول تغيير المعلمة، فإن الخطأ لن يختفي، مثل الموصوفة في هذا المنشور على Serverfault. في هذه الحالة، كانت قيمة PM.min صغيرة جدًا، وبما أن حركة مرور الويب تختلف كثيرًا ولها قمم عالية وأودية عميقة، فمن الصعب ضبط PM بشكل مناسب ديناميكي. عادة ما يتم استخدام مساء على الطلب, كما نصحت في نفس المنصب. ولكن هذا هو أسوأ من ذلك، لأنه على الطلب ينهي العمليات الخاملة إلى الصفر عندما تكون حركة المرور قليلة أو معدومة، وسيظل الأمر ينتهي بك الأمر مع تحمل عبء تغيير حركة المرور. ما لم تقم بالطبع بتعيين وقت انتظار كبير. وبعد ذلك من الأفضل استخدامه مساء.ثابت + رقم مرتفع 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 اعتمادا على الحد الأقصى لاستخدام مساء ديناميكي أو على الطلب، ثم قم بزيادة هذه القيمة إلى المستوى الذي ستعمل فيه الذاكرة والمعالج دون تحميل زائد. ستلاحظ ذلك مع مساء ثابت، نظرًا لوجود كل شيء في الذاكرة، فإن الزيادات في حركة المرور ستؤدي إلى ارتفاعات أقل في وحدة المعالجة المركزية بمرور الوقت، وستنخفض متوسطات تحميل الخادم ووحدة المعالجة المركزية. يعتمد متوسط ​​حجم عملية PHP-FPM على خادم الويب ويتطلب تكوينًا يدويًا، لذلك يوجد المزيد من مديري العمليات الآلية ديناميكي и على الطلب - اكثر شهرة. أتمنى أن يكون المقال مفيدا.

UPD تمت إضافة الرسم البياني القياسي ab. إذا كانت عمليات PHP-FPM موجودة في الذاكرة، فسيزداد الأداء على حساب استهلاك الذاكرة حيث تجلس وتنتظر. ابحث عن الخيار الأفضل لنفسك.

المصدر: www.habr.com