HestiaCP PHP-FPM-ը ծանր բեռի տակ է: Դինամիկ վեբ էջի 500 սխալ: Այս օպտիմալացումը ուժի մեջ կմտնի անմիջապես:

Դուք երբևէ բախվե՞լ եք այս իրավիճակին:Կայքի հասանելիությունը հանկարծակի դանդաղեց, կամ նույնիսկ հանգեցրեց 500 սխալի, PHP-FPM-ի վերագործարկումից հետո այն վերադարձավ նորմալ:, բայց որոշ ժամանակ անց խնդիրը նորից ի հայտ է գալիս։ Սա այնքան հիասթափեցնող է:

Ինչու է դա տեղի ունենումԻրականում, սա սովորաբարPHP-FPM գործընթացի լողավազանը ճիշտ կազմաձևված չէ, կամ սերվերի ռեսուրսները անբավարար են:պայմանավորված է. Այսօր մենք մանրակրկիտ օպտիմալացնելու ենք HestiaCP PHP-FPM-ը վեբկայքը դարձնում է քարի պես կայուն:

PHP-FPM-ի գերբեռնվածության հիմնական պատճառը

PHP-FPM-ը աԳործընթացի կառավարիչ, որը պատասխանատու է դինամիկ հարցումների մշակման համար: Եթե ​​կոնֆիգուրացիան ողջամիտ չէ, դա կարող է հանգեցնել.

• Սերվերի ռեսուրսները սպառված են, ինչը հանգեցնում է նրան, որ PHP-FPM-ը չի կարողանում ժամանակին պատասխանել նոր հարցումներին.
• Չափազանց քիչ գործընթացներ, երբ երթևեկությունը հանկարծակի մեծանում է, այն չի կարող ժամանակին մշակվել.
• Գործընթացի օգտագործումը չափազանց մեծ է, պատճառելով պրոցեսորի բեռնվածությունը պայթել:

Ինչպե՞ս պարզել, թե արդյոք PHP-FPM-ը գերբեռնված է:

կարող է օգտագործել top 或 htop CPU-ի և հիշողության օգտագործումը դիտելու հրաման.

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

Տեսնո՞ւմ եք, թե ինչպես են այս գործընթացները զբաղեցնում CPU-ի ավելի քան 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

Հարցում ուղարկել HestiaCP-ի կողմից սահմանված PHP տարբերակի վերաբերյալ

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

Ամեն օր առավոտյան ժամը 3-ին PHP-FPM-ը ավտոմատ կերպով վերագործարկելու համար ավելացրեք հետևյալ պլանավորված առաջադրանքը.

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 բեռը զգալիորեն կնվազի, և վեբկայքի աշխատանքը կլինի ավելի կայուն: 🔥

Գնա փորձիր հիմա: 💪🚀