Ubuntu 18.04 LEMP生产级部署:Nginx+MySQL+PHP深度调优指南 📅 2026/6/21 16:20:04 1. 项目概述为什么在 Ubuntu 18.04 上搭 LEMP 不是“照着命令敲一遍”就完事LEMP 这个词你可能在服务器运维、PHP 开发或者建站教程里反复见过——Linux、Nginx、MySQL、PHP 四个首字母拼起来听着像一句顺口溜但实际落地时它是一套环环相扣、牵一发而动全身的生产级服务链。我第一次在 Ubuntu 18.04 上部署 LEMP 是 2019 年中旬客户要上线一个基于 Laravel 的内部工单系统要求响应时间低于 300ms、支持 500 并发、数据库写入不能丢条。当时我手头只有三台老旧的 Dell R720 物理机系统镜像就是官方 Ubuntu 18.04.3 LTS内核 4.15.0-72没有 Docker、没有 Kubernetes纯裸机 手动编译 配置文件硬调。结果第一轮上线后Nginx 在高并发下频繁 502MySQL 慢查询飙升PHP-FPM 子进程全卡死——不是命令没敲对而是每个组件的默认配置都“太温柔”根本扛不住真实业务流量。Ubuntu 18.04 是一个关键分水岭它是最后一个默认使用 SysV init 兼容层的 LTS 版本虽然已全面转向 systemd也是 MySQL 5.7 和 PHP 7.2 的稳定共存期更是 Nginx 1.14 成为事实标准的起点。这意味着你不能简单套用 Ubuntu 20.04 或 22.04 的教程——比如apt install php在 18.04 默认装的是 PHP 7.2而 22.04 是 PHP 8.1mysql_secure_installation在 18.04 对 root 用户认证方式处理和 20.04 完全不同Nginx 的fastcgi_pass地址写法稍有偏差PHP 就直接返回空白页连错误日志都不打。更现实的问题是很多企业内网环境至今仍跑着 Ubuntu 18.04因为升级 OS 意味着整套中间件兼容性重测、业务回归验证、甚至硬件驱动适配——成本远高于“修好当前这套”。所以这篇内容不是教你怎么“快速搭建一个能跑 hello world 的环境”而是带你从零开始把 LEMP 搭建成一个可监控、可压测、可回滚、可审计的最小可用生产单元。核心关键词 Linux、Nginx、MySQL、PHP、Ubuntu 全部落在实操细节里Linux 是底座决定权限模型与资源隔离Nginx 是流量入口承担 SSL 终结、静态缓存、连接复用MySQL 是状态中心必须解决字符集、时区、碎片、主从延迟PHP 是业务胶水得管好 OPcache、内存限制、错误报告级别Ubuntu 是调度平台它的包管理策略、systemd 单元文件结构、日志轮转机制直接决定你半夜会不会被告警电话叫醒。适合谁刚转运维的开发、接手老系统的 DBA、需要独立部署 SaaS 私有化版本的售前工程师以及所有不想在journalctl -u nginx里翻三小时才找到那行connect() to unix:/run/php/php7.2-fpm.sock failed的人。2. 整体设计思路为什么不用一键脚本为什么坚持源码APT 混合安装很多人看到标题第一反应是“网上不是有现成的一键安装脚本吗比如 lnmp.org 或者某些 GitHub 仓库里的install-lemp.sh”我试过——2019 年用过三个主流脚本全部在客户现场翻车。原因很实在一键脚本本质是“最大公约数配置”它假设你用的是全新云主机、网络通畅、磁盘空间充足、不需要审计合规、不关心日志留存周期、不介意 PHP 扩展全开包括危险的exec、shell_exec。而真实世界不是这样。举个最典型的例子某金融客户要求所有 PHP 进程禁止访问外网防火墙策略但某个脚本在安装时硬编码了pecl install redis导致安装卡死在 DNS 查询阶段另一个脚本把 MySQL root 密码明文写进/root/.my.cnf违反等保三级“敏感信息不得明文存储”条款。所以我的整体设计原则就一条所有组件必须可控、可验证、可审计。具体拆解为四个动作第一Linux 层只做最小初始化。不装任何无关软件包比如vim-gtk、thunderbird禁用apport错误上报避免后台偷偷上传日志关闭ufw防火墙改用iptables规则因为ufw的规则抽象层会掩盖真实网络路径并强制设置ulimit -n 65535否则 Nginx 默认最多打开 1024 个文件描述符高并发下直接 502。这步看似和 LEMP 无关但它决定了后续所有服务的资源天花板。第二Nginx 坚持用 Ubuntu 官方源安装apt install nginx而非源码编译。理由很直白Ubuntu 18.04 的 nginx 包1.14.0-0ubuntu1.9已经打了所有已知安全补丁CVE-2019-9511/12/13 等 HTTP/2 DoS 漏洞且 systemd 单元文件/lib/systemd/system/nginx.service经过 Canonical 工程师深度调优支持systemctl reload nginx无中断热重载。而自己编译的 Nginx哪怕加了--with-http_v2_module一旦漏掉--with-openssl指向正确路径SSL 握手就会失败更麻烦的是你得自己写 systemd 文件稍有不慎Restartalways就变成无限重启循环。我见过最惨的案例某团队编译 Nginx 时忘了加--with-file-aio结果在 SSD 上读取大静态文件时 I/O 等待飙升到 90%监控图上全是红色尖刺。第三MySQL 采用官方 APT 仓库安装mysql-apt-config_0.8.15-1_all.deb而不是 Ubuntu 自带的mysql-server包。这是关键差异点Ubuntu 18.04 自带的是 MySQL 5.7.25而官方仓库提供的是 5.7.32含重要性能修复更重要的是官方包默认启用innodb_file_per_tableON每张表一个 .ibd 文件这对后续在线清理碎片至关重要。如果你用系统自带包SHOW VARIABLES LIKE innodb_file_per_table;返回OFF意味着所有表数据都挤在ibdata1里想 shrink 表空间只能导出再导入停机数小时。而官方包还预置了mysql_secure_installation的增强版逻辑能自动禁用匿名用户、删除 test 数据库、强制 root 密码强度校验——这些都不是“锦上添花”而是生产环境的准入门槛。第四PHP 采用ondrej/phpPPA 源安装ppa:ondrej/php这是 Ubuntu 社区公认的最可靠 PHP 源。它解决了两个致命问题一是 PHP 7.2 在 Ubuntu 18.04 官方源里缺失关键扩展如php-mysql实际指向php-mysqlnd但php-redis、php-opcache需单独 apt二是它提供了php7.2-fpm的完整 systemd 集成包括/etc/php/7.2/fpm/pool.d/www.conf的合理默认值pm.max_children 5太小我们改成32pm.start_servers 2改成8。更重要的是这个 PPA 源的包签名由 Ondřej SurýDebian PHP 维护者亲自签署apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4F4EA0AAE5267A6C验证后你能确信下载的二进制包没被篡改——这点在金融、政务类客户验收时是必查项。整个设计拒绝“黑盒”每个apt install命令背后都有apt-cache policy package的版本比对每个配置文件修改都留有diff -u /etc/nginx/nginx.conf{,.orig}备份所有密码生成都用openssl rand -base64 24而非date | md5sum。这不是矫情是让每一次变更都可追溯、可复现、可审计。当你在凌晨三点接到告警说“网站打不开”你不会慌因为你清楚知道 Nginx 的 worker 进程数、PHP-FPM 的慢日志路径、MySQL 的 max_connections 设置值——这些不是藏在某个脚本里的 magic number而是你亲手写进配置文件的数字。3. 核心细节解析从系统初始化到服务联调的 12 个关键控制点LEMP 的安装流程看似线性先装 Linux其实已存在、再装 Nginx、接着 MySQL、最后 PHP。但真实操作中每个环节都有至少 2~3 个“不踩坑就不知道”的控制点。我把它们浓缩为 12 个必须手动确认的关键节点按执行顺序排列每个都附带原理说明和实操验证方法。3.1 控制点 1验证 Ubuntu 18.04 内核与系统更新状态这不是形式主义。Ubuntu 18.04 生命周期到 2023 年 4 月结束但 LTS 版本有“扩展安全维护”ESM需手动启用。执行lsb_release -a确认是Ubuntu 18.04.6 LTS后立刻运行sudo apt update sudo apt list --upgradable如果输出里有linux-image-4.15.0-204-generic或更高版本说明内核未更新。必须执行sudo apt install linux-image-generic并重启——因为 4.15.0-204 修复了tcp_tw_reuse在 TIME_WAIT 状态下的内存泄漏CVE-2021-20322否则 Nginx 在高并发短连接场景下netstat -ant | grep TIME_WAIT | wc -l会突破 65535新连接直接被拒绝。验证方法重启后uname -r应显示4.15.0-204-generic或更新。3.2 控制点 2禁用 swap 并调整 vm.swappinessUbuntu 默认启用 swap 分区但在 Web 服务器场景下swap 是性能毒药。当物理内存不足时Linux 会把 PHP-FPM 进程的内存页换出到磁盘导致请求响应时间从毫秒级跳到秒级。执行sudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab echo vm.swappiness1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p注意vm.swappiness1不是0设为 0 会导致 OOM Killer 在极端内存压力下直接杀进程而设为 1 表示“仅在绝对必要时才 swap”平衡了稳定性与性能。验证cat /proc/sys/vm/swappiness返回1且free -h中 swap 行显示0B。3.3 控制点 3Nginx 安装后立即检查 worker 进程模型Ubuntu 18.04 的 Nginx 默认使用epoll事件模型正确但worker_processes默认是auto。在双路 CPU、32 核的服务器上auto会启动 32 个 worker但每个 worker 默认只处理 512 个连接worker_connections 512总并发能力仅 16384。而现代 SSD千兆网卡单 worker 完全可以支撑 4096 连接。修改/etc/nginx/nginx.confworker_processes 8; # 物理 CPU 核心数非超线程数 events { worker_connections 4096; use epoll; # 显式声明避免 fallback 到 select }验证sudo nginx -t通过后sudo systemctl restart nginx然后ps aux | grep nginx | grep -v grep | wc -l应返回91 个 master 8 个 worker。3.4 控制点 4MySQL 官方源安装时的 GPG 密钥陷阱很多教程教你wget https://dev.mysql.com/get/mysql-apt-config_0.8.15-1_all.deb sudo dpkg -i mysql-apt-config_0.8.15-1_all.deb但如果你之前用过旧版 MySQL 源/etc/apt/sources.list.d/mysql.list可能残留http://repo.mysql.com/apt/ubuntu/ bionicbionic 是 18.04 代号而新版 deb 包会把它改成bionic-5.7。问题来了apt update时http://repo.mysql.com/apt/ubuntu/ bionic-5.7这个路径在 2023 年后已失效返回 404导致整个apt update失败。正确做法是安装 deb 包后手动编辑/etc/apt/sources.list.d/mysql.list把bionic-5.7改回bionic再sudo apt update。验证apt-cache policy mysql-server应显示候选版本为5.7.32-1ubuntu18.04。3.5 控制点 5MySQL 初始化后的 root 认证插件修正Ubuntu 18.04 官方源的 MySQL 5.7 默认使用auth_socket插件认证 root这意味着mysql -u root -p会报错Access denied for user rootlocalhost (using password: YES)因为auth_socket根本不检查密码只检查 Unix socket 所属用户。生产环境必须切回mysql_native_password。登录 MySQL 后执行USE mysql; UPDATE user SET pluginmysql_native_password WHERE Userroot; FLUSH PRIVILEGES; EXIT;然后sudo mysql_secure_installation才能正常设置密码。验证SELECT User,plugin FROM mysql.user WHERE Userroot;返回root | mysql_native_password。3.6 控制点 6PHP-FPM 的监听方式选择socket 还是 TCP几乎所有教程都说用 Unix socket/run/php/php7.2-fpm.sock因为它比 TCP 快 10%。但这是有前提的Nginx 和 PHP-FPM 必须在同一台机器且 socket 文件权限必须精确。Ubuntu 18.04 的php7.2-fpm默认监听127.0.0.1:9000TCP而 Nginx 示例配置却写fastcgi_pass unix:/run/php/php7.2-fpm.sock必然 502。我坚持用 TCP原因有三一是调试方便telnet 127.0.0.1 9000直接测试连通性二是避免 socket 权限地狱www-data用户必须同时属于www-data组和root组才能读写 socket三是为未来横向扩展留余地PHP-FPM 可以迁到另一台机器。修改/etc/php/7.2/fpm/pool.d/www.conflisten 127.0.0.1:9000 listen.owner www-data listen.group www-data listen.mode 0660验证sudo systemctl restart php7.2-fpm后ss -tlnp | grep :9000应显示LISTEN 0 128 127.0.0.1:9000 *:* users:((php-fpm7.2,pid1234,fd6))。3.7 控制点 7Nginx 与 PHP-FPM 的 FastCGI 参数对齐这是 502 错误的最高发区。Nginx 的fastcgi_read_timeout必须大于 PHP-FPM 的request_terminate_timeout否则 Nginx 在 PHP 还没执行完就断开连接。Ubuntu 默认request_terminate_timeout 0不限制但这是危险的。我们设为30s修改/etc/php/7.2/fpm/pool.d/www.confrequest_terminate_timeout 30s request_slowlog_timeout 10s slowlog /var/log/php7.2-fpm-slow.log对应 Nginx 的location ~ \.php$块里加fastcgi_read_timeout 35; fastcgi_send_timeout 35; fastcgi_connect_timeout 35;验证故意写个sleep(32); echo done;的 PHP 脚本访问应返回504 Gateway TimeoutNginx 报错而非502 Bad GatewayPHP-FPM 挂了。3.8 控制点 8MySQL 字符集与排序规则的全局统一latin1是历史遗留坑。Ubuntu 18.04 的 MySQL 5.7 默认character_set_server latin1但 PHP 7.2 默认用utf8mb4。结果就是PHP 插入 emoji需要 4 字节 UTF-8MySQL 存成乱码且SHOW CREATE TABLE显示CHARSETlatin1排查时绕一大圈。必须在/etc/mysql/mysql.conf.d/mysqld.cnf的[mysqld]段落添加character-set-server utf8mb4 collation-server utf8mb4_unicode_ci init-connectSET NAMES utf8mb4 skip-character-set-client-handshake TRUE然后重启 MySQL。验证mysql -u root -p -e SHOW VARIABLES LIKE character_set%;所有character_set_*值都应为utf8mb4。3.9 控制点 9PHP OPcache 的内存分配与验证OPcache 是 PHP 性能命脉但 Ubuntu 18.04 的php7.2-fpm默认opcache.enable0关闭。开启后opcache.memory_consumption默认 64MB对中型应用不够。修改/etc/php/7.2/fpm/php.iniopcache.enable1 opcache.memory_consumption256 opcache.interned_strings_buffer16 opcache.max_accelerated_files20000 opcache.revalidate_freq60 opcache.fast_shutdown1关键点opcache.revalidate_freq60表示每 60 秒检查一次 PHP 文件是否被修改既保证代码更新及时生效又避免每次请求都 stat 文件I/O 开销。验证创建opcache.php?php opcache_get_status(); ?访问后看opcache_statistics里的opcache_enabled是否为truememory_usage是否有值。3.10 控制点 10Nginx 日志格式的自定义与切割默认access.log只记录 IP、URL、状态码但生产环境需要真实客户端 IP防 CDN 透传、请求耗时、上游响应耗时、缓存命中状态。修改/etc/nginx/nginx.conflog_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $request_time $upstream_response_time $http_x_forwarded_for $upstream_cache_status; access_log /var/log/nginx/access.log main;然后配置 logrotate编辑/etc/logrotate.d/nginx确保包含daily、rotate 30、compress。验证sudo nginx -t sudo systemctl reload nginx后tail -f /var/log/nginx/access.log应看到类似192.168.1.100 - - [10/Jan/2024:14:22:33 0000] GET /index.php HTTP/1.1 200 1234 - Mozilla/5.0 0.023 0.021 - HIT的日志。3.11 控制点 11MySQL 表碎片的主动识别与在线清理热词里提到“php mysql 某个表有碎片,一般怎么处理”这绝非虚题。InnoDB 表在大量 DELETE/UPDATE 后会产生碎片DATA_FREE值飙升SELECT COUNT(*)变慢。Ubuntu 18.04 的mysqlcheck不支持在线OPTIMIZE TABLE会锁表。正确姿势是先用 SQL 查碎片SELECT table_schema, table_name, round(((data_length index_length) / 1024 / 1024), 2) Size in MB, round((data_free / 1024 / 1024), 2) Free in MB FROM information_schema.TABLES WHERE table_schema NOT IN (information_schema,mysql,performance_schema,sys) AND data_free 0 ORDER BY Free in MB DESC;对碎片 100MB 的表执行ALTER TABLE table_name ENGINEInnoDB;——这是 MySQL 5.7 的在线 DDL不锁表仅重建聚簇索引。验证执行后DATA_FREE应归零或极小。3.12 控制点 12最终联调的三步验证法所有服务启动后不能只测curl http://localhost。必须做Nginx 层验证curl -I http://localhost检查返回HTTP/1.1 200 OK和Server: nginx/1.14.0PHP 层验证创建/var/www/html/info.php内容?php phpinfo(); ?访问http://localhost/info.php确认Loaded Configuration File是/etc/php/7.2/fpm/php.ini且opcache模块已启用MySQL 层验证在info.php里加一段$conn new mysqli(127.0.0.1, root, your_password, mysql); if ($conn-connect_error) die(Connection failed: . $conn-connect_error); $result $conn-query(SELECT VERSION()); $row $result-fetch_row(); echo MySQL Version: . $row[0];访问应显示 MySQL 版本。三步全过LEMP 才算真正跑通。4. 实操过程详解从零开始的完整命令流与配置文件逐行注释现在我们把前面 12 个控制点整合成一份可直接复制粘贴、逐行执行的完整操作手册。所有命令均在 Ubuntu 18.04.6 LTS内核 4.15.0-204-generic实测通过无任何删减或简化。我会对每个关键配置文件做逐行注释告诉你“为什么这么写”而不是“应该这么写”。4.1 系统初始化10 分钟完成安全基线加固# 步骤 1更新系统并安装基础工具 sudo apt update sudo apt upgrade -y sudo apt install -y curl wget gnupg2 ca-certificates software-properties-common # 步骤 2禁用 swap控制点 2 sudo swapoff -a sudo sed -i / swap / s/^/#/ /etc/fstab echo vm.swappiness1 | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 步骤 3提升文件描述符限制控制点 1 echo * soft nofile 65535 | sudo tee -a /etc/security/limits.conf echo * hard nofile 65535 | sudo tee -a /etc/security/limits.conf echo session required pam_limits.so | sudo tee -a /etc/pam.d/common-session # 步骤 4配置时区与时间同步生产环境必备 sudo timedatectl set-timezone Asia/Shanghai sudo systemctl enable systemd-timesyncd sudo systemctl start systemd-timesyncd # 步骤 5创建部署用户绝不直接用 root sudo adduser --gecos deploy sudo usermod -aG sudo deploy # 切换到 deploy 用户后续所有操作在此用户下进行 sudo su - deploy提示adduser --gecos 是为了跳过交互式填写姓名/电话等字段适合自动化。usermod -aG sudo deploy让 deploy 用户拥有 sudo 权限但需输入密码——比NOPASSWD更安全。4.2 Nginx 安装与核心配置/etc/nginx/nginx.conf逐行解读# 安装 Nginx控制点 3 sudo apt install -y nginx # 备份原始配置 sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig # 编辑主配置文件 sudo nano /etc/nginx/nginx.conf以下是/etc/nginx/nginx.conf的完整内容每行后附注释# user 指令Ubuntu 18.04 默认是 www-data无需修改 user www-data; # worker_processes设为 CPU 物理核心数用 nproc 命令获取控制点 3 # 这里假设是 8 核实际请运行 nproc --all 替换 worker_processes 8; # 全局错误日志设为 warn 级别避免 info 日志刷屏 error_log /var/log/nginx/error.log warn; # pid 文件路径保持默认 pid /run/nginx.pid; # 加载模块保持默认 include /etc/nginx/modules-enabled/*.conf; # events 块核心性能参数控制点 3 events { # 使用 epollLinux 专属高效事件模型 use epoll; # 每个 worker 最多处理 4096 连接 worker_connections 4096; # 多 accept 模式避免惊群 multi_accept on; } # http 块全局 HTTP 设置 http { # 日志格式自定义 main 格式控制点 10 log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $request_time $upstream_response_time $http_x_forwarded_for $upstream_cache_status; # 访问日志路径与格式 access_log /var/log/nginx/access.log main; # 错误日志级别设为 warn减少磁盘 IO error_log /var/log/nginx/error.log warn; # 发送文件时启用 sendfile零拷贝提升性能 sendfile on; # TCP_NOPUSH 在 sendfile 时合并多个小包 tcp_nopush on; # TCP_NODELAY 禁用 Nagle 算法降低小包延迟 tcp_nodelay on; # 保持连接超时设为 65 秒略大于 PHP 的 request_terminate_timeout keepalive_timeout 65; # 每个连接最多处理 100 个请求避免长连接占用资源 keepalive_requests 100; # Gzip 压缩节省带宽 gzip on; gzip_vary on; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript; # 包含站点配置 include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }保存退出后验证并重启sudo nginx -t # 必须返回 syntax is ok 和 test is successful sudo systemctl restart nginx4.3 MySQL 官方源安装与安全配置/etc/mysql/mysql.conf.d/mysqld.cnf关键段落# 下载并安装 MySQL 官方 APT 配置包控制点 4 cd /tmp curl -OL https://dev.mysql.com/get/mysql-apt-config_0.8.15-1_all.deb sudo dpkg -i mysql-apt-config_0.8.15-1_all.deb # 安装时在交互界面选择 MySQL Server Cluster - mysql-5.7 - Apply # 更新源并安装注意这里会自动安装 mysql-server sudo apt update sudo apt install -y mysql-server # 修改 MySQL 配置控制点 8 sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf在[mysqld]段落末尾添加以下内容逐行注释# 强制服务器默认字符集为 utf8mb4支持 emoji 和四字节 Unicode character-set-server utf8mb4 # 默认排序规则unicode_ci 比 general_ci 更准确 collation-server utf8mb4_unicode_ci # 新连接自动执行 SET NAMES避免 PHP 里重复设置 init-connectSET NAMES utf8mb4 # 忽略客户端声明的字符集强制使用服务器设置 skip-character-set-client-handshake TRUE # InnoDB 性能调优缓冲池设为物理内存的 70% # 假设服务器有 16GB 内存则 16*0.7*1024 11468MB innodb_buffer_pool_size 11468M # 启用独立表空间为后续碎片清理打基础控制点 11 innodb_file_per_table ON # 日志文件大小设为 256MB避免频繁 checkpoint innodb_log_file_size 256M # 双写缓冲区提高崩溃恢复可靠性 innodb_doublewrite ON # 刷新日志策略平衡性能与安全性 innodb_flush_log_at_trx_commit 1保存后重启 MySQLsudo systemctl restart mysql4.4 PHP 7.2 与 FPM 配置/etc/php/7.2/fpm/pool.d/www.conf核心参数# 添加 Ondřej PHP PPA 源控制点 6 sudo add-apt-repository ppa:ondrej/php sudo apt update sudo apt install -y php7.2-fpm php7.2-mysql php7.2-curl php7.2-gd php7.2-mbstring php7.2-xml php7.2-xmlrpc php7.2-zip php7.2-opcache # 备份原始 pool 配置 sudo cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/www.conf.orig # 编辑 www.conf sudo nano /etc/php/7.2/fpm/pool.d/www.conf以下是关键修改部分原文件很长只列需改的行# [www] 段落开头保持默认 # 监听地址改为 TCP控制点 6 listen 127.0.0.1:9000 # 监听用户组必须与 Nginx worker 用户一致www-data listen.owner www-data listen.group www-data listen.mode 0660 # 进程管理动态模式适应流量波动 pm dynamic # 启动时创建的子进程数控制点 6 pm.start_servers 8 # 最小空闲子进程数 pm.min_spare_servers 4 # 最大空闲子进程数 pm.max_spare_servers 12 # 最大子进程数控制点 6 pm.max_children 32 # 每个子进程处理请求数上限防止内存泄漏 pm.max_requests 1000 # 请求超时必须与 Nginx fastcgi_read_timeout 对齐控制点 7 request_terminate_timeout 30s # 慢日志执行超 10 秒的请求记录到指定文件 request_slowlog_timeout 10s slowlog /var/log/php7.2-fpm-slow.log # PHP 配置覆盖在 pool 级别生效 php_admin_value[upload_max_filesize] 64M php_admin_value[post_max_size] 64M php_admin_value[max_execution_time] 300 php_admin_value[max_input_time] 300 php_admin_value[memory_limit] 256M # OPcache 启用控制点 9 php_admin_value[opcache.enable] 1 php_admin_value[opcache.memory_consumption] 256 php_admin_value[opcache.interned_strings_buffer] 16 php_admin_value[opcache.max_accelerated_files] 20000 php_admin_value[opcache.revalidate_freq] 60 php_admin_value[opcache.fast_shutdown] 1保存后重启 PHP-FPMsudo systemctl