دليل المادة
يعتمد عدد المستخدمين المتزامنين الذين يمكن للخادم التعامل معهم ليس على عدد النوى التي يمتلكها، ولكن على مقدار الذاكرة التي تستهلكها كل عملية.
قد يبدو هذا البيان بمثابة استفزاز، ولكنه التجربة الأكثر واقعية وإيلاماً في صناعة التشغيل والصيانة.
لماذا تُعتبر الذاكرة هي العائق الرئيسي؟
يرى الكثير من الناس خادمًا افتراضيًا خاصًا (VPS) مزودًا بمعالج ثماني النواة وذاكرة سعتها 24 جيجابايت ويعتقدون لا شعوريًا أنه يمكنهم بسهولة تشغيل مئات من عمليات PHP-FPM.
ومع ذلك، في الواقع، غالبًا ما يصل استخدام الذاكرة RSS لعملية PHP واحدة إلى 200 ميجابايت.
هذه هي النتيجة التي تم الحصول عليها من خلال الاختبار الفعلي عبر سطر الأوامر:
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 | إجمالي الذاكرة 24 جيجابايت باستثناء نواة النظام و MySQL/رديسبعد Nginx، يتبقى حوالي 16 جيجابايت لـ PHP.16,384 MB / 200 MB ≈ 81.9ضبطه على 80 يمكن أن يقضي تمامًا على مشكلة نفاد الذاكرة (OOM) أثناء التزامن العالي. |
| pm.start_servers | 16 | تم ضبط التسخين المسبق عند بدء التشغيل على ضعف عدد أنوية وحدة المعالجة المركزية (8 أنوية × 2 = 16) لضمان قدرة الخدمة على التعامل مع التزامن الأساسي على الفور بعد إعادة التشغيل. |
| pm.min_spare_servers | 8 | قم بتعيين عدد أنوية وحدة المعالجة المركزية إلى 8 أنوية لضمان إمكانية الاستجابة للطلبات الجديدة في أي وقت خلال فترات انخفاض حركة المرور. |
| pm.max_spare_servers | 24 | قم بتعيينه إلى 3 أضعاف عدد أنوية وحدة المعالجة المركزية (8 أنوية × 3 = 24) للاحتفاظ بعدد معتدل من العمليات بعد انحسار حركة المرور، وذلك للتعامل مع التقلبات الطفيفة. |
| pm.max_requests | 500 | إذا وصلت عملية واحدة إلى قاعدة كبيرة تبلغ 200 ميجابايت، فإن تقليل عدد الطلبات إلى 500 قبل التدمير وإعادة البناء يمكن أن ينظف تسريبات الذاكرة الضمنية بشكل أسرع. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers يتم تحرير العمليات الخاملة تلقائيًا وإعادتها إلى ذاكرة النظام بعد 10 ثوانٍ من عدم وجود طلبات. |
إعدادات الدعم الأساسية واقتراحات التحسين
1. آلية منع آثار الإفراط في تناول الكحول
request_terminate_timeout = 60s هذا هو المفتاح.
يمكنه إنهاء العمليات العالقة بسبب تعطل قاعدة البيانات أو حظر واجهة برمجة التطبيقات التابعة لجهات خارجية بشكل قسري.
في هذه الأثناء، Nginx fastcgi_read_timeout يجب الاحتفاظ بها لمدة 60 ثانية على الأقل، وإلا سيستلمها العميل قبل الأوان. 504 Gateway Timeout.
2. استراتيجيات للتغلب على اختناقات الذاكرة
يعني الحد الأقصى لعدد العمليات المتزامنة البالغ 80 عملية أنه في ظل ظروف التزامن القصوى، يمكن للنظام التعامل مع 80 طلب HTTP ديناميكي كحد أقصى في وقت واحد.
إذا كنت ترغب في تحسين السعة بشكل أكبر، فيجب أن ينصب التركيز على تقليل استخدام الذاكرة لكل عملية.
- تمكين OPcache:يخرج
php.iniتكوين متوسطopcache.enable=1及opcache.memory_consumption=256يمكن أن يؤدي التخزين المؤقت لرمز البايت إلى تقليل استخدام الذاكرة لعملية واحدة من 200 ميجابايت إلى 60 إلى 100 ميجابايت. - تحكم معقول في حد الذاكرة: 将
php.ini中 的memory_limitيقتصر على128M或256Mلمنع ظهور النصوص البرمجية الفردية غير الطبيعية无限يستهلك الكثير من الذاكرة.
بمجرد أن ينخفض استخدام الذاكرة لعملية واحدة إلى 100 ميجابايت...pm.max_children يمكن ترقيته بأمان إلى 150 بالإضافة إلى ذلك، تضاعفت قدرة التزامن تقريبًا.
تم الاستشهاد بوجهات نظر موثوقة
وفقًا للتوصيات الواردة في وثائق Nginx الرسمية :
"يجب دائمًا مراقبة تطبيقات FastCGI باستخدام توجيهات مهلة زمنية لمنع استنفاد الموارد."
(المصدر: وثائق Nginx)
ينص دليل PHP الرسمي بوضوح على ما يلي:
"يحدد pm.max_children الحد الأقصى لعدد العمليات الفرعية التي سيتم إنشاؤها. هذا هو التوجيه الأكثر أهمية."
(المصدر: وثائق PHP-FPM)
تتوافق هذه الآراء الموثوقة تمامًا مع ممارساتنا، مما يثبت أن منطق التحسين لا يعتمد فقط على الخبرة، ولكن أيضًا على أفضل الممارسات الموحدة.
الخلاصة: وجهات نظري والاقتباسات الرئيسية
في سيناريوهات التزامن العالي، تكون وحدة المعالجة المركزية هي المحرك، والذاكرة هي خزان الوقود، وPHP-FPM هو موزع الأسطول.
مهما كانت قوة المحرك، إذا لم يكن خزان الوقود كبيرًا بما يكفي، فلن تقطع القافلة مسافة طويلة.
الخبراء الحقيقيون لا يقومون بزيادة المعلمات بشكل أعمى، بل يقومون بحساب استخدام الذاكرة لكل عملية بدقة لتجنب كل من الهدر والتجاوز.
جوهر التحسين هو إيجاد التوازن الأمثل مع الموارد المحدودة.
هذه ليست مجرد تقنية، بل هي فلسفة أيضاً.
لذلك، توقف عن الاعتقاد بأن "عدد النوى يحدد كل شيء". ما يحدد حقًا حد التزامن هو تحكمك في الذاكرة.
اتخذ إجراءً وقم بتحسين خادمك الافتراضي الخاص إلى أقصى إمكاناته، مستفيدًا إلى أقصى حد من كل قطرة من الذاكرة.
نأمل أن تكون المقالة "8-core 24GB VPS running out of memory? Extreme tuned of PHP-FPM process pool under HestiaCP" المنشورة على مدونة Chen Weiliang ( https://www.chenweiliang.com/ ) مفيدة لك.
لا تتردد في مشاركة رابط هذه المقالة: https://www.chenweiliang.com/cwl-34509.html