电商大促那几天最怕的往往不是业务代码出 Bug而是服务器在流量冲上来之后突然从 500 毫秒变成 3 秒紧接着后台飘红一片 502。如果你手里跑的是 SUSE Linux Enterprise Server 15应用栈又是经典的 Nginx PHP-FPM那么这篇文章就是冲着你来的怎么把这套组合从“能跑”调到“扛得住”在保持响应速度的前提下尽量不让 PHP 拖后腿也不让 Nginx 变成瓶颈。我操作过的线上环境里这套配置从默认值到最终优化完成压测 QPS 大概能翻三倍左右P95 响应时间也能稳稳降下来。下面我会按实际部署的顺序拆开讲每个参数为什么这么调、调了有多大影响、踩过什么坑尽量讲透方便你对照自己的服务器直接抄作业。1. 先想清楚调优到底调的是什么1.1 大流量下电商应用的真实瓶颈电商类的 PHP 应用有一个很典型的特征动态请求占比高而且每个请求背后往往连着数据库、Redis、外部接口业务代码本身就可能吃掉几十毫秒到几百毫秒。这个时候压垮系统的通常是两个点一是 PHP-FPM 进程池耗尽新请求进来直接排队二是 Nginx 和 PHP-FPM 之间衔接不当代理缓冲、超时、连接复用等参数不合理导致请求在中间层空等。很多人一上来就调内核参数、开 gzip但真正的大头反而在进程池和 upstream 连接的配置上。还要注意一个容易被忽略的事实Nginx 处理静态文件的能力极强绝大多数时候瓶颈不在 Nginx 的 I/O 上而在 PHP 侧的并发能力。所以调优的第一步不是盲目堆高 worker_processes而是先搞清楚请求链路里哪一段是短板。我在压测时发现默认配置下 PHP-FPM 的 max_children 只有 16 左右一旦并发超过这个数队列堆积响应时间会呈指数恶化而这种恶化经常被误认为“带宽不够”或“数据库慢”。1.2 SLES 15 这套组合的特别之处SLES 15 是 SUSE 面向企业服务器的发行版包管理的默认行为和 CentOS、Debian 都有差异踩坑点全在细节上。第一官方仓库里 PHP 相关包的版本取决于你当前激活的 Service Pack有的 SP 版本默认给的是 PHP 7老一些的环境还在用 PHP 5 的残留配置需要特别留意。第二SLES 15 默认不会帮你把 nginx.org 的仓库加进来你要么手动添加仓库要么用 SUSE 自家仓库里的版本后者版本可能比上游慢半拍。第三SLES 默认环境里强制访问控制的安全策略需要放行否则 Nginx 的 unix socket 或 PHP-FPM 的日志目录可能被静默拦掉。这些差异意味着网上大量针对 Ubuntu 的教程不能直接照搬比如直接用 apt install nginx 在 SLES 上根本不存在。我个人倒是更喜欢用 nginx.org 官方仓库的方式版本可控而且和上游配置文件的习惯完全一致。至于 PHP-FPM最好通过 SUSE PackageHub 安装因为官方主仓库里 php-fpm 这个包不一定默认启用漏掉这一步后面会少很多可用模块。1.3 性能目标怎么定义调优前先给自己定一个可量化的目标不然你会陷入“调了又调但不知道有没有效果”的泥潭。我的做法是两阶段设定第一阶段压测目标用 ab 或 wrk 在固定并发比如 200、400、800下测试观察 QPS 和错误率第二阶段业务目标压测得到的 P95 响应时间要比优化前低至少 30%错误率低于 0.5%。注意不要只盯着 QPS一个高的 QPS 如果伴随大量超时说明服务器的承受能力是虚假的。我建议在你的压测环境里至少准备一台和线上同规格的机器很多参数优化效果在低配机器上非常不明显比如 worker_processes 从 auto 改成手动指定后4 核机器和 16 核机器的行为完全不一样。目标定清楚之后下一步才是动手装环境。2. 环境准备与基础部署2.1 在 SLES 15 上装 Nginx 的两种路径SLES 15 上装 Nginx 有两条主流路径。第一条是用 zypper 直接安装系统仓库里的版本好处是命令简单依赖问题少坏处是版本相对保守而且部分优化模块可能没编进去。我自己的生产环境更推荐第二条添加 nginx.org 官方仓库保持和上游同步配置文件结构也更干净。具体命令大概是# 导入签名 sudo rpm --import https://nginx.org/keys/nginx_signing.key # 添加 nginx 官方 SLES 15 仓库 sudo zypper addrepo --gpgcheck-auto-import yes \ https://nginx.org/packages/sles/15/ nginx-repo # 安装 sudo zypper install nginx安装完不要急着启动先检查一下版本和编译参数nginx -V你会看到 configure arguments 那一大串这里要重点关注有没有 --with-http_stub_status_module。现在 nginx 官方包默认通常是带上的但如果你用的是发行版自带包建议确认一下后面要拿状态页做监控时全靠它。如果确实没有不少人在 SLES 上会走源码编译自己加 --with-http_stub_status_module 和 --with-http_slice_module相对麻烦一些但可控性高。启动服务前我习惯先把 nginx 的默认站点注释掉免得后面测试时 80 端口上的欢迎页干扰判断sudo systemctl enable --now nginx sudo curl -I http://127.0.0.1/一旦看到 nginx 默认页面的响应头就说明基础服务已经起跑。2.2 PHP-FPM 的安装与扩展选型PHP-FPM 在 SLES 15 上的安装路径稍微曲折一点。如果你直接 zypper install php7-fpm可能提示找不到包这种情况十有八九是 PackageHub 仓库没激活。SLES 15 的服务包管理和系统包管理是分开的PackageHub 需要先用 SUSEConnect 激活sudo SUSEConnect -p PackageHub/15.5/x86_64 sudo zypper install php7 php7-fpm php7-opcache php7-mysql php7-curl \ php7-json php7-xml php7-mbstring php7-gd php7-bcmath如果你的 SLES 是 SP3 或更高版本可能已经拿到 PHP 8 的包版本号换成 php8 前缀即可。需要什么扩展取决于电商平台的技术栈但 opcache 一定要装这是 PHP 响应能力提升性价比最高的一块后面我会专门讲怎么调。curl、mbstring、json、xml 这些都是跑主流电商框架比如 WooCommerce 或自研商城的老搭档缺一个往往会出现诡异的函数不存在报错。装完之后的启动配置我建议直接修改 php-fpm 的池配置文件。SLES 上路径一般是 /etc/php7/fpm/pool.d/www.conf 或 /etc/php-fpm.d/www.conf根据不同包版本略有差异。启动 PHP-FPM 之前先确认它要监听的地址。生产环境我强烈推荐 unix socket因为回环地址虽然好记但每次请求都要走一次 TCP 协议栈多出来的开销在大流量下会被放大sudo systemctl enable --now php-fpm sudo ss -lx | grep php看到 php-fpm.sock 出现说明进程池已经跑起来。如果 socket 没出现大概率是你的 www.conf 里 listen 参数写错了或者日志目录没建好后者在 SLES 上还挺常见。2.3 第一个能跑通的测试站点环境装好后不要急着写一堆优化配置先做一个最小可用的站点。目标是验证 Nginx 和 PHP-FPM 之间的链路是通的再去做调优不然你后面优化了半天最后发现 502 是因为路径配错那就很浪费时间。我习惯在 /srv/www/shop 下面建目录结构如下/srv/www/shop/ public/ index.php logs/index.php 里放最简单的内容?php phpinfo();然后写一个最基本的 server 配置确保 PHP 请求能通过 unix socket 交到 PHP-FPMserver { listen 80; server_name shop.example.com; root /srv/www/shop/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php-fpm.sock; } }这里最关键的是 fastcgi_param SCRIPT_FILENAME。很多刚接触的人忘了把它从默认的 /scripts 改过来结果访问任何 PHP 页面都返回 404 或者 “No input file specified”。当你用 $document_root$fastcgi_script_name 之后Nginx 会根据 server 的 root 去定位实际文件这条路我到现在还在用稳定得很。配置文件改完不要急着 reload先sudo nginx -t sudo systemctl reload nginx curl -I http://127.0.0.1/index.php看到 HTTP 200 且 Content-Type 是 text/html说明 Nginx 和 PHP-FPM 的链路没有问题。从这一步开始所有调优才真正有意义。3. Nginx 配置优化从“能用”到“好用”3.1 worker 进程和连接模型Nginx 的默认配置是 worker_processes 1这在开发桌面上一点问题没有但线上流量一上来立刻见底。它不代表 Nginx 只能处理单线程而是所有 worker 都挤在一个进程里CPU 多核完全浪费。我强烈建议设成 auto让 Nginx 按 CPU 核心数自动拉进程。如果你希望精确控制也可以手动指定核心数的一半或者全部这个要看机器上还有没有其他重负载服务。另一个容易踩坑的是 worker_rlimit_nofile。它决定了每个 worker 进程能打开的最大文件描述符数量默认值在低版本上只有 1024而一个高并发连接会占用多个 fd。如果你只调大 ulimit却忘记在 nginx.conf 里设置 worker_rlimit_nofile连接数量还是会卡在很低的水平。我把这几项放在一起看worker_processes auto; worker_rlimit_nofile 65536; events { worker_connections 4096; }worker_connections 与 worker_rlimit_nofile 的关系可以用一个简单乘法算单 worker 允许的并发连接数大约是 worker_connections同时受 fd 数量上限约束。按 4 核的机器算auto 会拉起 4 个 worker理论上并发连接上限是 4×4096。但如果你没有调大 fdworker_rlimit_nofile 卡在 1024那么每个 worker 最多也就撑 1024 个连接我一度遇到过连接数一上来就报 Too Many Open Files排查半天才发现是这里的问题。在实际项目里我一般不会把 worker_connections 拉到 10000 以上因为单进程的 fd 竞争会加剧反而带来调度开销。更合理的方向是保持 4096 到 8192同时确保 worker 数量足够。3.2 静态资源分离与 location 工作流电商站点里图片、CSS、JS 文件占了非常大的流量。如果这些请求也往 PHP-FPM 丢那纯属浪费 CPU。一个比较干净的思路是在 Nginx 里把静态资源拦截下来同时借助 location 的匹配规则实现分离。这里有必要把 Nginx 的 location 工作流理清因为很多配置看起来没问题实际匹配到的位置却不是你想要的。Nginx 处理 location 的顺序大致是这样的先精确匹配 location 命中直接用然后是普通前缀匹配按最长前缀记录如果这个最长前缀是 ^~ 开头就立即使用不再往下看接着按配置文件顺序测试正则 location第一个命中的正则胜出最后如果正则都没命中才用刚才记录的最长前缀。这个顺序直接决定了你的配置怎么写。我见过有人把图片分离写成location ~* \.(jpg|png|css|js)$ { expires 30d; }结果因为其他 location 里也有 try_files静态规则在后面永远匹配不到。正确做法是把静态资源匹配放在前面并且可以搭配 ^~ 或普通前缀来兜底。比如location ^~ /static/ { root /srv/www/shop; expires 7d; access_log off; } location ~* \.(?:css|js|png|jpg|jpeg|gif|ico|webp|woff2?)$ { root /srv/www/shop/public; expires 30d; access_log off; try_files $uri 404; }这里 ^~ 的含义是告诉 Nginx/static/ 前缀一旦匹配就直接用这个块不再去跑正则。而正则块专门处理散落在各个目录的图片和样式文件这类请求 30 天强缓存对于不经常变的资源非常有效。过期时间设多久要结合业务。电商的促销 banner 经常换如果你把图片缓存 30 天可能下个活动上线用户端还在拿旧图。我通常的做法是static/ 目录里按版本号存放资源目录级别缓存 7 天带 hash 的文件名缓存 30 天既兼顾性能又能及时刷新。3.3 代理缓冲、keepalive 和 gzipNginx 在把请求转发给 PHP-FPM 并接收返回内容时默认行为对突发流量并不友好。你需要关注的是 fastcgi_buffer 相关参数和 keepalive 连接复用。fastcgi_buffers 决定 Nginx 从 PHP-FPM 拿响应时用多大的内存 buffer。如果 buffer 太小Nginx 会把部分响应内容写到临时文件磁盘 I/O 一旦介入响应速度立刻下降一截。我在这类电商场景下的配置通常是fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; fastcgi_busy_buffers_size 64k; fastcgi_read_timeout 60s; fastcgi_send_timeout 60s;fastcgi_buffer_size 是响应头缓冲fastcgi_buffers 是响应体缓冲。当 PHP 返回一个几百 KB 的 HTML 页面时这套配置可以让大部分内容留在内存里不用频繁落盘。至于超时电商场景偶尔会有慢 SQL 导致的长时间请求60 秒是个比较平衡的值短了会 504长了容易拖住连接导致 PHP-FPM 池被占满。另一块容易被忽视的是 upstream keepalive。默认配置下每来一个请求Nginx 都要和 PHP-FPM 重建一次 socket 连接高并发下这本身就有开销。我在 http 块里加 upstream 配置upstream php_fpm_backend { server unix:/run/php-fpm.sock; keepalive 256; } server { ... location ~ \.php$ { fastcgi_pass php_fpm_backend; fastcgi_keep_conn on; } }fastcgi_keep_conn 需要配合 keepalive 使用否则 keepalive 生效不了。这是我调优过后 QPS 提升最明显的一项原因很简单省掉了大量 TCP 三次握手和四次挥手。gzip 的影响没有想象中大但依然值得开。我的经验是开启 gzip 压缩后HTML 和 CSS 响应体积能减少 60% 以上网络传输时间明显缩短代价是 CPU 会吃掉一点。这里要小心的不是 CPU而是别把图片也压缩一遍。绝大多数图片已经过压缩再压一次只会白白消耗 CPUgzip on; gzip_types text/plain text/css application/json application/javascript application/xml image/svgxml; gzip_min_length 1024; gzip_comp_level 5;3.4 fastcgi_cache 与动态页面缓存边界电商这个词容易让人误以为所有页面都必须实时动态生成。实际上首页、分类页、搜索结果这类流量大户页面的主体内容在几分钟内并没有变化。用 fastcgi_cache 把 PHP 生成的页面缓存住可以在不打磨业务代码的前提下大幅降低 PHP-FPM 的压力。我在 nginx.conf 的 http 块里声明缓存路径fastcgi_cache_path /var/cache/nginx levels1:2 keys_zonephpcache:128m inactive60m max_size2g;然后在 PHP location 里启用缓存并加上缓存标识。这里要特别小心有个人信息的页面购物车、用户中心不能进这个缓存因为不同用户的响应内容会被串掉。我的做法是用fastcgi_cache_key结合请求参数和 Cookie 来区分但更稳妥的方案是不对需要登录的路径启用缓存location ~ \.php$ { fastcgi_cache phpcache; fastcgi_cache_valid 200 301 302 60m; fastcgi_cache_key $request_method|$host|$request_uri; fastcgi_cache_bypass $cookie_session; fastcgi_no_cache $cookie_session; add_header X-Cache-Status $upstream_cache_status; }fastcgi_cache_bypass 和 fastcgi_no_cache 都是用来识别带 session cookie 的用户请求一旦命中条件就跳过缓存。X-Cache-Status 这个响应头在调试阶段特别有用能看到 HIT、MISS、BYPASS一眼判断缓存是否生效。我上线后靠这个头排查过很多“页面一直没变化”的反馈也靠它确认过压测时的缓存命中率。设置 fastcgi_cache_valid 60m 的意思是只对状态码为 200、301、302 的响应缓存 60 分钟。如果你做秒杀活动这个 60 分钟可能太长需要根据实际运营策略调短或者干脆在活动页禁用缓存。生产环境中缓存粒度越细分越不容易出事。4. PHP-FPM 调优进程池决定上限4.1 pm 模式选择static 还是 dynamicNginx 调得再好PHP-FPM 的进程池如果支撑不住一切白搭。PHP-FPM 有三种进程管理模式static、dynamic、ondemand。电商场景并发波动大我一般只用 static 或 dynamic很少用 ondemand因为 ondemand 在请求突发时临时拉进程过程本身就是延迟而且进程频繁创建销毁也会消耗 CPU。static 模式是固定进程数好处是响应时间稳定坏处是空闲时段资源浪费。dynamic 模式则允许在最小值和最大值之间浮动适合业务有明显的峰谷。我在 4 核 8G 的机器上做过对比同样的压测流量static 20 进程和 dynamic 峰值 20 进程的 QPS 差别很小但 static 的响应时间更平稳几乎看不到毛刺。如果你的服务器是专用给这个电商站点用的我建议直接用 staticpm static pm.max_children 30这里 max_children 的取值不是拍脑袋来的而是根据每个 PHP 进程的内存占用和机器总内存算出来的。这个计算我在下面单独说。如果你的环境是数据库、Redis、Web 共存一台机器用 dynamic 会更稳pm dynamic pm.max_children 50 pm.start_servers 10 pm.min_spare_servers 6 pm.max_spare_servers 20 pm.max_requests 1000pm.max_requests 对长期运行的应用很重要。它表示每个子进程处理完多少请求后主动退出让主进程重新拉起新进程。PHP 长生命周期下会有内存增长即使脚本本身没有明显泄漏累计到一定程度也会吃满内存。把它设为 1000 到 2000 之间能有效避免内存持续上涨。4.2 进程数与内存估算的计算方法我调优前第一件事是看单个 PHP-FPM 进程占多少内存。在生产环境用下面的命令采样ps -eo rss,comm | awk /php-fpm/ {sum$1; n} END {printf total%.0fMB avg%.0fMB n%d\n, sum/1024, sum/n/1024, n}假设每个 PHP 进程平均占用 80MB一台 8G 内存的机器上假设系统基础占用 2G、数据库和 Redis 再占 3G留给 PHP 的安全余量也就 2G 左右。那么合理进程数可以压到进程数 可用内存 / 单进程平均内存 2048MB / 80MB ≈ 25所以前面配置里 max_children 写成 30 已经算偏激进我实际线上会取 25宁可进程数少一点也不要让机器因为内存不足开始 swap。内存一旦 swap响应时间会瞬间暴涨比进程数略少的代价严重得多。有一些细节会让这个估算翻车比如 PHP 扩展不同单进程内存差异很大。装了 opcache 和 curl 的进程往往比裸 PHP 多占用几十 MB所以最稳妥的做法是在你的实际环境里跑一轮压测采集峰值内存再算。我在 SLES 上碰到过一次因为 opcache 的 memory_consumption 配了 256M结果每个 PHP 进程内存都比预期大 60MB 的情况后来把 opcache 内存降到 128M 才算恢复正常。max_children 调完后还可以顺手调一下pm.max_spare_servers的上下界比如最小空闲 6、最大空闲 20。这个区间越小进程数量越稳定但如果设置得太窄比如最小 5、最大 10一遇到突发流量就要频繁扩容可能造成等待。4.3 慢日志、状态页与 opcache 三件套排查 PHP 性能问题最直接的手段是开启慢日志。默认情况下PHP-FPM 会把所有执行时间超过指定阈值的请求记录到 slowlog 中这对定位那些“页面偶尔变慢”的请求太有用了。在 www.conf 里request_slowlog_timeout 5s slowlog /var/log/php-fpm-slow.log catch_workers_output yes开启之后一旦某个请求执行超过 5 秒慢日志里会打上调用栈直接指出是哪个函数、哪个文件拖慢了响应。我踩过的最典型场景是某个订单导出功能调用了外部接口外部接口偶尔要等 20 秒打开慢日志之后马上就能发现调用栈里的 file_get_contents后续改异步处理就顺理成章了。状态页是另一个利器。在 Nginx 配置里加一个专门 location指向 PHP-FPM 的状态接口location ~ ^/php-fpm-status$ { fastcgi_pass unix:/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME /srv/www/shop/status.php; include fastcgi_params; }然后在 www.conf 里打开 pm.status_pathpm.status_path /php-fpm-status访问这个页面可以看到当前 active connections、max children 等指标。我通常用它配合监控系统一旦 idle 进程数降到接近 0就说明进程池正在被打满需要立刻扩容或者排查慢请求。最后是 opcache。PHP 的 opcache 本身是官方的字节码缓存扩展打开之后能避免每个请求都重新编译 PHP 文件。电商平台代码文件非常多没有 opcache 时性能有近一半浪费在编译上。我常用的配置在 php.ini 中opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer16 opcache.max_accelerated_files20000 opcache.revalidate_freq60注意 revalidate_freq 设成 60意味着 60 秒内 PHP 文件如果被修改不会立刻生效。这在测试环境容易让人一头雾水改了代码页面却没变化。我个人的做法是测试环境把 revalidate_freq 设成 2生产环境保留 60兼顾性能和更新效率。5. 系统级兜底内核、文件句柄、防火墙5.1 内核参数让 TCP 连接能力跟上进程和 Nginx 配置调完后系统层面的 TCP 处理能力如果跟不上照样白搭。最明显的问题是连接队列溢出。高并发下新连接到达时如果 accept 队列满了内核会直接丢包客户端表现为连接建立超时。我通常会在 /etc/sysctl.conf 里加这几项net.core.somaxconn 65536 net.ipv4.tcp_max_syn_backlog 65536 net.ipv4.ip_local_port_range 1024 65535 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_tw_reuse 1 net.core.netdev_max_backlog 65536 fs.file-max 655350先解释这几个参数的作用。net.core.somaxconn 和 tcp_max_syn_backlog 决定了连接队列能容纳多少等待 accept 的连接如果队列太小Nginx 的处理速度一时跟不上新连接就会被内核丢掉。ip_local_port_range 影响的是出站连接的端口范围尤其是 PHP 进程连接 Redis、数据库时会占用本地端口范围太小会导致 “Cannot assign requested address”。tcp_tw_reuse 允许内核复用处于 TIME_WAIT 状态的连接配合 tcp_fin_timeout 30 秒能明显减少 TIME_WAIT 堆积。一个要特别强调的坑tcp_tw_recycle 这个参数在早期内核里和 NAT 环境有严重兼容问题容易导致一部分用户连接异常新版内核里已经废弃了。我在很多老教程里看到有人还在推荐开它千万不要照做。只开 tcp_tw_reuse 就足够了。5.2 systemd 句柄限制与进程上限有时候你把系统 ulimit 调大了Nginx 仍然报 too many open files原因就是 systemd 启动的进程默认继承的是 systemd 里的限制而不是 shell 里的 ulimit。SLES 15 的 systemd 服务默认对文件句柄有单独限制必须单独覆盖。我习惯在 /etc/systemd/system/nginx.service.d/limits.conf 里写[Service] LimitNOFILE65536 LimitNPROC65536同样给 php-fpm 也建一个目录覆盖sudo mkdir -p /etc/systemd/system/php-fpm.service.d然后写入同样的 LimitNOFILE。改完别忘记sudo systemctl daemon-reload sudo systemctl restart nginx php-fpm这个细节如果不处理后面压测一到高并发就报句柄不够非常容易和 Nginx 配置问题混淆。另外也要检查一下 php-fpm 的listen.backlog它对应的是 unix socket 的连接队列; www.conf listen.backlog 65535调大 backlog 后即使瞬时请求非常多socket 层也不会轻易丢连接。5.3 压测验证ab / wrk 前后对比所有参数都改完之后不要直接看业务感受先用压测工具拿数据。ab 是 ApacheBench胜在简单wrk 胜在能模拟更高并发我一般两个都用。wrk 在 SLES 15 上没有官方包可以直接源码编译也可以找第三方仓库这里演示用它跑一轮测试wrk -t4 -c400 -d60s http://127.0.0.1/这里的 -t4 表示 4 个线程-c400 表示 400 个并发连接-d60s 表示持续 60 秒。压测过程中我会同时用top和ss -s观察 CPU、内存和 socket 状态的走势。我在一台 4C8G 的测试机上拿没有调优的最初配置和调优后的配置做过对比优化主要包括Nginx worker 调整、静态分离、fastcgi buffer 与 keepalive、PHP-FPM static 30 进程、内核参数。结果大致如下指标优化前优化后QPS约 1300约 4200P95 响应时间780ms220ms错误率2.3%0.1%PHP-FPM 队列等待频繁出现基本消失看到这个结果不要直接拿数字套自己的机器想表达的是默认配置和优化配置之间的差距非常大。压测完如果 QPS 提高但错误率也提高说明某个配置卡得太死需要降一些并发再观察。压测过程也是排查配置问题的过程多跑几轮比一次跑完更容易定位到具体是哪个参数在捣乱。6. 常见问题与排查实录6.1 502、504 到底谁在拖后腿502 Bad Gateway 和 504 Gateway Timeout 是大流量场景下最常见的两张脸。502 的语义是 Nginx 从 PHP-FPM 拿不到有效响应最常见的几个原因PHP-FPM 没启动、unix socket 路径不一致、socket 文件权限不对、PHP-FPM 进程池崩了。我在 SLES 上遇到最多的是权限问题因为 php-fpm 默认以 php-fpm 用户跑而 Nginx worker 也可能以 nginx 用户跑两者对 socket 文件的读写权限必须对得上。查看 socket 权限ls -l /run/php-fpm.sock如果发现 socket 的属主和 Nginx worker 的用户不一致就会导致 502。解决办法是找到一个两边都能读写的用户或者在 www.conf 里把 listen.owner 和 listen.group 设成 nginx 的用户listen.owner nginx listen.group nginx listen.mode 0660504 则一般是超时。fastcgi_read_timeout 设得太短或者某个 PHP 请求本身执行时间太长。这种情况下我会先看 php-fpm 慢日志如果没有慢日志再用strace去跟一次请求看看卡在哪个系统调用上。印象很深的一次是某个接口在等 Redis 连接池而 Redis 连接池已经满了从 Nginx 层面看就是 504实际瓶颈却在 Redis 客户端上所以排查不能只看 Nginx 和 PHP-FPM。6.2 TIME_WAIT 与连接超限压测时如果发现ss -s里 TIME_WAIT 数量达到好几万通常意味着连接被频繁建立和关闭。Nginx 和 PHP-FPM 之间如果没启用 keepalive每一次请求都会产生断开连接断开的一方就会留下 TIME_WAIT。开启 fastcgi_keep_conn 后这种现象会好很多。如果是客户端主动断开导致的 TIME_WAIT比如移动端 App 频繁轮询接口可以在内核层面通过 tcp_tw_reuse 和调低 tcp_fin_timeout 来缓解但不要指望它能完全消灭 TIME_WAIT。TIME_WAIT 本身是可靠传输的一部分大量堆积只是内存和端口的短期占用问题端口范围调大了之后一般不致命。连接数超限时报错通常出现在两个地方。一个是 Nginx 错误日志里出现 worker_connections are not enough解决方向是调大 worker_connections 或 worker_rlimit_nofile另一个是应用层报数据库连接获取失败这说明 PHP-FPM 进程已经把数据库连接池吃满此时单纯调 Nginx 没用要去看数据库连接数和 PHP-FPM 的 max_children。6.3 日志与慢日志配合定位最后想说的是所有调优手段都离不开日志。Nginx 的 access log 我会开启一个带响应时间的自定义格式log_format perf $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent rt$request_time;这样每次请求的耗时都直接记录在日志里线上出现响应慢的情况时只需要tail -f /var/log/nginx/access.log | awk $NF ~ /rt.*/ {split($NF,a,); if(a[2]0 2) print}就能把耗时超过 2 秒的请求全部筛出来。再拿这些请求对应的时间点去翻 php-fpm 慢日志几乎百试百灵。我平时排障的顺序是先看 access log 响应时间是不是普遍上升再看 PHP-FPM 状态页里的 idle 进程数和队列等待接着看慢日志有没有可疑调用栈最后才动配置。盲改参数是最浪费时间的方式日志定位再调整一次就能命中问题。7. 写在最后的实战体会这套从 SLES 15 安装 Nginx 与 PHP-FPM 开始到内核参数收尾的优化流程我在不同项目里重复过很多次。每次复用的过程中我都会对参数做微调因为每台机器的 CPU、内存、业务代码都不一样没有一套配置能通吃所有场景。如果有人让我只留一条经验那就是先量化再调优最后用压测数据验证别相信“感觉变快了”这种模糊评价。我自己的习惯是每次优化完都留一份优化前后的压测报告既方便复盘也给后续接手的人留下参考。再分享一个小技巧所有配置文件在变更后都养成 nginx -t 和 php-fpm -t 先检查的做法。SLES 上路径和 CentOS、Ubuntu 都有差异一条拼错的路径就能让整个服务起不来。配置文件管理我建议纳入 Git 仓库避免上线前一天发现“我也不知道谁改过配置”的尴尬。把这个流程稳定下来再大的流量你也会心里有底。
电商大促那几天最怕的往往不是业务代码出 Bug而是服务器在流量冲上来之后突然从 500 毫秒变成 3 秒紧接着后台飘红一片 502。如果你手里跑的是 SUSE Linux Enterprise Server 15应用栈又是经典的 Nginx PHP-FPM那么这篇文章就是冲着你来的怎么把这套组合从“能跑”调到“扛得住”在保持响应速度的前提下尽量不让 PHP 拖后腿也不让 Nginx 变成瓶颈。我操作过的线上环境里这套配置从默认值到最终优化完成压测 QPS 大概能翻三倍左右P95 响应时间也能稳稳降下来。下面我会按实际部署的顺序拆开讲每个参数为什么这么调、调了有多大影响、踩过什么坑尽量讲透方便你对照自己的服务器直接抄作业。1. 先想清楚调优到底调的是什么1.1 大流量下电商应用的真实瓶颈电商类的 PHP 应用有一个很典型的特征动态请求占比高而且每个请求背后往往连着数据库、Redis、外部接口业务代码本身就可能吃掉几十毫秒到几百毫秒。这个时候压垮系统的通常是两个点一是 PHP-FPM 进程池耗尽新请求进来直接排队二是 Nginx 和 PHP-FPM 之间衔接不当代理缓冲、超时、连接复用等参数不合理导致请求在中间层空等。很多人一上来就调内核参数、开 gzip但真正的大头反而在进程池和 upstream 连接的配置上。还要注意一个容易被忽略的事实Nginx 处理静态文件的能力极强绝大多数时候瓶颈不在 Nginx 的 I/O 上而在 PHP 侧的并发能力。所以调优的第一步不是盲目堆高 worker_processes而是先搞清楚请求链路里哪一段是短板。我在压测时发现默认配置下 PHP-FPM 的 max_children 只有 16 左右一旦并发超过这个数队列堆积响应时间会呈指数恶化而这种恶化经常被误认为“带宽不够”或“数据库慢”。1.2 SLES 15 这套组合的特别之处SLES 15 是 SUSE 面向企业服务器的发行版包管理的默认行为和 CentOS、Debian 都有差异踩坑点全在细节上。第一官方仓库里 PHP 相关包的版本取决于你当前激活的 Service Pack有的 SP 版本默认给的是 PHP 7老一些的环境还在用 PHP 5 的残留配置需要特别留意。第二SLES 15 默认不会帮你把 nginx.org 的仓库加进来你要么手动添加仓库要么用 SUSE 自家仓库里的版本后者版本可能比上游慢半拍。第三SLES 默认环境里强制访问控制的安全策略需要放行否则 Nginx 的 unix socket 或 PHP-FPM 的日志目录可能被静默拦掉。这些差异意味着网上大量针对 Ubuntu 的教程不能直接照搬比如直接用 apt install nginx 在 SLES 上根本不存在。我个人倒是更喜欢用 nginx.org 官方仓库的方式版本可控而且和上游配置文件的习惯完全一致。至于 PHP-FPM最好通过 SUSE PackageHub 安装因为官方主仓库里 php-fpm 这个包不一定默认启用漏掉这一步后面会少很多可用模块。1.3 性能目标怎么定义调优前先给自己定一个可量化的目标不然你会陷入“调了又调但不知道有没有效果”的泥潭。我的做法是两阶段设定第一阶段压测目标用 ab 或 wrk 在固定并发比如 200、400、800下测试观察 QPS 和错误率第二阶段业务目标压测得到的 P95 响应时间要比优化前低至少 30%错误率低于 0.5%。注意不要只盯着 QPS一个高的 QPS 如果伴随大量超时说明服务器的承受能力是虚假的。我建议在你的压测环境里至少准备一台和线上同规格的机器很多参数优化效果在低配机器上非常不明显比如 worker_processes 从 auto 改成手动指定后4 核机器和 16 核机器的行为完全不一样。目标定清楚之后下一步才是动手装环境。2. 环境准备与基础部署2.1 在 SLES 15 上装 Nginx 的两种路径SLES 15 上装 Nginx 有两条主流路径。第一条是用 zypper 直接安装系统仓库里的版本好处是命令简单依赖问题少坏处是版本相对保守而且部分优化模块可能没编进去。我自己的生产环境更推荐第二条添加 nginx.org 官方仓库保持和上游同步配置文件结构也更干净。具体命令大概是# 导入签名 sudo rpm --import https://nginx.org/keys/nginx_signing.key # 添加 nginx 官方 SLES 15 仓库 sudo zypper addrepo --gpgcheck-auto-import yes \ https://nginx.org/packages/sles/15/ nginx-repo # 安装 sudo zypper install nginx安装完不要急着启动先检查一下版本和编译参数nginx -V你会看到 configure arguments 那一大串这里要重点关注有没有 --with-http_stub_status_module。现在 nginx 官方包默认通常是带上的但如果你用的是发行版自带包建议确认一下后面要拿状态页做监控时全靠它。如果确实没有不少人在 SLES 上会走源码编译自己加 --with-http_stub_status_module 和 --with-http_slice_module相对麻烦一些但可控性高。启动服务前我习惯先把 nginx 的默认站点注释掉免得后面测试时 80 端口上的欢迎页干扰判断sudo systemctl enable --now nginx sudo curl -I http://127.0.0.1/一旦看到 nginx 默认页面的响应头就说明基础服务已经起跑。2.2 PHP-FPM 的安装与扩展选型PHP-FPM 在 SLES 15 上的安装路径稍微曲折一点。如果你直接 zypper install php7-fpm可能提示找不到包这种情况十有八九是 PackageHub 仓库没激活。SLES 15 的服务包管理和系统包管理是分开的PackageHub 需要先用 SUSEConnect 激活sudo SUSEConnect -p PackageHub/15.5/x86_64 sudo zypper install php7 php7-fpm php7-opcache php7-mysql php7-curl \ php7-json php7-xml php7-mbstring php7-gd php7-bcmath如果你的 SLES 是 SP3 或更高版本可能已经拿到 PHP 8 的包版本号换成 php8 前缀即可。需要什么扩展取决于电商平台的技术栈但 opcache 一定要装这是 PHP 响应能力提升性价比最高的一块后面我会专门讲怎么调。curl、mbstring、json、xml 这些都是跑主流电商框架比如 WooCommerce 或自研商城的老搭档缺一个往往会出现诡异的函数不存在报错。装完之后的启动配置我建议直接修改 php-fpm 的池配置文件。SLES 上路径一般是 /etc/php7/fpm/pool.d/www.conf 或 /etc/php-fpm.d/www.conf根据不同包版本略有差异。启动 PHP-FPM 之前先确认它要监听的地址。生产环境我强烈推荐 unix socket因为回环地址虽然好记但每次请求都要走一次 TCP 协议栈多出来的开销在大流量下会被放大sudo systemctl enable --now php-fpm sudo ss -lx | grep php看到 php-fpm.sock 出现说明进程池已经跑起来。如果 socket 没出现大概率是你的 www.conf 里 listen 参数写错了或者日志目录没建好后者在 SLES 上还挺常见。2.3 第一个能跑通的测试站点环境装好后不要急着写一堆优化配置先做一个最小可用的站点。目标是验证 Nginx 和 PHP-FPM 之间的链路是通的再去做调优不然你后面优化了半天最后发现 502 是因为路径配错那就很浪费时间。我习惯在 /srv/www/shop 下面建目录结构如下/srv/www/shop/ public/ index.php logs/index.php 里放最简单的内容?php phpinfo();然后写一个最基本的 server 配置确保 PHP 请求能通过 unix socket 交到 PHP-FPMserver { listen 80; server_name shop.example.com; root /srv/www/shop/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php-fpm.sock; } }这里最关键的是 fastcgi_param SCRIPT_FILENAME。很多刚接触的人忘了把它从默认的 /scripts 改过来结果访问任何 PHP 页面都返回 404 或者 “No input file specified”。当你用 $document_root$fastcgi_script_name 之后Nginx 会根据 server 的 root 去定位实际文件这条路我到现在还在用稳定得很。配置文件改完不要急着 reload先sudo nginx -t sudo systemctl reload nginx curl -I http://127.0.0.1/index.php看到 HTTP 200 且 Content-Type 是 text/html说明 Nginx 和 PHP-FPM 的链路没有问题。从这一步开始所有调优才真正有意义。3. Nginx 配置优化从“能用”到“好用”3.1 worker 进程和连接模型Nginx 的默认配置是 worker_processes 1这在开发桌面上一点问题没有但线上流量一上来立刻见底。它不代表 Nginx 只能处理单线程而是所有 worker 都挤在一个进程里CPU 多核完全浪费。我强烈建议设成 auto让 Nginx 按 CPU 核心数自动拉进程。如果你希望精确控制也可以手动指定核心数的一半或者全部这个要看机器上还有没有其他重负载服务。另一个容易踩坑的是 worker_rlimit_nofile。它决定了每个 worker 进程能打开的最大文件描述符数量默认值在低版本上只有 1024而一个高并发连接会占用多个 fd。如果你只调大 ulimit却忘记在 nginx.conf 里设置 worker_rlimit_nofile连接数量还是会卡在很低的水平。我把这几项放在一起看worker_processes auto; worker_rlimit_nofile 65536; events { worker_connections 4096; }worker_connections 与 worker_rlimit_nofile 的关系可以用一个简单乘法算单 worker 允许的并发连接数大约是 worker_connections同时受 fd 数量上限约束。按 4 核的机器算auto 会拉起 4 个 worker理论上并发连接上限是 4×4096。但如果你没有调大 fdworker_rlimit_nofile 卡在 1024那么每个 worker 最多也就撑 1024 个连接我一度遇到过连接数一上来就报 Too Many Open Files排查半天才发现是这里的问题。在实际项目里我一般不会把 worker_connections 拉到 10000 以上因为单进程的 fd 竞争会加剧反而带来调度开销。更合理的方向是保持 4096 到 8192同时确保 worker 数量足够。3.2 静态资源分离与 location 工作流电商站点里图片、CSS、JS 文件占了非常大的流量。如果这些请求也往 PHP-FPM 丢那纯属浪费 CPU。一个比较干净的思路是在 Nginx 里把静态资源拦截下来同时借助 location 的匹配规则实现分离。这里有必要把 Nginx 的 location 工作流理清因为很多配置看起来没问题实际匹配到的位置却不是你想要的。Nginx 处理 location 的顺序大致是这样的先精确匹配 location 命中直接用然后是普通前缀匹配按最长前缀记录如果这个最长前缀是 ^~ 开头就立即使用不再往下看接着按配置文件顺序测试正则 location第一个命中的正则胜出最后如果正则都没命中才用刚才记录的最长前缀。这个顺序直接决定了你的配置怎么写。我见过有人把图片分离写成location ~* \.(jpg|png|css|js)$ { expires 30d; }结果因为其他 location 里也有 try_files静态规则在后面永远匹配不到。正确做法是把静态资源匹配放在前面并且可以搭配 ^~ 或普通前缀来兜底。比如location ^~ /static/ { root /srv/www/shop; expires 7d; access_log off; } location ~* \.(?:css|js|png|jpg|jpeg|gif|ico|webp|woff2?)$ { root /srv/www/shop/public; expires 30d; access_log off; try_files $uri 404; }这里 ^~ 的含义是告诉 Nginx/static/ 前缀一旦匹配就直接用这个块不再去跑正则。而正则块专门处理散落在各个目录的图片和样式文件这类请求 30 天强缓存对于不经常变的资源非常有效。过期时间设多久要结合业务。电商的促销 banner 经常换如果你把图片缓存 30 天可能下个活动上线用户端还在拿旧图。我通常的做法是static/ 目录里按版本号存放资源目录级别缓存 7 天带 hash 的文件名缓存 30 天既兼顾性能又能及时刷新。3.3 代理缓冲、keepalive 和 gzipNginx 在把请求转发给 PHP-FPM 并接收返回内容时默认行为对突发流量并不友好。你需要关注的是 fastcgi_buffer 相关参数和 keepalive 连接复用。fastcgi_buffers 决定 Nginx 从 PHP-FPM 拿响应时用多大的内存 buffer。如果 buffer 太小Nginx 会把部分响应内容写到临时文件磁盘 I/O 一旦介入响应速度立刻下降一截。我在这类电商场景下的配置通常是fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; fastcgi_busy_buffers_size 64k; fastcgi_read_timeout 60s; fastcgi_send_timeout 60s;fastcgi_buffer_size 是响应头缓冲fastcgi_buffers 是响应体缓冲。当 PHP 返回一个几百 KB 的 HTML 页面时这套配置可以让大部分内容留在内存里不用频繁落盘。至于超时电商场景偶尔会有慢 SQL 导致的长时间请求60 秒是个比较平衡的值短了会 504长了容易拖住连接导致 PHP-FPM 池被占满。另一块容易被忽视的是 upstream keepalive。默认配置下每来一个请求Nginx 都要和 PHP-FPM 重建一次 socket 连接高并发下这本身就有开销。我在 http 块里加 upstream 配置upstream php_fpm_backend { server unix:/run/php-fpm.sock; keepalive 256; } server { ... location ~ \.php$ { fastcgi_pass php_fpm_backend; fastcgi_keep_conn on; } }fastcgi_keep_conn 需要配合 keepalive 使用否则 keepalive 生效不了。这是我调优过后 QPS 提升最明显的一项原因很简单省掉了大量 TCP 三次握手和四次挥手。gzip 的影响没有想象中大但依然值得开。我的经验是开启 gzip 压缩后HTML 和 CSS 响应体积能减少 60% 以上网络传输时间明显缩短代价是 CPU 会吃掉一点。这里要小心的不是 CPU而是别把图片也压缩一遍。绝大多数图片已经过压缩再压一次只会白白消耗 CPUgzip on; gzip_types text/plain text/css application/json application/javascript application/xml image/svgxml; gzip_min_length 1024; gzip_comp_level 5;3.4 fastcgi_cache 与动态页面缓存边界电商这个词容易让人误以为所有页面都必须实时动态生成。实际上首页、分类页、搜索结果这类流量大户页面的主体内容在几分钟内并没有变化。用 fastcgi_cache 把 PHP 生成的页面缓存住可以在不打磨业务代码的前提下大幅降低 PHP-FPM 的压力。我在 nginx.conf 的 http 块里声明缓存路径fastcgi_cache_path /var/cache/nginx levels1:2 keys_zonephpcache:128m inactive60m max_size2g;然后在 PHP location 里启用缓存并加上缓存标识。这里要特别小心有个人信息的页面购物车、用户中心不能进这个缓存因为不同用户的响应内容会被串掉。我的做法是用fastcgi_cache_key结合请求参数和 Cookie 来区分但更稳妥的方案是不对需要登录的路径启用缓存location ~ \.php$ { fastcgi_cache phpcache; fastcgi_cache_valid 200 301 302 60m; fastcgi_cache_key $request_method|$host|$request_uri; fastcgi_cache_bypass $cookie_session; fastcgi_no_cache $cookie_session; add_header X-Cache-Status $upstream_cache_status; }fastcgi_cache_bypass 和 fastcgi_no_cache 都是用来识别带 session cookie 的用户请求一旦命中条件就跳过缓存。X-Cache-Status 这个响应头在调试阶段特别有用能看到 HIT、MISS、BYPASS一眼判断缓存是否生效。我上线后靠这个头排查过很多“页面一直没变化”的反馈也靠它确认过压测时的缓存命中率。设置 fastcgi_cache_valid 60m 的意思是只对状态码为 200、301、302 的响应缓存 60 分钟。如果你做秒杀活动这个 60 分钟可能太长需要根据实际运营策略调短或者干脆在活动页禁用缓存。生产环境中缓存粒度越细分越不容易出事。4. PHP-FPM 调优进程池决定上限4.1 pm 模式选择static 还是 dynamicNginx 调得再好PHP-FPM 的进程池如果支撑不住一切白搭。PHP-FPM 有三种进程管理模式static、dynamic、ondemand。电商场景并发波动大我一般只用 static 或 dynamic很少用 ondemand因为 ondemand 在请求突发时临时拉进程过程本身就是延迟而且进程频繁创建销毁也会消耗 CPU。static 模式是固定进程数好处是响应时间稳定坏处是空闲时段资源浪费。dynamic 模式则允许在最小值和最大值之间浮动适合业务有明显的峰谷。我在 4 核 8G 的机器上做过对比同样的压测流量static 20 进程和 dynamic 峰值 20 进程的 QPS 差别很小但 static 的响应时间更平稳几乎看不到毛刺。如果你的服务器是专用给这个电商站点用的我建议直接用 staticpm static pm.max_children 30这里 max_children 的取值不是拍脑袋来的而是根据每个 PHP 进程的内存占用和机器总内存算出来的。这个计算我在下面单独说。如果你的环境是数据库、Redis、Web 共存一台机器用 dynamic 会更稳pm dynamic pm.max_children 50 pm.start_servers 10 pm.min_spare_servers 6 pm.max_spare_servers 20 pm.max_requests 1000pm.max_requests 对长期运行的应用很重要。它表示每个子进程处理完多少请求后主动退出让主进程重新拉起新进程。PHP 长生命周期下会有内存增长即使脚本本身没有明显泄漏累计到一定程度也会吃满内存。把它设为 1000 到 2000 之间能有效避免内存持续上涨。4.2 进程数与内存估算的计算方法我调优前第一件事是看单个 PHP-FPM 进程占多少内存。在生产环境用下面的命令采样ps -eo rss,comm | awk /php-fpm/ {sum$1; n} END {printf total%.0fMB avg%.0fMB n%d\n, sum/1024, sum/n/1024, n}假设每个 PHP 进程平均占用 80MB一台 8G 内存的机器上假设系统基础占用 2G、数据库和 Redis 再占 3G留给 PHP 的安全余量也就 2G 左右。那么合理进程数可以压到进程数 可用内存 / 单进程平均内存 2048MB / 80MB ≈ 25所以前面配置里 max_children 写成 30 已经算偏激进我实际线上会取 25宁可进程数少一点也不要让机器因为内存不足开始 swap。内存一旦 swap响应时间会瞬间暴涨比进程数略少的代价严重得多。有一些细节会让这个估算翻车比如 PHP 扩展不同单进程内存差异很大。装了 opcache 和 curl 的进程往往比裸 PHP 多占用几十 MB所以最稳妥的做法是在你的实际环境里跑一轮压测采集峰值内存再算。我在 SLES 上碰到过一次因为 opcache 的 memory_consumption 配了 256M结果每个 PHP 进程内存都比预期大 60MB 的情况后来把 opcache 内存降到 128M 才算恢复正常。max_children 调完后还可以顺手调一下pm.max_spare_servers的上下界比如最小空闲 6、最大空闲 20。这个区间越小进程数量越稳定但如果设置得太窄比如最小 5、最大 10一遇到突发流量就要频繁扩容可能造成等待。4.3 慢日志、状态页与 opcache 三件套排查 PHP 性能问题最直接的手段是开启慢日志。默认情况下PHP-FPM 会把所有执行时间超过指定阈值的请求记录到 slowlog 中这对定位那些“页面偶尔变慢”的请求太有用了。在 www.conf 里request_slowlog_timeout 5s slowlog /var/log/php-fpm-slow.log catch_workers_output yes开启之后一旦某个请求执行超过 5 秒慢日志里会打上调用栈直接指出是哪个函数、哪个文件拖慢了响应。我踩过的最典型场景是某个订单导出功能调用了外部接口外部接口偶尔要等 20 秒打开慢日志之后马上就能发现调用栈里的 file_get_contents后续改异步处理就顺理成章了。状态页是另一个利器。在 Nginx 配置里加一个专门 location指向 PHP-FPM 的状态接口location ~ ^/php-fpm-status$ { fastcgi_pass unix:/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME /srv/www/shop/status.php; include fastcgi_params; }然后在 www.conf 里打开 pm.status_pathpm.status_path /php-fpm-status访问这个页面可以看到当前 active connections、max children 等指标。我通常用它配合监控系统一旦 idle 进程数降到接近 0就说明进程池正在被打满需要立刻扩容或者排查慢请求。最后是 opcache。PHP 的 opcache 本身是官方的字节码缓存扩展打开之后能避免每个请求都重新编译 PHP 文件。电商平台代码文件非常多没有 opcache 时性能有近一半浪费在编译上。我常用的配置在 php.ini 中opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer16 opcache.max_accelerated_files20000 opcache.revalidate_freq60注意 revalidate_freq 设成 60意味着 60 秒内 PHP 文件如果被修改不会立刻生效。这在测试环境容易让人一头雾水改了代码页面却没变化。我个人的做法是测试环境把 revalidate_freq 设成 2生产环境保留 60兼顾性能和更新效率。5. 系统级兜底内核、文件句柄、防火墙5.1 内核参数让 TCP 连接能力跟上进程和 Nginx 配置调完后系统层面的 TCP 处理能力如果跟不上照样白搭。最明显的问题是连接队列溢出。高并发下新连接到达时如果 accept 队列满了内核会直接丢包客户端表现为连接建立超时。我通常会在 /etc/sysctl.conf 里加这几项net.core.somaxconn 65536 net.ipv4.tcp_max_syn_backlog 65536 net.ipv4.ip_local_port_range 1024 65535 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_tw_reuse 1 net.core.netdev_max_backlog 65536 fs.file-max 655350先解释这几个参数的作用。net.core.somaxconn 和 tcp_max_syn_backlog 决定了连接队列能容纳多少等待 accept 的连接如果队列太小Nginx 的处理速度一时跟不上新连接就会被内核丢掉。ip_local_port_range 影响的是出站连接的端口范围尤其是 PHP 进程连接 Redis、数据库时会占用本地端口范围太小会导致 “Cannot assign requested address”。tcp_tw_reuse 允许内核复用处于 TIME_WAIT 状态的连接配合 tcp_fin_timeout 30 秒能明显减少 TIME_WAIT 堆积。一个要特别强调的坑tcp_tw_recycle 这个参数在早期内核里和 NAT 环境有严重兼容问题容易导致一部分用户连接异常新版内核里已经废弃了。我在很多老教程里看到有人还在推荐开它千万不要照做。只开 tcp_tw_reuse 就足够了。5.2 systemd 句柄限制与进程上限有时候你把系统 ulimit 调大了Nginx 仍然报 too many open files原因就是 systemd 启动的进程默认继承的是 systemd 里的限制而不是 shell 里的 ulimit。SLES 15 的 systemd 服务默认对文件句柄有单独限制必须单独覆盖。我习惯在 /etc/systemd/system/nginx.service.d/limits.conf 里写[Service] LimitNOFILE65536 LimitNPROC65536同样给 php-fpm 也建一个目录覆盖sudo mkdir -p /etc/systemd/system/php-fpm.service.d然后写入同样的 LimitNOFILE。改完别忘记sudo systemctl daemon-reload sudo systemctl restart nginx php-fpm这个细节如果不处理后面压测一到高并发就报句柄不够非常容易和 Nginx 配置问题混淆。另外也要检查一下 php-fpm 的listen.backlog它对应的是 unix socket 的连接队列; www.conf listen.backlog 65535调大 backlog 后即使瞬时请求非常多socket 层也不会轻易丢连接。5.3 压测验证ab / wrk 前后对比所有参数都改完之后不要直接看业务感受先用压测工具拿数据。ab 是 ApacheBench胜在简单wrk 胜在能模拟更高并发我一般两个都用。wrk 在 SLES 15 上没有官方包可以直接源码编译也可以找第三方仓库这里演示用它跑一轮测试wrk -t4 -c400 -d60s http://127.0.0.1/这里的 -t4 表示 4 个线程-c400 表示 400 个并发连接-d60s 表示持续 60 秒。压测过程中我会同时用top和ss -s观察 CPU、内存和 socket 状态的走势。我在一台 4C8G 的测试机上拿没有调优的最初配置和调优后的配置做过对比优化主要包括Nginx worker 调整、静态分离、fastcgi buffer 与 keepalive、PHP-FPM static 30 进程、内核参数。结果大致如下指标优化前优化后QPS约 1300约 4200P95 响应时间780ms220ms错误率2.3%0.1%PHP-FPM 队列等待频繁出现基本消失看到这个结果不要直接拿数字套自己的机器想表达的是默认配置和优化配置之间的差距非常大。压测完如果 QPS 提高但错误率也提高说明某个配置卡得太死需要降一些并发再观察。压测过程也是排查配置问题的过程多跑几轮比一次跑完更容易定位到具体是哪个参数在捣乱。6. 常见问题与排查实录6.1 502、504 到底谁在拖后腿502 Bad Gateway 和 504 Gateway Timeout 是大流量场景下最常见的两张脸。502 的语义是 Nginx 从 PHP-FPM 拿不到有效响应最常见的几个原因PHP-FPM 没启动、unix socket 路径不一致、socket 文件权限不对、PHP-FPM 进程池崩了。我在 SLES 上遇到最多的是权限问题因为 php-fpm 默认以 php-fpm 用户跑而 Nginx worker 也可能以 nginx 用户跑两者对 socket 文件的读写权限必须对得上。查看 socket 权限ls -l /run/php-fpm.sock如果发现 socket 的属主和 Nginx worker 的用户不一致就会导致 502。解决办法是找到一个两边都能读写的用户或者在 www.conf 里把 listen.owner 和 listen.group 设成 nginx 的用户listen.owner nginx listen.group nginx listen.mode 0660504 则一般是超时。fastcgi_read_timeout 设得太短或者某个 PHP 请求本身执行时间太长。这种情况下我会先看 php-fpm 慢日志如果没有慢日志再用strace去跟一次请求看看卡在哪个系统调用上。印象很深的一次是某个接口在等 Redis 连接池而 Redis 连接池已经满了从 Nginx 层面看就是 504实际瓶颈却在 Redis 客户端上所以排查不能只看 Nginx 和 PHP-FPM。6.2 TIME_WAIT 与连接超限压测时如果发现ss -s里 TIME_WAIT 数量达到好几万通常意味着连接被频繁建立和关闭。Nginx 和 PHP-FPM 之间如果没启用 keepalive每一次请求都会产生断开连接断开的一方就会留下 TIME_WAIT。开启 fastcgi_keep_conn 后这种现象会好很多。如果是客户端主动断开导致的 TIME_WAIT比如移动端 App 频繁轮询接口可以在内核层面通过 tcp_tw_reuse 和调低 tcp_fin_timeout 来缓解但不要指望它能完全消灭 TIME_WAIT。TIME_WAIT 本身是可靠传输的一部分大量堆积只是内存和端口的短期占用问题端口范围调大了之后一般不致命。连接数超限时报错通常出现在两个地方。一个是 Nginx 错误日志里出现 worker_connections are not enough解决方向是调大 worker_connections 或 worker_rlimit_nofile另一个是应用层报数据库连接获取失败这说明 PHP-FPM 进程已经把数据库连接池吃满此时单纯调 Nginx 没用要去看数据库连接数和 PHP-FPM 的 max_children。6.3 日志与慢日志配合定位最后想说的是所有调优手段都离不开日志。Nginx 的 access log 我会开启一个带响应时间的自定义格式log_format perf $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent rt$request_time;这样每次请求的耗时都直接记录在日志里线上出现响应慢的情况时只需要tail -f /var/log/nginx/access.log | awk $NF ~ /rt.*/ {split($NF,a,); if(a[2]0 2) print}就能把耗时超过 2 秒的请求全部筛出来。再拿这些请求对应的时间点去翻 php-fpm 慢日志几乎百试百灵。我平时排障的顺序是先看 access log 响应时间是不是普遍上升再看 PHP-FPM 状态页里的 idle 进程数和队列等待接着看慢日志有没有可疑调用栈最后才动配置。盲改参数是最浪费时间的方式日志定位再调整一次就能命中问题。7. 写在最后的实战体会这套从 SLES 15 安装 Nginx 与 PHP-FPM 开始到内核参数收尾的优化流程我在不同项目里重复过很多次。每次复用的过程中我都会对参数做微调因为每台机器的 CPU、内存、业务代码都不一样没有一套配置能通吃所有场景。如果有人让我只留一条经验那就是先量化再调优最后用压测数据验证别相信“感觉变快了”这种模糊评价。我自己的习惯是每次优化完都留一份优化前后的压测报告既方便复盘也给后续接手的人留下参考。再分享一个小技巧所有配置文件在变更后都养成 nginx -t 和 php-fpm -t 先检查的做法。SLES 上路径和 CentOS、Ubuntu 都有差异一条拼错的路径就能让整个服务起不来。配置文件管理我建议纳入 Git 仓库避免上线前一天发现“我也不知道谁改过配置”的尴尬。把这个流程稳定下来再大的流量你也会心里有底。
