PHP 7.4在宝塔中内存失控需三同步校准：先用ps命令实测单进程RSS（如38MB），再按可用内存÷RSS×0.8得安全pm.max_children值（如56–60）；确认OPcache在Web环境真实启用且配置合理（memory_consumption=256、max_accelerated_files=7963）；将pm模式从static改为dynamic并配齐start/min/max_spare_servers参数。
PHP 7.4 在宝塔面板中运行时，常因内存占用失控、进程排队、缓存未生效导致 CPU 和内存持续飙高，2核2G服务器上 WordPress 刷一次 F5 就可能触发 OOM Killer 杀进程，必须从 PHP-FPM 进程模型、OPcache 实际加载状态、单进程真实内存消耗三方面同步校准，不能只调一个参数。
确认当前 PHP-FPM 进程真实内存占用
宝塔界面上显示的 pm.max_children=50 是假象——它没考虑你每个 php-fpm 进程实际吃多少 RSS 内存。不查实测值就调参，等于蒙眼开车。
在 SSH 中执行：ps --no-headers -o rss -C php-fpm | awk '{sum+=$1} END {print int(sum/NR/1024)" MB"}'
若结果是 【38 MB】，说明每个进程常驻内存约 38MB；若开了 Xdebug 或 Laravel + 大量 Composer 包，可能高达 60–80MB；没开扩展的小站可能仅 22MB。别信“平均 30MB”这种模糊说法。
立即学习“PHP免费学习笔记（深入）”；
执行 ps aux --sort=-%mem | grep php-fpm | head -n 5，直接看 RSS 列，取前 5 个里最稳定的数值作为基准。
按内存倒推设置 pm.max_children 安全值
第一步：算出系统可分配给 PHP 的内存上限。4GB 总内存 → 预留 30% 给系统、MySQL、宝塔自身 → 可用约 2800MB。
第二步：用可用内存 ÷ 单进程 RSS（比如 38MB）→ floor(2800 / 38) ≈ 73。
第三步：打八折留余量 → 73 × 0.8 = 58.4 → 建议设为 【56–60】。
设成 100？那光 PHP 就要吃掉 3.8GB+，系统立刻启动 OOM Killer 杀进程，网站直接 502。
宝塔界面改完后，必须点「重载配置」，只「保存」不生效；改前先运行 php-fpm -t 校验语法，避免配置错误导致服务崩溃。
验证 OPcache 是否真在 Web 环境生效
很多人点了“安装 opcache”就以为加速了，其实 CLI 和 Web 用的是两套配置，php -m | grep opcache 成功不代表网页能用。
方法一：建 info.php，内容为 <?php phpinfo(); ?>，浏览器访问后搜索 “Loaded Configuration File”，复制路径 —— 这才是你要改的 php.ini。
方法二：确认该文件里有 zend_extension=opcache.so（不是 extension=opcache.so），且前面没分号或 # 注释。
方法三：搜索 “Opcode Caching”，状态必须是 Enabled；同时检查 opcache.enable 行显示 On。若 opcache_get_status() 报 Call to undefined function，说明扩展压根没加载进 Web SAPI。
调整 OPcache 关键参数防止缓存失效
宝塔默认值对现代框架完全不够：opcache.max_accelerated_files=2000 容易打满，缓存频繁淘汰反而拖慢响应。
进入宝塔 → PHP 7.4 设置 → 配置修改，在 [opcache] 区块下确保以下几项存在且未注释：
opcache.memory_consumption=256（WordPress 插件多时，128MB 容易踢缓存）
opcache.max_accelerated_files=7963（质数，减少哈希冲突；插件超 15000 时建议 ≥10000）
opcache.validate_timestamps=0（上线后必须关，否则代码更新后白屏）
opcache.revalidate_freq=60（设为 0 就等于每次请求都扫描文件时间戳，失去加速意义）
改完必须点「重载配置」，它会自动执行 systemctl restart php74-fpm；只重启 Nginx 或只点“保存”都不起作用。
切换 PHP-FPM 进程模型避免静态模式卡死
宝塔 PHP 7.4 默认用 pm = static + pm.max_children = 10，而一个 WordPress 前台页面平均占 3–5 个进程。3 个用户同时刷页，请求就开始排队，TTFB 直接飙到 1s+，这时 OpCache 命中率反而虚高——因为多数请求根本没走到 PHP 执行层，卡在 FPM 队列里。
进宝塔 → PHP 设置 → 配置修改 → 找到 www.conf 片段，把 pm = static 改成 pm = dynamic。
同时设置：pm.max_children = 56、pm.start_servers = 10、pm.min_spare_servers = 6、pm.max_spare_servers = 16。
动态模式能根据负载自动伸缩空闲进程数，避免低峰期浪费资源、高峰期排队阻塞。
