HestiaCP PHP-FPM е под тежок товар? Грешка во динамичната веб-страница 500? Оваа оптимизација ќе стапи на сила веднаш!

Дали некогаш сте се сретнале со оваа ситуација?Пристапот до веб-локацијата одеднаш се забави, па дури и резултираше со грешка од 500 По рестартирањето на PHP-FPM, тој се врати во нормала., но проблемот повторно се појавува по некое време? Ова е толку фрустрирачки!

Зошто се случува ова?Всушност, ова е обичноПроцесот на PHP-FPM не е правилно конфигуриран или ресурсите на серверот се недоволни.предизвикани од. Денеска темелно ќе се оптимизираме HestiaCP PHP-FPM под капакот ја прави веб-страницата стабилна како камен!

Основната причина зошто PHP-FPM е преоптоварен

PHP-FPM е aПроцес менаџер, кој е одговорен за справување со динамички барања. Ако конфигурацијата не е разумна, може да доведе до:

• Ресурсите на серверот се исцрпени, што предизвикува PHP-FPM да не може навремено да одговори на новите барања;
• Премалку процеси, кога сообраќајот ненадејно се зголемува, тој не може да се обработи на време;
• Употребата на процесот е превисока, што предизвикува оптоварување на процесорот да експлодира.

Како да препознаете дали PHP-FPM е преоптоварен?

може да користи top Или htop Команда за прегледување на користењето на процесорот и меморијата:

top -c

Ако видите информации за процесот слични на следново, тоа значи дека PHP-FPM работи под големо оптоварување:

1669293 abc     20   0  790284 227880 185568 R  73.1   0.9   1:30.09 php-fpm: pool chenweiliang.com                                                    
1669522 abc     20   0  801924 224224 170236 R  69.9   0.9   0:59.01 php-fpm: pool chenweiliang.com

Погледнете како овие процеси зафаќаат над 70% од процесорот? Ако ова се случува често, вашиот PHP-FPM Мора да има проблем!

Значи, како можеме да ја оптимизираме конфигурацијата PHP-FPM, така што серверот повеќе не е преоптоварен?

PHP-FPM оптимизација на базен на процеси (приспособување на основни параметри)

Прво, отворете php-fpm Конфигурациски датотеки:

sudo nano /etc/php/*/fpm/pool.d/www.conf

• *Променете ја вашата PHP верзија, како на пример PHP8.3, и променете ја на ова:/etc/php/8.3/fpm/pool.d/www.conf

Побарајте ја PHP верзијата поставена од HestiaCP

v-list-web-domain user domain.com

На пример:

v-list-web-domain abc chenweiliang.com

На излезот, ќе видите нешто како:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.3

Ова значи дека страницата користи PHP 8.3.

Ајде да погледнеме во вашата PHP-FPM конфигурација:

[chenweiliang.com]
listen = /run/php/php8.3-fpm-chenweiliang.com.sock
listen.owner = abc
listen.group = www-data
listen.mode = 0660

user = abc
group = abc

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s

Можете да видите дека вашата pm Оној што се користи е ondemand,Иако може да ја намали употребата на ресурси за време на мирување, кога сообраќајот ненадејно се зголемува, процесот можеби нема да може да реагира навреме., што резултира со грешка од 500.

1. Прилагодете ги параметрите на процесниот базен на PHP-FPM

Ако конфигурацијата користи dynamicОва е метод за претходно стартување на некои работни процеси и нивно динамичко прилагодување според обемот на барања, што може да одговори побрзо кога обемот на барања одеднаш се зголемува.

За веб-страници со одреден обем на сообраќај, се препорачува да се користи pm = dynamicБидејќи може да одржува одреден број на неактивни процеси и да избегне 500 грешки за време на висока истовременост.

Се препорачува да се користи само кога волуменот на пристап е екстремно низок, а ресурсите на меморијата се ограничени. pm = ondemand За да заштедите ресурси.

Се предлага да се смени во ondemandи оптимизирајте pm.max_children И други параметри:

pm = dynamic
pm.max_children = 16  ; 根据服务器资源调整，建议值：CPU 核心数 × 2
pm.start_servers = 4   ; 初始进程数，建议设为 max_children × 25%
pm.min_spare_servers = 2  ; 最小空闲进程数
pm.max_spare_servers = 7  ; 最大空闲进程数
pm.max_requests = 3000    ; 每个子进程处理完 3000 个请求后自动重启
pm.process_idle_timeout = 10s  ; 空闲进程 10s 后自动退出

Зошто сакаш да го промениш вака?

• pm = dynamic: Распоредете ги процесите пофлексибилно за да избегнете чекање за барање што може да биде предизвикано од нарачка;
• pm.max_children = 16: Спречете 500 грешки предизвикани од премалку процеси;
• pm.start_servers = 5: Избегнувајте бавно стартување на процесот;
• pm.max_requests = 3000:Спречување на протекување на меморијата, редовно рециклирајте го процесот.

2. Ограничете го времето на извршување на PHP скриптите за да спречите долгорочно зафаќање

request_terminate_timeout = 30s  ; 超过 30s 的 PHP 脚本自动终止
php_admin_value[memory_limit] = 128M  ; 限制 PHP 进程最大内存占用

Ова може да спречи некоиPHP скриптите кои користат премногу процесор може да го урнат вашиот сервер.

По зачувувањето, рестартирајте го процесот на PHP:

sudo systemctl restart php8.3-fpm

Овозможете следење на статусот на PHP-FPM за да го следите напредокот во секое време

Овозможете следење на процесот на PHP-FPM и прегледајте го во секое времеТековен број на активни процеси и статус на барање на чекање, за да се избегне преоптоварување на серверот.

在 php-fpm.conf Додадено во:

pm.status_path = /status

Потоа, конфигурација на Nginx:

location /status {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

На овој начин можете http://yourdomain.com/status Проверете го PHP-FPM во акција!

Оптимизирајте ги дневниците на PHP-FPM за брзо решавање проблеми

在 php-fpm.conf Додај во:

php_admin_value[error_log] = /var/log/php-fpm/error.log
php_admin_value[log_errors] = On
php_admin_value[error_reporting] = E_ALL
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s  ; 执行超过 5s 的脚本记录到日志

На овој начин, секогаш кога ќе се појави грешка 500, можете директно да го прегледате дневникот:

tail -f /var/log/php-fpm/error.log

Погледнете дали PHP известува за грешка, како на пр out of memory,script execution timeout 。

Рестартирајте го PHP-FPM редовно за да спречите протекување на меморијата

способен да помине cron Рестартирајте го PHP-FPM редовно за да спречите да предизвикаат долготрајни процесиПротекување на меморијата.

crontab -e

Додајте ја следнава закажана задача за автоматско рестартирање на PHP-FPM во 3 часот наутро секој ден:

0 3 * * * /usr/sbin/service php8.3-fpm restart

Што ако проблемот продолжи? Понатамошна оптимизација!

Ако сè уште ја следите горната оптимизацијаПовремено се појавуваат 500 грешки, можете да продолжите со следните оптимизации:

1. Овозможете OPcache за да ја подобрите ефикасноста на извршувањето на PHP

Ако OPcache сè уште не е овозможена, можете да ја инсталирате вака (користејќи го Ubuntu како пример):

sudo apt install php8.3-opcache -y

Потоа уреди php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.validate_timestamps=1

Ефект? Брзината на извршување на PHP страницата е значително подобрена!

2. Оптимизација на конфигурацијата Nginx

Осигурајте се дека параметрите поврзани со Nginx се разумни, како на пр fastcgi_read_timeout Прилагодете го соодветно за да избегнете прекинување на PHP скриптите од Nginx поради долго време на извршување:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Резиме: оптимизирајте го PHP-FPM и веб-страницата повеќе нема да се урива!

Какви прилагодувања направивме по оваа оптимизација?

✅ Оптимизирање на базенот на процеси PHP-FPM, користете ondemandИ оптимизирај pm.max_children параметар;
✅ Ограничување на времето на извршување на PHP скриптите, за да се спречи долгорочно окупирање на процесорот;
✅ Овозможи следење PHP-FPM, погледнете го оптоварувањето на процесот во реално време;
✅ Оптимизирање на PHP-FPM дневници, брзо решавајте 500 грешки;
✅ Рестартирајте го PHP-FPM редовно, спречи протекување на меморијата;
✅ Овозможи OPcache, подобрување на ефикасноста на извршувањето на PHP;
✅ Оптимизирање на конфигурацијата на Nginx, за да се избегнат проблеми со тајмаутот.

По оваа оптимизација, оптоварувањето на PHP-FPM ќе биде значително намалено и работата на веб-страницата ќе биде постабилна! 🔥

Оди пробај сега! 💪🚀