فهرست مقاله
تعداد کاربران همزمانی که یک سرور میتواند مدیریت کند، به تعداد هستههای آن بستگی ندارد، بلکه به میزان حافظهای که هر فرآیند مصرف میکند بستگی دارد.
این جمله ممکن است تحریکآمیز به نظر برسد، اما واقعیترین و دردناکترین تجربه در صنعت عملیات و نگهداری است.
چرا حافظه گلوگاه اصلی است؟
بسیاری از افراد با دیدن یک VPS با پردازنده ۸ هسته ای و ۲۴ گیگابایت حافظه، ناخودآگاه فکر می کنند که می توانند به راحتی صدها فرآیند PHP-FPM را اجرا کنند.
با این حال، در واقعیت، میزان استفاده از حافظه RSS توسط یک فرآیند PHP اغلب به ۲۰۰ مگابایت میرسد.
این نتیجهای است که از طریق آزمایش واقعی از طریق خط فرمان به دست آمده است:
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
در چارچوب پیچیده و محیط چند افزونهای HestiaCP، به خصوص بدون بهینهسازی OPcache، 200 مگابایت مقدار معمول است.
این یعنی حافظه، نه پردازنده، حد نهایی است که حداکثر همزمانی را تعیین میکند.
فایل پیکربندی پیشنهادی (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
منطق محاسبه پارامتر و مبنای تنظیم
| پارامترهای پیکربندی | تنظیم مقدار | محاسبه و مبنای تنظیم هسته |
|---|---|---|
| pm | dynamic | حالت پویا امکان اضافه یا حذف انعطافپذیر فرآیندها را بر اساس الزامات همزمانی، با ایجاد تعادل بین سرعت پاسخ و استفاده از حافظه، فراهم میکند. |
| pm.max_children | 80 | ۲۴ گیگابایت حافظه کل منهای هسته سیستم و خروجی/Redisبعد از Nginx، تقریباً ۱۶ گیگابایت برای PHP باقی میماند.16,384 MB / 200 MB ≈ 81.9تنظیم آن روی ۸۰ میتواند OOM (Out of Memory) را در حین همزمانی بالا به طور کامل از بین ببرد. |
| pm.start_servers | 16 | پیش گرمایش در هنگام راه اندازی روی دو برابر تعداد هسته های CPU (8 هسته × 2 = 16) تنظیم شده است تا اطمینان حاصل شود که سرویس می تواند بلافاصله پس از راه اندازی مجدد، همزمانی اولیه را مدیریت کند. |
| pm.min_spare_servers | 8 | تعداد هستههای CPU را روی ۸ هسته تنظیم کنید تا اطمینان حاصل شود که در دورههای کم ترافیک، میتوان به درخواستهای جدید در هر زمانی پاسخ داد. |
| pm.max_spare_servers | 24 | آن را روی ۳ برابر تعداد هستههای CPU (۸ هسته × ۳ = ۲۴) تنظیم کنید تا تعداد متوسطی از فرآیندها پس از کاهش ترافیک حفظ شوند و نوسانات ملایم را مدیریت کنند. |
| pm.max_requests | 500 | اگر یک فرآیند واحد به حجم پایه بزرگ ۲۰۰ مگابایت برسد، کاهش تعداد درخواستها به ۵۰۰، فرآیند را از بین میبرد و دوباره میسازد، که میتواند نشت حافظه ضمنی را سریعتر پاک کند. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers فرآیندهای بیکار پس از 10 ثانیه عدم درخواست، به طور خودکار آزاد شده و به حافظه سیستم بازگردانده میشوند. |
تنظیمات پشتیبانی ضروری و پیشنهادات بهینهسازی
۱. مکانیسم ضد خماری تایم اوت
request_terminate_timeout = 60s کلید ماجرا همین است.
میتواند فرآیندهایی را که به دلیل بنبست پایگاه داده یا مسدود شدن API شخص ثالث گیر کردهاند، به زور خاتمه دهد.
در همین حال، Nginx fastcgi_read_timeout باید حداقل 60 ثانیه نگه داشته شود، در غیر این صورت مشتری آن را زودتر از موعد دریافت خواهد کرد. 504 Gateway Timeout.
۲. راهکارهایی برای غلبه بر تنگناهای حافظه
حداکثر ۸۰ فرآیند همزمان به این معنی است که در شرایط همزمانی شدید، سیستم میتواند حداکثر ۸۰ درخواست HTTP پویا را به طور همزمان مدیریت کند.
اگر میخواهید ظرفیت را بیشتر بهبود دهید، تمرکز باید روی کاهش میزان استفاده از حافظه به ازای هر فرآیند باشد.
- OPcache را فعال کنید: در حال حاضر
php.iniپیکربندی متوسطopcache.enable=1及opcache.memory_consumption=256ذخیره سازی بایت کد میتواند میزان استفاده از حافظه توسط یک فرآیند واحد را از ۲۰۰ مگابایت به ۶۰ تا ۱۰۰ مگابایت کاهش دهد. - کنترل معقول محدودیت حافظه：
php.iniوسطmemory_limitمحدود به128Mیا256Mبرای جلوگیری از اسکریپتهای غیرعادی فردینامحدودحافظه زیادی مصرف میکند.
زمانی که میزان استفاده از حافظه توسط یک فرآیند به ۱۰۰ مگابایت کاهش یابد...pm.max_children میتوان آن را با خیال راحت ارتقا داد 150 علاوه بر این، قابلیت همزمانی تقریباً دو برابر شده است.
دیدگاههای معتبر ذکر شده
طبق توصیههای موجود در مستندات رسمی Nginx :
«برنامههای FastCGI باید همیشه با دستورالعملهای timeout تحت نظارت باشند تا از اتمام منابع جلوگیری شود.»
(منبع: اسناد Nginx)
راهنمای رسمی PHP به وضوح بیان میکند:
"pm.max_children حداکثر تعداد فرآیندهای فرزندی که باید ایجاد شوند را تعریف میکند. این مهمترین دستورالعمل است."
(منبع: مستندات PHP-FPM)
این دیدگاههای معتبر کاملاً با شیوههای ما همسو هستند و ثابت میکنند که منطق بهینهسازی نه تنها مبتنی بر تجربه، بلکه مبتنی بر بهترین شیوههای استاندارد نیز میباشد.
نتیجهگیری: دیدگاهها و نقل قولهای کلیدی من
در سناریوهای با همزمانی بالا، CPU نقش موتور، حافظه نقش مخزن سوخت و PHP-FPM نقش توزیعکننده ناوگان را ایفا میکند.
مهم نیست موتور چقدر قدرتمند باشد، اگر مخزن سوخت به اندازه کافی بزرگ نباشد، کاروان مسافت زیادی را طی نخواهد کرد.
متخصصان واقعی کورکورانه پارامترها را به حداکثر نمیرسانند، بلکه میزان استفاده از حافظه توسط هر فرآیند را به طور دقیق محاسبه میکنند تا از هدر رفتن و سرریز جلوگیری شود.
اساس بهینهسازی، یافتن تعادل بهینه با منابع محدود است.
این فقط یک فناوری نیست، بلکه یک فلسفه نیز هست.
بنابراین، از این باور که «تعداد هستهها همه چیز را تعیین میکند» دست بردارید. آنچه واقعاً محدودیت همزمانی را تعیین میکند، کنترل شما بر حافظه است.
اقدام کنید و VPS خود را با تمام توان بهینه کنید و از هر قطره حافظه نهایت استفاده را ببرید.
امیدوارم مقاله «حافظه VPS هشت هستهای ۲۴ گیگابایتی رو به اتمام است؟ تنظیم شدید استخر پردازش PHP-FPM تحت HestiaCP» که در وبلاگ چن ویلیانگ ( https://www.chenweiliang.com/ ) به اشتراک گذاشته شده است، برای شما مفید باشد.
لینک این مقاله را به اشتراک بگذارید: https://www.chenweiliang.com/cwl-34509.html