Je HestiaCP PHP-FPM pod velkým zatížením? Chyba dynamické webové stránky 500? Tato optimalizace se projeví okamžitě!

Setkali jste se někdy s touto situací?Přístup k webu se náhle zpomalil, nebo dokonce vedl k chybě 500 Po restartu PHP-FPM se vrátil do normálu., ale problém se po chvíli znovu objeví? To je tak frustrující!

Proč se toto děje?Ve skutečnosti to tak obvykle jeProcesní fond PHP-FPM není správně nakonfigurován nebo jsou prostředky serveru nedostatečné.způsobené. Dnes budeme důkladně optimalizovat HestiaCP PHP-FPM pod kapotou dělá web stabilní jako skála!

Hlavní důvod, proč je PHP-FPM přetíženo

PHP-FPM je aSprávce procesů, který je zodpovědný za zpracování dynamických požadavků. Pokud konfigurace není rozumná, může to vést k:

• Prostředky serveru jsou vyčerpány, což způsobuje, že PHP-FPM není schopen reagovat na nové požadavky včas;
• Příliš málo procesů, když se návštěvnost náhle zvýší, nelze ji včas zpracovat;
• Využití procesu je příliš vysoké, což způsobí explozi zátěže CPU.

Jak zjistit, zda je PHP-FPM přetíženo?

může použít top Nebo htop Příkaz pro zobrazení využití CPU a paměti:

top -c

Pokud vidíte informace o procesu podobné následujícím, znamená to, že PHP-FPM běží pod vysokou zátěží:

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

Vidíte, jak tyto procesy zabírají více než 70 % CPU? Pokud se to stává často, váš PHP-FPM Musí tam být problém!

Jak tedy můžeme optimalizovat konfiguraci PHP-FPM, aby server již nebyl přetížen?

Optimalizace procesního fondu PHP-FPM (úprava základních parametrů)

Nejprve otevřete php-fpm Konfigurační soubory:

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

• *Změňte verzi PHP na PHP8.5 a změňte ji na toto:/etc/php/8.3/fpm/pool.d/www.conf

Dotaz na verzi PHP nastavenou programem HestiaCP

v-list-web-domain user domain.com

Např:

v-list-web-domain abc chenweiliang.com

Ve výstupu uvidíte něco jako:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

To znamená, že web používá PHP 8.5.

Pojďme se podívat na vaši konfiguraci 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

Můžete vidět, že vaše pm Ten použitý je ondemand,Ačkoli to může snížit využití zdrojů během doby nečinnosti, když se provoz náhle zvýší, proces nemusí být schopen včas reagovat.výsledkem je chyba 500.

www.conf: Vestavěný „univerzální fond zdrojů“ systému

Po instalaci PHP-FPM vám systém automaticky poskytne... www.conf soubor.
svéPolohováníJe to velmi jednoduché – je to jen výchozí procesní fond, který funguje ihned po instalaci, obvykle připojený k... www-data Stažení uživatelem.

Tento typ fondu je vhodný zejména pro prostředí s jedním webem: konfigurace je nenáročná a parametry jsou všechny generické šablony, například:

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

Pokud hostujete pouze jeden web, můžete ho používat přímo a spolehlivě bez jakýchkoli dalších potíží.

etUFO.org.conf: Vlastní fond

Jakmile provozujete více webů, nemůžete všechny namačkat do stejné skupiny.
V tomto okamžiku HestiaCP automaticky vytvoří samostatný pool pro každou lokalitu, například... etUFO.org.confSpecializováno na doménová jména etufo.org 服务。

Běžný způsob hraní je:

• Změna uživatelů a skupin:user = etufo,group = etufo
• Nezávislý monitoring:listen = /run/php/etufo.sock
• Úprava počtu procesů zajišťuje spolehlivou stabilitu i při vysoké souběžnosti.
• Samostatné soubory protokolu usnadňují odstraňování problémů.

Výhody jsou zřejmé:Bezpečná izolaceI když je jeden web napaden, ostatní weby zůstanou nedotčeny.

dummy.conf: soubor s fiktivními údaji

dummy.conf Obvykle se jedná o příklady nebo šablony poskytované systémem.
Ve skutečnosti se nespustí, pokud ho ručně neupravíte a nepovolíte.
Jeho význam je spíše jako „provozní manuál“, který vám říká, jak napsat novou konfiguraci fondu.

Proč rozdělovat bazén?

• 安全 性Používejte pro různé weby různé uživatele, abyste se vyhnuli konfliktu oprávnění.
• 性能优化Počet procesů lze upravit individuálně pro každý pool, což umožňuje flexibilní úpravy na základě poptávky po provozu.
• IzolaceProtokoly, chyby a naslouchací adresy jsou oddělené, což usnadňuje řešení problémů.

Například: dokonce www.conf Zhroutilo se to.etufo.org.conf Bude to i nadále fungovat normálně a nezpůsobí to výpadek celého serveru.

实际场景

• Server s jedním pracovištěmStačí www.conf.
• Vícemístný serverKaždý web má svůj vlastní nezávislý soubor .conf, například etufo.org.conf.
• dummy.confPouze pro informaci, nedoporučuje se.

Porovnání konfigurací

www.conf (výchozí fond)

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

etufo.org.conf (Vlastní fond)

[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

Hlavní rozdíl je:Identita uživatele, naslouchající adresa, počet procesů.

1. Upravte parametry procesního fondu PHP-FPM

Pokud konfigurace používá dynamicJedná se o metodu předběžného spuštění některých pracovních procesů a jejich dynamického přizpůsobení podle objemu požadavků, což umožňuje rychleji reagovat, když se objem požadavků náhle zvýší.

Pro webové stránky s určitou návštěvností se doporučuje používat pm = dynamicProtože dokáže udržovat určitý počet nečinných procesů a vyhnout se 500 chybám během vysoké souběžnosti.

Doporučuje se jej používat pouze v případě, že je přístupový objem extrémně nízký a paměťové zdroje jsou omezené. pm = ondemand Aby se šetřily zdroje.

Doporučeno změnit na dynamica optimalizovat pm.max_children A další parametry:

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

Proč to chceš takhle změnit?

• pm = dynamic: Přidělujte procesy flexibilněji, abyste se vyhnuli čekání na požadavky, které může být způsobeno ondemand;
• pm.max_children = 16: Zabránit 500 chybám způsobeným příliš malým počtem procesů;
• pm.start_servers = 5: Vyhněte se pomalému spouštění procesu;
• pm.max_requests = 3000:Prevence úniků paměti, proces pravidelně recyklujte.

2. Omezte dobu provádění PHP skriptů, abyste zabránili dlouhodobému obsazení

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

To může některým zabránitPHP skripty, které využívají příliš mnoho CPU, mohou zničit váš server.

Po uložení restartujte proces PHP:

sudo systemctl restart php8.3-fpm

根据VPS配置优化PHP-FPM

VPS的配置示例：

• Description: VPS 3 NVMe
• Místo na disku: 300 GB
• CPU cores: 8
• RAM: 24 GB

根据你的 VPS 配置（8 核 CPU、24 GB 内存），你的服务器资源非常充足。对于 PHP-FPM 来说，24 GB 内存允许你配置非常高的并发进程数。

在生产环境中，我们通常会为系统本身、Apache 数据库（如 MySQL/MariaDB）以及缓存（如 Redis/Memcached）留出足够的内存（假设留出 8GB-12GB），剩下的 12GB-16GB 内存可以完全分配给 PHP-FPM。

按照每个 PHP 进程平均占用 40 MB – 60 MB 内存计算，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.4-fpm.log.slow
request_slowlog_timeout = 5s

💡 为什么这样配置？

1. pm.max_children = 300：这是核心优化。你之前配置的 50 面对 24GB 内存太保守了。当遭遇突发大流量（或机器人刷后台）时，50 个进程瞬间就会被占满导致响应超时（Connection timed out）。提升到 300 可以让你的服务器并发处理能力提升数倍。
2. pm.start_servers / `min_spare_servers`：因为你有 8 个 CPU 核心，初始和常规保留更多的空闲进程，可以利用多核优势，让新进来的请求无需等待进程创建，直接秒开。
3. pm.max_requests = 1000：从 500 提升到 1000。你的内存很大，进程不需要频繁重启，提高到 1000 可以减少进程频繁销毁与创建带来的 CPU 损耗。

修改完成后，记得重启 PHP-FPM 服务使其生效：

systemctl restart php8.5-fpm

Povolte sledování stavu PHP-FPM, abyste mohli kdykoli sledovat průběh

Povolte monitorování procesu PHP-FPM a kdykoli si jej prohlédněteAktuální počet aktivních procesů a stav čekání na požadavek, aby nedošlo k přetížení serveru.

在 php-fpm.conf Přidáno v:

pm.status_path = /status

Poté konfigurace 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;
}

Tímto způsobem můžete http://yourdomain.com/status Podívejte se na PHP-FPM v akci!

Optimalizujte protokoly PHP-FPM pro rychlé řešení problémů

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

Tímto způsobem, kdykoli dojde k chybě 500, můžete přímo zobrazit protokol:

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

Podívejte se, zda PHP nehlásí chybu, jako např out of memory,script execution timeout Počkejte.

Pravidelně restartujte PHP-FPM, abyste zabránili úniku paměti

schopný projít cron Pravidelně restartujte PHP-FPM, abyste zabránili způsobení dlouhotrvajících procesůÚniky paměti.

crontab -e

Přidejte následující naplánovanou úlohu pro automatické restartování PHP-FPM každý den ve 3:XNUMX:

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

Co když problém přetrvává? Další optimalizace!

Pokud stále dodržujete výše uvedenou optimalizaciObčas se vyskytne 500 chyb, můžete pokračovat s následujícími optimalizacemi:

1. Povolte OPcache pro zlepšení efektivity provádění PHP

Pokud OPcache ještě není povolena, můžete ji nainstalovat takto (použijte Ubuntu jako příklad):

sudo apt install php8.5-opcache -y

Poté upravte php.ini:

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

• opcache.validate_timestamps=0
• Zakázat detekci v reálném časeSnižte počet operací v systému souborů a zvyšte výkon.

• To však znamená, že po úpravě souborů PHP musíte ručně vymazat mezipaměť (restartovat službu PHP).

Po úpravě konfigurace je nutné restartovat službu PHP, aby se změny projevily.

sudo systemctl restart php<版本>-fpm

Účinek? Rychlost spouštění stránek PHP se výrazně zlepšila!

2. Optimalizace konfigurace Nginx

Ujistěte se, že parametry související s Nginx jsou rozumné, jako např fastcgi_read_timeout Upravte jej vhodně, aby nedošlo k ukončení skriptů PHP ze strany Nginx kvůli dlouhé době provádění:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

Shrnutí: Optimalizujte PHP-FPM a web již nebude padat!

Jaké úpravy jsme provedli po této optimalizaci?

(Tj. Optimalizace fondu procesů PHP-FPM,použití ondemandA optimalizovat pm.max_children parametr;
(Tj. Omezení doby provádění PHP skriptů, aby se zabránilo dlouhodobému obsazení CPU;
(Tj. Povolit monitorování PHP-FPM, zobrazit zatížení procesu v reálném čase;
(Tj. Optimalizace protokolů PHP-FPM, rychle odstranit 500 chyb;
(Tj. Pravidelně restartujte PHP-FPM, zabránit únikům paměti;
(Tj. Povolit OPcache, zlepšit efektivitu provádění PHP;
(Tj. Optimalizace konfigurace Nginx, abyste se vyhnuli problémům s časovým limitem.

Po této optimalizaci se výrazně sníží zatížení PHP-FPM a provoz webu bude stabilnější! 🔥

Jdi to zkusit hned teď! 💪🚀