HestiaCP PHP-FPM அதிக சுமையில் உள்ளதா? டைனமிக் வலைப்பக்கம் 500 பிழையா? இந்த மேம்படுத்தல் உடனடியாக அமலுக்கு வரும்!

நீங்கள் எப்போதாவது இந்த சூழ்நிலையை சந்தித்திருக்கிறீர்களா?வலைத்தள அணுகல் திடீரென மெதுவாகிவிட்டது, அல்லது 500 பிழையை ஏற்படுத்தியது. PHP-FPM ஐ மறுதொடக்கம் செய்த பிறகு, அது இயல்பு நிலைக்குத் திரும்பியது., ஆனால் சிறிது நேரத்திற்குப் பிறகு பிரச்சனை மீண்டும் தோன்றுகிறதா? இது ரொம்ப வெறுப்பூட்டுது!

இது ஏன் நடக்கிறது?உண்மையில், இது வழக்கமாகPHP-FPM செயல்முறை தொகுப்பு சரியாக உள்ளமைக்கப்படவில்லை, அல்லது சேவையக வளங்கள் போதுமானதாக இல்லை.காரணமாக ஏற்படுகிறது. இன்று, நாம் முழுமையாக மேம்படுத்துவோம் ஹெஸ்டியாசிபி நிறுவப்பட்ட PHP-FPM வலைத்தளத்தை ஒரு பாறை போல நிலையானதாக ஆக்குகிறது!

PHP-FPM ஓவர்லோடாக இருப்பதற்கான முக்கிய காரணம்

PHP-FPM என்பது ஒருசெயல்முறை மேலாளர், இது மாறும் கோரிக்கைகளை கையாளுவதற்கு பொறுப்பாகும். உள்ளமைவு நியாயமானதாக இல்லாவிட்டால், அது இதற்கு வழிவகுக்கும்:

• சேவையக வளங்கள் தீர்ந்துவிட்டன., இதனால் PHP-FPM புதிய கோரிக்கைகளுக்கு சரியான நேரத்தில் பதிலளிக்க முடியாமல் போகிறது;
• மிகக் குறைவான செயல்முறைகள், போக்குவரத்து திடீரென அதிகரிக்கும் போது, ​​அதை சரியான நேரத்தில் செயல்படுத்த முடியாது;
• செயல்முறை பயன்பாடு மிக அதிகமாக உள்ளது., இதனால் CPU சுமை வெடிக்கும்.

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 பிழை ஏற்படுகிறது.

www. conf：系统自带的“万能池”

安装好 PHP-FPM 后，系统会自动丢给你一个 www. conf கோப்பு.
அதன்நிலைப்படுத்தல்很简单——就是一个开箱即用的默认进程池，通常挂在 இது www-தரவு 用户下跑。

这种池子特别适合单站点环境：配置轻量，参数都是通用模板，比如：

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

如果你只托管一个站点，直接用它就能稳稳当当，不需要额外折腾。

etயுஎஃப்ஒ.org.conf：专属定制池

一旦你要跑多个站点，就不能再让大家挤在同一个池里了。
这时候HestiaCP会自动给每个站点单独开一个池，比如 etயுஎஃப்ஒ.org.conf，专门为域名 etufo.org 服务.

常见的玩法是：

• 换掉用户和组：user = etufo,group = etufo
• 独立监听：listen = /run/php/etufo.sock
• 调整进程数，保证高并发下依旧稳如老狗
• 单独日志文件，排错更清晰

好处显而易见：安全隔离。就算某个站点被攻破，其他站点也能安然无恙。

dummy.conf：摆设文件

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ஏனெனில் இது ஒரு குறிப்பிட்ட அளவு செயலற்ற செயல்முறைகளைப் பராமரிக்க முடியும் மற்றும் அதிக ஒத்திசைவின் போது 500 பிழைகளைத் தவிர்க்க முடியும்.

அணுகல் அளவு மிகக் குறைவாகவும், நினைவக வளங்கள் குறைவாகவும் இருக்கும்போது மட்டுமே இதைப் பயன்படுத்த பரிந்துரைக்கப்படுகிறது. 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: தேவைக்கேற்ப ஏற்படக்கூடிய கோரிக்கை காத்திருப்பைத் தவிர்க்க செயல்முறைகளை மிகவும் நெகிழ்வாக ஒதுக்குங்கள்;
• 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 进程最大内存占用

இது சிலவற்றைத் தடுக்கலாம்அதிக CPU ஐப் பயன்படுத்தும் 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. PHP செயல்படுத்தல் செயல்திறனை மேம்படுத்த OPcache ஐ இயக்கவும்.

OPcache இன்னும் இயக்கப்படவில்லை என்றால், நீங்கள் அதை இப்படி நிறுவலாம் (உபுண்டுவை உதாரணமாகப் பயன்படுத்தி):

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 நீண்ட செயல்பாட்டு நேரம் காரணமாக Nginx ஆல் PHP ஸ்கிரிப்ட்கள் நிறுத்தப்படுவதைத் தவிர்க்க அதை சரியான முறையில் சரிசெய்யவும்:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

சுருக்கம்: PHP-FPM ஐ மேம்படுத்தினால், வலைத்தளம் இனி செயலிழக்காது!

இந்த உகப்பாக்கத்திற்குப் பிறகு நாம் என்ன மாற்றங்களைச் செய்துள்ளோம்?

✅ PHP-FPM செயல்முறை தொகுப்பை மேம்படுத்துதல், பயன்படுத்த ondemandமற்றும் மேம்படுத்தவும் pm.max_children அளவுரு;
✅ PHP ஸ்கிரிப்ட்களின் செயல்பாட்டு நேரத்தைக் கட்டுப்படுத்துதல், நீண்ட கால CPU ஆக்கிரமிப்பைத் தடுக்க;
✅ PHP-FPM கண்காணிப்பை இயக்கு, செயல்முறை ஏற்றத்தை உண்மையான நேரத்தில் காண்க;
✅ PHP-FPM பதிவுகளை மேம்படுத்துதல், 500 பிழைகளை விரைவாக சரிசெய்தல்;
✅ PHP-FPM ஐ தொடர்ந்து மறுதொடக்கம் செய்யுங்கள்., நினைவக கசிவுகளைத் தடுக்கவும்;
✅ OPcache ஐ இயக்கு, PHP செயல்படுத்தல் செயல்திறனை மேம்படுத்துதல்;
✅ Nginx உள்ளமைவை மேம்படுத்துதல், காலாவதி சிக்கல்களைத் தவிர்க்க.

இந்த உகப்பாக்கத்திற்குப் பிறகு, PHP-FPM சுமை வெகுவாகக் குறைக்கப்படும், மேலும் வலைத்தள செயல்பாடு மிகவும் நிலையானதாக இருக்கும்! 🔥

இப்போதே முயற்சி செய்து பாருங்கள்! 💪🚀