تنظیم PHP-FPM: از pm static برای حداکثر کارایی استفاده کنید

نسخه ویرایش نشده این مقاله در ابتدا در تاریخ منتشر شد haydenjames.io و با اجازه او در اینجا منتشر شد نویسنده.

من به طور خلاصه بهترین راه را برای پیکربندی PHP-FPM برای افزایش توان عملیاتی، کاهش تأخیر و استفاده از CPU و حافظه به طور مداوم توضیح خواهم داد. به طور پیش فرض، خط PM (مدیر فرآیند) در PHP-FPM است پویاو اگر حافظه کافی ندارید بهتر است نصب کنید بر اساس تقاضا. بیایید 2 گزینه کنترل را بر اساس مستندات php.net مقایسه کنیم و ببینیم مورد علاقه من چه تفاوتی با آنها دارد. ایستا 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 پیوند دهم. چه کسی حداقل یک بار کاهش سرعت پردازنده را تجربه نکرده است - در لپ تاپ، ماشین مجازی یا سرور اختصاصی؟ مقیاس فرکانس پردازنده را به خاطر دارید؟ این گزینه ها برای nix و Windows می توانند با تغییر تنظیمات دریچه گاز پردازنده، عملکرد و پاسخگویی سیستم را بهبود بخشند بر اساس تقاضا بر کارایی*. این بار، بیایید توضیحات را با هم مقایسه کنیم و شباهت ها را بررسی کنیم:

فرماندار = خواستگار - مقیاس بندی پویا فرکانس پردازنده بسته به بار فعلی. به سرعت به حداکثر فرکانس می پرد و سپس با افزایش دوره های عدم فعالیت آن را کاهش می دهد.
استاندار=محافظه کار= مقیاس بندی فرکانس دینامیکی بسته به بار فعلی. فرکانس را راحتتر از درخواستی افزایش و کاهش می دهد.
فرماندار = عملکرد - فرکانس همیشه حداکثر است.

برای جزئیات، نگاه کنید لیست کامل پارامترهای تنظیم کننده فرکانس پردازنده.

شباهت ها را می بینید؟ من می خواستم این مقایسه را نشان دهم تا شما را متقاعد کنم که استفاده از آن بهترین است pm ثابت برای PHP-FPM.

برای پارامتر تنظیم کننده پردازنده کارایی به افزایش ایمن عملکرد کمک می کند زیرا تقریباً به طور کامل به محدودیت CPU سرور بستگی دارد. علاوه بر این، البته عواملی مانند دما، شارژ باتری (در لپ تاپ) و سایر عوارض جانبی کارکردن مداوم پردازنده در 100 درصد نیز وجود دارد. تنظیمات عملکرد سریعترین عملکرد پردازنده را تضمین می کند. به عنوان مثال، در مورد پارامتر force_turbo در رزبری پایکه با آن پنل RPi از رگولاتور استفاده خواهد کرد کارایی، که در آن بهبود عملکرد به دلیل سرعت پایین کلاک CPU بیشتر محسوس خواهد بود.

استفاده از pm static برای دستیابی به حداکثر عملکرد سرور

گزینه PHP-FPM pm ثابت تا حد زیادی به حافظه رایگان سرور بستگی دارد. اگر حافظه کم است، بهتر است انتخاب کنید بر اساس تقاضا یا پویا. از طرف دیگر، اگر حافظه دارید، می توانید با تنظیم pm از سربار مدیر فرآیند PHP جلوگیری کنید ایستا به حداکثر ظرفیت سرور به عبارت دیگر، اگر همه چیز به خوبی محاسبه شود، باید ایجاد کنید pm.static به حداکثر حجم فرآیندهای PHP-FPM قابل اجرا، بدون ایجاد مشکل با حافظه کم یا کش. اما نه آنقدر بالا که پردازنده ها را غرق کند و دسته ای از عملیات PHP-FPM را در انتظار اجرا جمع کند..

در تصویر بالا، سرور دارای pm = استاتیک و 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 با static اگر به اسکریپت های موجود و آینده PHP کاملاً مطمئن هستید. اما بهتر است فیلمنامه ها به مرور زمان دوباره اجرا شوند. تعداد زیادی درخواست تنظیم کنید، زیرا می خواهیم از هزینه های غیر ضروری pm جلوگیری کنیم. مثلا حداقل pm.max_requests = 1000 - بسته به مقدار pm.max_children و تعداد درخواست ها در ثانیه

اسکرین شات فرمان را نشان می دهد بالای لینوکس، توسط u (کاربر) و نام کاربری PHP-FPM فیلتر شده است. فقط 50 یا بیشتر فرآیند اول نشان داده می شود (من دقیقاً حساب نکردم)، اما اساساً بالا آمارهای برتر را نشان می دهد که در پنجره ترمینال قرار می گیرند. در این مورد بر اساس % CPU (% CPU) مرتب شده است. برای مشاهده تمام 100 فرآیند PHP-FPM، دستور را اجرا کنید:

top -bn1 | grep php-fpm

زمان استفاده از pm ondemand و پویا

اگر از 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

سعی کنید پارامتر را تغییر دهید، خطا از بین نمی رود، مانند در این پست در Serverfault توضیح داده شده است. در این مورد، مقدار 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