Mae HestiaCP PHP-FPM o dan lwyth trwm? Gwall tudalen we deinamig 500? Bydd yr optimeiddio hwn yn dod i rym ar unwaith!

Ydych chi erioed wedi dod ar draws y sefyllfa hon?Arafodd mynediad gwefan yn sydyn, neu hyd yn oed arwain at wall 500 Ar ôl ailgychwyn PHP-FPM, dychwelodd i normal., ond mae'r broblem yn ailymddangos ar ôl ychydig? Mae hyn mor rhwystredig!

Pam mae hyn yn digwydd?Mewn gwirionedd, mae hyn fel arferNid yw cronfa prosesau PHP-FPM wedi'i ffurfweddu'n iawn, neu nid yw adnoddau'r gweinydd yn ddigonol.achosir gan. Heddiw, byddwn yn gwneud y gorau yn drylwyr HestiaCP Mae PHP-FPM o dan y cwfl yn gwneud y wefan mor sefydlog â chraig!

Y rheswm craidd pam mae PHP-FPM yn cael ei orlwytho

PHP-FPM ynRheolwr Proses, sy'n gyfrifol am drin ceisiadau deinamig. Os nad yw'r ffurfweddiad yn rhesymol, gall arwain at:

• Mae adnoddau gweinydd wedi dod i ben, gan achosi i PHP-FPM fethu ag ymateb i geisiadau newydd mewn modd amserol;
• Rhy ychydig o brosesau, pan fydd traffig yn cynyddu'n sydyn, ni ellir ei brosesu mewn pryd;
• Mae'r defnydd o brosesau yn rhy uchel, gan achosi i'r llwyth CPU ffrwydro.

Sut i ddweud a yw PHP-FPM wedi'i orlwytho?

yn gallu defnyddio top 或 htop Gorchymyn i weld CPU a defnydd cof:

top -c

Os gwelwch wybodaeth proses debyg i'r canlynol, mae'n golygu bod PHP-FPM yn rhedeg o dan lwyth uchel:

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

Gweld sut mae'r prosesau hyn yn cymryd dros 70% o'r CPU? Os bydd hyn yn digwydd yn aml, eich PHP-FPM Mae'n rhaid bod problem!

Felly, sut allwn ni optimeiddio'r cyfluniad PHP-FPM fel nad yw'r gweinydd yn cael ei orlwytho mwyach?

Optimeiddio cronfa broses PHP-FPM (addasiad paramedr craidd)

Yn gyntaf, agor php-fpm Ffeiliau Ffurfweddu:

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

• *Newidiwch i'ch fersiwn PHP, fel PHP8.3, a'i newid i hyn:/etc/php/8.3/fpm/pool.d/www.conf

Ymholi'r fersiwn PHP a osodwyd gan HestiaCP

v-list-web-domain user domain.com

E.g:

v-list-web-domain abc chenweiliang.com

Yn yr allbwn, fe welwch rywbeth fel:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.3

Mae hyn yn golygu bod y safle yn defnyddio PHP 8.3.

Beth am edrych ar eich ffurfweddiad 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

Gallwch weld bod eich pm Yr un a ddefnyddir yw ondemand,Er y gall leihau'r defnydd o adnoddau yn ystod amser segur, pan fydd traffig yn cynyddu'n sydyn, efallai na fydd y broses yn gallu ymateb mewn pryd., gan arwain at wall 500.

1. Addaswch baramedrau pwll proses PHP-FPM

Os yw'r cyfluniad yn defnyddio dynamicMae hwn yn ddull o gychwyn rhai prosesau gwaith ymlaen llaw a'u haddasu'n ddeinamig yn ôl cyfaint y ceisiadau, a all ymateb yn gyflymach pan fydd cyfaint y ceisiadau yn cynyddu'n sydyn.

Ar gyfer gwefannau sydd â swm penodol o draffig, argymhellir defnyddio pm = dynamicOherwydd y gall gynnal nifer penodol o brosesau segur ac osgoi 500 o wallau yn ystod cydamseredd uchel.

Argymhellir ei ddefnyddio dim ond pan fydd y gyfrol mynediad yn isel iawn a'r adnoddau cof yn brin. pm = ondemand I arbed adnoddau.

Awgrymir newid i ondemand, ac optimeiddio pm.max_children A pharamedrau eraill:

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 后自动退出

Pam ydych chi eisiau ei newid fel hyn?

• pm = dynamic: Dyrannu prosesau'n fwy hyblyg er mwyn osgoi aros am geisiadau a allai gael ei achosi gan ondemand;
• pm.max_children = 16: Atal 500 o wallau a achosir gan rhy ychydig o brosesau;
• pm.start_servers = 5: Osgoi cychwyn proses araf;
• pm.max_requests = 3000:Atal gollyngiadau cof, ailgylchu'r broses yn rheolaidd.

2. Cyfyngu ar amser gweithredu sgriptiau PHP i atal deiliadaeth hirdymor

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

Gall hyn atal rhaiGall sgriptiau PHP sy'n defnyddio gormod o CPU ddod â'ch gweinydd i lawr.

Ar ôl arbed, ailgychwynwch y broses PHP:

sudo systemctl restart php8.3-fpm

Galluogi monitro statws PHP-FPM i gadw golwg ar y cynnydd ar unrhyw adeg

Galluogi monitro proses PHP-FPM a'i weld ar unrhyw adegNifer presennol o brosesau gweithredol a cais am statws aros, er mwyn osgoi gorlwytho gweinydd.

在 php-fpm.conf Wedi'i ychwanegu yn:

pm.status_path = /status

Yna, cyfluniad 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;
}

Yn y modd hwn, gallwch chi http://yourdomain.com/status Edrychwch ar PHP-FPM ar waith!

Optimeiddio logiau PHP-FPM i ddatrys problemau yn gyflym

在 php-fpm.conf Ychwanegu at:

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 的脚本记录到日志

Yn y modd hwn, pryd bynnag y bydd gwall 500 yn digwydd, gallwch weld y log yn uniongyrchol:

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

Gweld a yw PHP yn adrodd am wall, megis out of memory,script execution timeout Arhoswch.

Ailgychwyn PHP-FPM yn rheolaidd i atal gollyngiadau cof

gallu pasio cron Ailgychwyn PHP-FPM yn rheolaidd i atal prosesau hirsefydlog rhag achosiGollyngiadau Cof.

crontab -e

Ychwanegwch y dasg a drefnwyd ganlynol i ailgychwyn PHP-FPM yn awtomatig am 3 am bob dydd:

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

Beth os bydd y broblem yn parhau? Optimeiddio pellach!

Os ydych chi'n dal i ddilyn yr optimeiddio uchodO bryd i'w gilydd bydd 500 o wallau'n digwydd, gallwch barhau gyda'r optimizations canlynol:

1. Galluogi OPcache i wella effeithlonrwydd gweithredu PHP

Os nad yw OPcache wedi'i alluogi eto, gallwch ei osod fel hyn (gan ddefnyddio Ubuntu fel enghraifft):

sudo apt install php8.3-opcache -y

Yna golygu php.ini:

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

Effaith? Mae cyflymder gweithredu tudalen PHP wedi'i wella'n fawr!

2. Optimization cyfluniad Nginx

Sicrhewch fod paramedrau cysylltiedig Nginx yn rhesymol, megis fastcgi_read_timeout Addaswch ef yn briodol er mwyn osgoi terfynu sgriptiau PHP gan Nginx oherwydd amser gweithredu hir:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Crynodeb: Optimeiddiwch PHP-FPM ac ni fydd y wefan yn chwalu mwyach!

Pa addasiadau ydyn ni wedi'u gwneud ar ôl yr optimeiddio hwn?

✅ Optimeiddio'r gronfa broses PHP-FPM, defnyddio ondemandAc optimeiddio pm.max_children paramedr;
✅ Cyfyngu ar amser gweithredu sgriptiau PHP, i atal galwedigaeth CPU hirdymor;
✅ Galluogi monitro PHP-FPM, gweld llwyth y broses mewn amser real;
✅ Optimeiddio logiau PHP-FPM, datrys problemau 500 o wallau yn gyflym;
✅ Ailgychwyn PHP-FPM yn rheolaidd, atal gollyngiadau cof;
✅ Galluogi OPcache, gwella effeithlonrwydd gweithredu PHP;
✅ Optimeiddio Ffurfweddiad Nginx, er mwyn osgoi problemau goramser.

Ar ôl yr optimeiddio hwn, bydd y llwyth PHP-FPM yn cael ei leihau'n fawr a bydd gweithrediad y wefan yn fwy sefydlog! 🔥

Ewch i roi cynnig arni nawr! 💪🚀