HestiaCP PHP-FPM ແມ່ນຢູ່ພາຍໃຕ້ການໂຫຼດຫນັກບໍ? ໜ້າເວັບແບບໄດນາມິກ 500 ຜິດພາດບໍ? ການເພີ່ມປະສິດທິພາບນີ້ຈະມີຜົນທັນທີ!

ເຄີຍພົບສະຖານະການນີ້ບໍ່? ເວັບໄຊທ໌ຂອງທ່ານຊ້າລົງຢ່າງກະທັນຫັນ, ຫຼືແມ່ນແຕ່ສະແດງຂໍ້ຜິດພາດ 500. ການເລີ່ມຕົ້ນ PHP-FPM ຄືນໃໝ່ຈະຊ່ວຍໃຫ້ມັນກັບຄືນສູ່ສະພາບປົກກະຕິ , ແຕ່ບັນຫາກໍ່ປາກົດຂຶ້ນອີກຫຼັງຈາກນັ້ນໄລຍະໜຶ່ງ? ມັນເປັນເລື່ອງທີ່ໜ້າອຸກໃຈຫຼາຍ!

ເປັນຫຍັງເລື່ອງນີ້ຈຶ່ງເກີດຂຶ້ນ? ຕົວຈິງແລ້ວ, ສິ່ງນີ້ມັກຈະ ເກີດຈາກ ການຕັ້ງຄ່າລະບົບ PHP-FPM ທີ່ບໍ່ຖືກຕ້ອງ ຫຼື ຊັບພະຍາກອນເຊີບເວີບໍ່ພຽງພໍ . ມື້ນີ້, ພວກເຮົາຈະປັບປຸງ PHP-FPM ຢ່າງລະອຽດ ພາຍໃຕ້ HestiaCP ເພື່ອຮັບປະກັນຄວາມໝັ້ນຄົງຂອງເວັບໄຊທ໌ຂອງທ່ານ!

ເຫດຜົນຫຼັກວ່າເປັນຫຍັງ PHP-FPM ແມ່ນ overloaded

PHP-FPM ເປັນ ຜູ້ຈັດການຂະບວນການ ຂອງ PHP , ຮັບຜິດຊອບໃນການຈັດການການຮ້ອງຂໍແບບໄດນາມິກ. ການຕັ້ງຄ່າທີ່ບໍ່ເໝາະສົມສາມາດນໍາໄປສູ່:

• ຊັບພະຍາກອນເຊີບເວີໝົດແລ້ວ, ເຮັດໃຫ້ PHP-FPM ບໍ່ສາມາດຕອບສະຫນອງຄໍາຮ້ອງຂໍໃຫມ່ໄດ້ທັນເວລາ;
• ຂະບວນການຫນ້ອຍເກີນໄປ, ເມື່ອການຈະລາຈອນເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ, ມັນບໍ່ສາມາດດໍາເນີນການໄດ້ທັນເວລາ;
• ການນໍາໃຊ້ຂະບວນການສູງເກີນໄປ, ເຮັດໃຫ້ການໂຫຼດ CPU ລະເບີດ.

ວິທີການບອກວ່າ PHP-FPM ແມ່ນ overloaded?

ສາມາດນໍາໃຊ້ 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.5 ແລະປ່ຽນເປັນອັນນີ້:/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.5 

ນີ້ຊີ້ບອກວ່າເວັບໄຊທ໌ໃຊ້ PHP 8.5.

ລອງເບິ່ງການຕັ້ງຄ່າ PHP-FPM ຂອງທ່ານ:

[chenweiliang.com]
listen = /run/php/php8.5-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.

www.conf: "ສະນຸກເກີຊັບພະຍາກອນສາກົນ" ທີ່ຕິດຕັ້ງມາພ້ອມໃນລະບົບ

ຫຼັງຈາກຕິດຕັ້ງ PHP-FPM ແລ້ວ, ລະບົບຈະໃຫ້ຂໍ້ມູນອັດຕະໂນມັດແກ່ທ່ານ... www.conf ເອກະສານ.
ຂອງມັນການຈັດຕໍາ ແໜ່ງມັນງ່າຍດາຍຫຼາຍ - ມັນເປັນພຽງກຸ່ມຂະບວນການເລີ່ມຕົ້ນທີ່ເຮັດວຽກຢູ່ນອກກ່ອງ, ໂດຍປົກກະຕິແລ້ວຈະຕິດກັບ... www-data ດາວໂຫຼດໂດຍຜູ້ໃຊ້.

ສະລອຍນ້ຳປະເພດນີ້ເໝາະສົມໂດຍສະເພາະສຳລັບສະພາບແວດລ້ອມສະຖານທີ່ດຽວ: ການຕັ້ງຄ່າມີນ້ຳໜັກເບົາ, ແລະພາລາມິເຕີທັງໝົດແມ່ນແມ່ແບບທົ່ວໄປ, ເຊັ່ນ:

user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm.max_children = 5

ຖ້າທ່ານໂຮດພຽງແຕ່ເວັບໄຊທ໌ດຽວ, ທ່ານສາມາດໃຊ້ມັນໄດ້ໂດຍກົງ ແລະ ໜ້າເຊື່ອຖືໂດຍບໍ່ມີບັນຫາເພີ່ມເຕີມ.

etufo.org.conf: ກຸ່ມຂໍ້ມູນແບບກຳນົດເອງ

ເມື່ອທ່ານກຳລັງໃຊ້ງານຫຼາຍເວັບໄຊທ໌, ທ່ານບໍ່ສາມາດເຮັດໃຫ້ທຸກຄົນອັດແໜ້ນຢູ່ໃນສະລອຍນ້ຳດຽວກັນໄດ້.
ໃນຈຸດນີ້, HestiaCP ຈະສ້າງ pool ແຍກຕ່າງຫາກໂດຍອັດຕະໂນມັດສຳລັບແຕ່ລະເວັບໄຊ, ຕົວຢ່າງ... etufo.org.confຊ່ຽວຊານສຳລັບຊື່ໂດເມນ etufo.org 。。

ວິທີການຫຼິ້ນທົ່ວໄປແມ່ນ:

• ປ່ຽນຜູ້ໃຊ້ ແລະ ກຸ່ມຕ່າງໆ:user = etufo,group = etufo
• ການຕິດຕາມກວດກາແບບອິດສະຫຼະ:listen = /run/php/etufo.sock
• ການປັບຈຳນວນຂອງຂະບວນການຮັບປະກັນຄວາມໝັ້ນຄົງທີ່ແຂງແກ່ນເຖິງແມ່ນວ່າຈະຢູ່ພາຍໃຕ້ການເຮັດວຽກພ້ອມກັນສູງກໍຕາມ.
• ໄຟລ໌ບັນທຶກແຍກຕ່າງຫາກເຮັດໃຫ້ການແກ້ໄຂບັນຫາຊັດເຈນຂຶ້ນ.

ຜົນປະໂຫຍດແມ່ນເຫັນໄດ້ຊັດເຈນ: ການແຍກແຍະທີ່ປອດໄພ . ເຖິງແມ່ນວ່າເວັບໄຊທ໌ໜຶ່ງຈະຖືກໂຈມຕີ, ແຕ່ເວັບໄຊທ໌ອື່ນໆກໍ່ຍັງບໍ່ໄດ້ຮັບຜົນກະທົບ.

dummy.conf: ໄຟລ໌ dummy

dummy.conf ໂດຍປົກກະຕິແລ້ວ ສິ່ງເຫຼົ່ານີ້ແມ່ນຕົວຢ່າງ ຫຼື ແມ່ແບບທີ່ລະບົບສະໜອງໃຫ້.
ມັນຈະບໍ່ເຮັດວຽກເວັ້ນເສຍແຕ່ວ່າທ່ານຈະດັດແປງ ແລະ ເປີດໃຊ້ມັນດ້ວຍຕົນເອງ.
ຄວາມສຳຄັນຂອງມັນຄ້າຍຄືກັບ "ຄູ່ມືການດຳເນີນງານ" ຫຼາຍກວ່າ, ເຊິ່ງບອກທ່ານກ່ຽວກັບວິທີການຂຽນການຕັ້ງຄ່າສະລອຍນ້ຳໃໝ່.

ເປັນຫຍັງຕ້ອງແບ່ງສະລອຍນ້ຳ?

• ຄວາມປອດໄພໃຊ້ຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນສຳລັບເວັບໄຊທີ່ແຕກຕ່າງກັນເພື່ອຫຼີກເວັ້ນການອະນຸຍາດທີ່ຂັດແຍ້ງກັນ.
• 性能优化ຈຳນວນຂະບວນການສາມາດປັບໄດ້ເປັນສ່ວນບຸກຄົນສຳລັບແຕ່ລະກຸ່ມ, ເຊິ່ງຊ່ວຍໃຫ້ສາມາດປັບໄດ້ຢ່າງຍືດຫຍຸ່ນໂດຍອີງໃສ່ຄວາມຕ້ອງການຂອງການຈະລາຈອນ.
• ​ການ​ແຍກ​ດ່ຽວບັນທຶກ, ຄວາມຜິດພາດ ແລະ ທີ່ຢູ່ການຮັບຟັງທັງໝົດແມ່ນແຍກອອກຈາກກັນ, ເຮັດໃຫ້ການແກ້ໄຂບັນຫາງ່າຍຂຶ້ນ.

ຕົວຢ່າງ, ເຖິງແມ່ນວ່າ www.conf ຈະຂັດຂ້ອງ, etufo.org.conf ຈະຍັງເຮັດວຽກຕາມປົກກະຕິ ແລະ ຈະບໍ່ເຮັດໃຫ້ເຊີບເວີທັງໝົດລົ້ມລົງ.

实际场景

• ເຊີບເວີເວັບໄຊທ໌ດຽວ: www.conf ແມ່ນພຽງພໍແລ້ວ.
• ເຊີບເວີຫຼາຍເວັບໄຊທ໌ແຕ່ລະເວັບໄຊມີໄຟລ໌ .conf ຂອງຕົນເອງ, ເຊັ່ນ etufo.org.conf.
• dummy.confສຳລັບອ້າງອີງເທົ່ານັ້ນ, ບໍ່ແນະນຳ.

ການປຽບທຽບການຕັ້ງຄ່າ

www.conf (ກຸ່ມເລີ່ມຕົ້ນ)

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 5

etufo.org.conf (ກຸ່ມທີ່ກຳນົດເອງ)

[etufo.org]
user = etufo
group = etufo
listen = /run/php/etufo.sock
pm = dynamic
pm.max_children = 20
access.log = /var/log/php-fpm/etufo.access.log

ຄວາມແຕກຕ່າງຕົ້ນຕໍແມ່ນ: ຕົວຕົນຂອງຜູ້ໃຊ້, ທີ່ຢູ່ການຟັງ ແລະ ຈຳນວນຂອງຂະບວນການ.

1. ປັບຕົວກໍານົດການສະນຸກເກີຂະບວນການ PHP-FPM

ຖ້າການຕັ້ງຄ່າໃຊ້ dynamicນີ້ແມ່ນວິທີການເລີ່ມຕົ້ນຂະບວນການເຮັດວຽກບາງຢ່າງແລະປັບຕົວແບບເຄື່ອນໄຫວຕາມປະລິມານການຮ້ອງຂໍ, ເຊິ່ງສາມາດຕອບສະຫນອງໄດ້ໄວຂຶ້ນເມື່ອປະລິມານການຮ້ອງຂໍເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ.

ສໍາລັບເວັບໄຊທ໌ທີ່ມີຈໍານວນການເຂົ້າຊົມທີ່ແນ່ນອນ, ແນະນໍາໃຫ້ໃຊ້ pm = dynamicເນື່ອງຈາກວ່າມັນສາມາດຮັກສາຈໍານວນທີ່ແນ່ນອນຂອງຂະບວນການ idle ແລະຫຼີກເວັ້ນການ 500 ຄວາມຜິດພາດໃນລະຫວ່າງການ concurrency ສູງ.

ມັນແນະນໍາໃຫ້ໃຊ້ມັນພຽງແຕ່ໃນເວລາທີ່ປະລິມານການເຂົ້າເຖິງຕ່ໍາສຸດແລະຊັບພະຍາກອນຫນ່ວຍຄວາມຈໍາແຫນ້ນ. pm = ondemand ເພື່ອຊ່ວຍປະຢັດຊັບພະຍາກອນ.

ແນະນໍາໃຫ້ປ່ຽນເປັນ dynamic, ແລະເພີ່ມປະສິດທິພາບ 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: ຈັດສັນຂະບວນການທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍຂື້ນເພື່ອຫຼີກເວັ້ນການຮ້ອງຂໍລໍຖ້າທີ່ອາດຈະເກີດຈາກ ondemand;
• pm.max_children = 16: ປ້ອງກັນ 500 ຄວາມຜິດພາດທີ່ເກີດຈາກຂະບວນການຫນ້ອຍເກີນໄປ;
• pm.start_servers = 5: ຫຼີກເວັ້ນການເລີ່ມຕົ້ນຂະບວນການຊ້າ;
• pm.max_requests = 3000ທ່ານ ອາຊື ກອນສິນ ນັກທຸລະກິດລາວປ້ອງກັນການຮົ່ວໄຫຼຂອງຄວາມຊົງຈໍາ, recycle ຂະບວນການເປັນປົກກະຕິ.

2. ຈໍາກັດເວລາປະຕິບັດຂອງ script PHP ເພື່ອປ້ອງກັນການຄອບຄອງໃນໄລຍະຍາວ

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

ສິ່ງນີ້ຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ ສະຄຣິບ PHP ບາງອັນທີ່ໃຊ້ CPU ຫຼາຍເກີນໄປເຮັດໃຫ້ເຊີບເວີຢຸດເຮັດວຽກ.

ຫຼັງຈາກບັນທຶກ, ເລີ່ມຕົ້ນຂະບວນການ PHP ຄືນໃໝ່:

sudo systemctl restart php8.3-fpm

ເພີ່ມປະສິດທິພາບ PHP-FPM ໂດຍອີງໃສ່ການຕັ້ງຄ່າ VPS

ຕົວຢ່າງການຕັ້ງຄ່າ VPS:

• ລາຍລະອຽດ: VPS 3 NVMe
• ພື້ນທີ່ດິດ: 300 GB
• ແກນ CPU: 8
• RAM: 24 GB

ອີງຕາມການຕັ້ງຄ່າ VPS ຂອງທ່ານ ( 8 CPU cores, 24 GB RAM ), ຊັບພະຍາກອນເຊີບເວີຂອງທ່ານແມ່ນພຽງພໍແລ້ວ. ສຳລັບ PHP-FPM, RAM 24 GB ຊ່ວຍໃຫ້ທ່ານສາມາດຕັ້ງຄ່າຂະບວນການພ້ອມໆກັນໄດ້ຫຼາຍ.

ໃນສະພາບແວດລ້ອມການຜະລິດ, ໂດຍປົກກະຕິແລ້ວພວກເຮົາຈັດສັນໜ່ວຍຄວາມຈຳພຽງພໍ (ເຊັ່ນ 8GB-12GB) ສຳລັບລະບົບເອງ, ຖານຂໍ້ມູນ Apache (ເຊັ່ນ MySQL /MariaDB), ແລະແຄດ (ເຊັ່ນ Redis / Memcached ), ເຮັດໃຫ້ ໜ່ວຍຄວາມຈຳທີ່ເຫຼືອ 12GB-16GB ຖືກຈັດສັນໃຫ້ PHP-FPM ຢ່າງເຕັມທີ່.

ອີງຕາມການໃຊ້ໜ່ວຍຄວາມຈຳສະເລ່ຍ 40MB-60MB ຕໍ່ຂະບວນການ PHP , ໜ່ວຍຄວາມຈຳ 1GB ສາມາດເຮັດວຽກໄດ້ປະມານ 16-25 ຂະບວນການ.

ຕໍ່ໄປນີ້ແມ່ນ ການຕັ້ງຄ່າ FPM ທີ່ມີປະສິດທິພາບສູງ ແລະ ມີປະສິດທິພາບສູງ ທີ່ອອກແບບມາສຳລັບທ່ານ , ເຊິ່ງສາມາດປັບປຸງ ຄວາມຈຸຂອງ WordPress ໄດ້ຢ່າງຫຼວງຫຼາຍ ແລະ ປ້ອງກັນບໍ່ໃຫ້ມັນຂັດຂ້ອງຍ້ອນການຈະລາຈອນທີ່ເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ:

pm = dynamic

; 允许的最大 PHP 进程数（12GB 内存 / 40MB ≈ 300）
; 8核CPU搭配300个进程，可以轻松应对极高并发，且不至于让内存溢出
pm.max_children = 300

; 启动时创建的初始进程数（CPU核心数 * 4）
pm.start_servers = 32

; 维持的最小空闲进程数（服务器空闲时保留的进程，保证随时响应）
pm.min_spare_servers = 16

; 维持的最大空闲进程数（超过这个数量的空闲进程会被释放）
pm.max_spare_servers = 64

; 每个进程处理1000个请求后自动重启，高配置服务器可适当调大，有效防止WP插件内存泄露
pm.max_requests = 1000

; 单个请求最大执行时间，超时60秒强杀，防止死锁卡死
request_terminate_timeout = 60s

; 慢日志路径及触发阈值（请求超过5秒则记录，用于排查性能瓶颈）
slowlog = /var/log/php8.5-fpm.log.slow
request_slowlog_timeout = 5s

💡 ເປັນຫຍັງຕ້ອງຕັ້ງຄ່ານີ້?

1. pm.max_children = 300ນີ້ແມ່ນການເພີ່ມປະສິດທິພາບຫຼັກ. ການຕັ້ງຄ່າກ່ອນໜ້ານີ້ຂອງທ່ານທີ່ມີ 50 ຂະບວນການນັ້ນມີຄວາມລະມັດລະວັງເກີນໄປສຳລັບໜ່ວຍຄວາມຈຳ 24GB. ເມື່ອພົບກັບການຈະລາຈອນທີ່ເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ (ຫຼື ບັອດທີ່ໄຫຼລົ້ນພື້ນຫຼັງ), 50 ຂະບວນການຈະຖືກຄອບງຳທັນທີ, ເຮັດໃຫ້ການເຊື່ອມຕໍ່ໝົດເວລາ. ການເພີ່ມມັນເປັນ 300 ສາມາດປັບປຸງຄວາມສາມາດໃນການປະມວນຜົນພ້ອມກັນຂອງເຊີບເວີຂອງທ່ານໄດ້ຫຼາຍເທົ່າ.
2. pm.start_servers / `ເຊີບເວີສຳຮອງໜ້ອຍໜຶ່ງເນື່ອງຈາກທ່ານມີ 8 CPU cores, ໃນເບື້ອງຕົ້ນ ແລະ ໂດຍປົກກະຕິແລ້ວທ່ານສາມາດຮັກສາຂະບວນການທີ່ບໍ່ໄດ້ໃຊ້ງານໄດ້ຫຼາຍຂຶ້ນ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດໃຊ້ປະໂຫຍດຈາກຂໍ້ໄດ້ປຽບຂອງຫຼາຍແກນ ເພື່ອໃຫ້ສາມາດເປີດການຮ້ອງຂໍໃໝ່ໄດ້ທັນທີໂດຍບໍ່ຕ້ອງລໍຖ້າການສ້າງຂະບວນການ.
3. pm.max_requests = 1000ເພີ່ມຈາກ 500 ເປັນ 1000. ໜ່ວຍຄວາມຈຳຂອງທ່ານມີຂະໜາດໃຫຍ່, ແລະ ບໍ່ຈຳເປັນຕ້ອງເລີ່ມຕົ້ນຂະບວນການໃໝ່ເລື້ອຍໆ. ການເພີ່ມເປັນ 1000 ສາມາດຫຼຸດຜ່ອນການໃຊ້ CPU ທີ່ເກີດຈາກການທຳລາຍ ແລະ ການສ້າງຂະບວນການເລື້ອຍໆ.

ເບິ່ງບັນທຶກຊ້າ:

tail -f /var/log/php8.5-fpm.log.slow
tail -f /var/log/php8.4-fpm.log.slow

ຫຼັງຈາກເຮັດການປ່ຽນແປງແລ້ວ, ຢ່າລືມເລີ່ມການບໍລິການ PHP-FPM ໃໝ່ເພື່ອໃຫ້ການປ່ຽນແປງມີຜົນ.

systemctl restart php8.5-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.5-fpm restart

ຈະເປັນແນວໃດຖ້າບັນຫາຍັງຄົງຢູ່? ການເພີ່ມປະສິດທິພາບເພີ່ມເຕີມ!

ຖ້າທ່ານຍັງ ພົບຂໍ້ຜິດພາດ 500 ເປັນບາງຄັ້ງຄາວ ຫຼັງຈາກປະຕິບັດຕາມການປັບປຸງຂ້າງເທິງແລ້ວ , ທ່ານສາມາດສືບຕໍ່ປັບປຸງຕໍ່ໄປນີ້ໄດ້:

1. ເປີດໃຊ້ OPcache ເພື່ອປັບປຸງປະສິດທິພາບການປະຕິບັດ PHP

ຖ້າ OPcache ຍັງບໍ່ໄດ້ເປີດໃຊ້, ທ່ານສາມາດຕິດຕັ້ງມັນແບບນີ້ໄດ້ (ໃຊ້ Ubuntu ເປັນຕົວຢ່າງ):

sudo apt install php8.5-opcache -y

ຈາກນັ້ນແກ້ໄຂ php.iniທ່ານ ອາຊື ກອນສິນ ນັກທຸລະກິດລາວ

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

• opcache.validate_timestamps=0
• ປິດການກວດສອບເວລາຈິງຫຼຸດຜ່ອນ I/O ຂອງລະບົບໄຟລ໌ ແລະ ປັບປຸງປະສິດທິພາບ.

• ເຖິງຢ່າງໃດກໍ່ຕາມ, ນີ້ໝາຍຄວາມວ່າທ່ານຕ້ອງລຶບແຄດດ້ວຍຕົນເອງ (ເລີ່ມການບໍລິການ PHP ຄືນໃໝ່) ຫຼັງຈາກດັດແປງໄຟລ໌ PHP.

ຫຼັງຈາກດັດແປງການຕັ້ງຄ່າແລ້ວ, ທ່ານຕ້ອງເລີ່ມການບໍລິການ PHP ໃໝ່ເພື່ອໃຫ້ການປ່ຽນແປງມີຜົນ.

sudo systemctl restart php<版本>-fpm

ຜົນກະທົບ? ຄວາມໄວການປະຕິບັດຫນ້າ PHP ໄດ້ຮັບການປັບປຸງຢ່າງຫຼວງຫຼາຍ!

2. ການປັບແຕ່ງການຕັ້ງຄ່າ Nginx

ໃຫ້ແນ່ໃຈວ່າຕົວກໍານົດການທີ່ກ່ຽວຂ້ອງ Nginx ແມ່ນສົມເຫດສົມຜົນ, ເຊັ່ນ: fastcgi_read_timeout ປັບມັນໃຫ້ເໝາະສົມເພື່ອຫຼີກລ່ຽງສະຄຣິບ PHP ຖືກຢຸດໂດຍ Nginx ເນື່ອງຈາກເວລາປະຕິບັດຍາວ:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

ສະຫຼຸບ: ເພີ່ມປະສິດທິພາບ PHP-FPM ແລະເວັບໄຊທ໌ຈະບໍ່ crash ອີກຕໍ່ໄປ!

ພວກເຮົາມີການປັບຕົວຫຍັງແດ່ຫຼັງຈາກການເພີ່ມປະສິດທິພາບນີ້?

✅ ການເພີ່ມປະສິດທິພາບຂອງຂະບວນການ PHP-FPM, ໃຊ້ ondemandແລະເພີ່ມປະສິດທິພາບ pm.max_children ພາລາມິເຕີ;
✅ ການຈໍາກັດເວລາປະຕິບັດຂອງ script PHP, ເພື່ອປ້ອງກັນການຍຶດຄອງ CPU ໃນໄລຍະຍາວ;
✅ ເປີດໃຊ້ການກວດສອບ PHP-FPM, ເບິ່ງການໂຫຼດຂະບວນການໃນເວລາທີ່ແທ້ຈິງ;
✅ ການເພີ່ມປະສິດທິພາບບັນທຶກ PHP-FPM, ຢ່າງວ່ອງໄວແກ້ໄຂບັນຫາ 500 ຄວາມຜິດພາດ;
✅ ຣີສະຕາດ PHP-FPM ເປັນປະຈຳ, ປ້ອງກັນການຮົ່ວໄຫລຂອງຫນ່ວຍຄວາມຈໍາ;
✅ ເປີດໃຊ້ OPcache, ປັບປຸງປະສິດທິພາບການປະຕິບັດ PHP;
✅ ການປັບແຕ່ງການຕັ້ງຄ່າ Nginx, ເພື່ອຫຼີກເວັ້ນບັນຫາການຫມົດເວລາ.

ຫຼັງຈາກການເພີ່ມປະສິດທິພາບນີ້, ການໂຫຼດ PHP-FPM ຈະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍແລະການດໍາເນີນງານເວັບໄຊທ໌ຈະມີຄວາມຫມັ້ນຄົງຫຼາຍ! 🔥

ໄປລອງມັນດຽວນີ້! 💪🚀

ຖ້າທ່ານຍັງຢາກຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບການປັບແຕ່ງແມ່ແບບ PHP-FPM ດ້ວຍ HestiaCP, ບົດຄວາມນີ້ຈະເຮັດໃຫ້ທ່ານມີຄວາມເຂົ້າໃຈທີ່ເລິກເຊິ່ງກວ່າ:

👉 ແມ່ແບບ PHP-FPM ແບບກຳນົດເອງຂອງ HestiaCP: ເຄັດລັບການເພີ່ມປະສິດທິພາບຂອງ PHP 8.5 ▼

🔗ແມ່ແບບ PHP-FPM ແບບກຳນົດເອງຂອງ HestiaCP: ຄວາມລັບກ່ຽວກັບການເພີ່ມປະສິດທິພາບຂອງ PHP 8.5

ໃນເນື້ອຫານີ້, ທ່ານຈະເຫັນ:

• ເຕັກນິກການເພີ່ມປະສິດທິພາບການເຮັດວຽກພ້ອມກັນສູງ: ວິທີການປັບປຸງຄວາມໄວໃນການຕອບສະໜອງຜ່ານການຕັ້ງຄ່າຂະບວນການທີ່ສົມເຫດສົມຜົນ.
• ວິທີແກ້ໄຂການແຍກຄວາມປອດໄພ: ຫຼີກລ່ຽງຄວາມສ່ຽງໃນການເຂົ້າເຖິງຂ້າມເວັບໄຊ ແລະ ຮັບປະກັນຄວາມໝັ້ນຄົງຂອງບັນຊີ.
• ບັນທຶກ ແລະ ການຕິດຕາມກວດກາ: ໃຊ້ບັນທຶກທີ່ຊ້າເພື່ອຊອກຫາຈຸດຄໍຂວດ ແລະ ເພີ່ມປະສິດທິພາບຂອງເວັບໄຊທ໌ຢ່າງຕໍ່ເນື່ອງ.