Kubernetes中PHP-FPM与Nginx启动缓慢问题排查求助

可能的原因及对应修复方法 #

1. Symfony容器未预热，首次请求触发初始化 #

Init容器只做了缓存清除，但Symfony的服务容器是懒加载的，第一次请求时才会完成编译、服务实例化，直接导致延迟。

• 修复：在Init容器或PHP-FPM启动脚本里加预热命令：

  php bin/console cache:warmup --env=prod
  

  确保这个命令在PHP-FPM启动前执行，让容器在FPM就绪前就完成初始化，首次请求不用再编译。

2. PHP-FPM就绪探针配置不准 #

K8s的就绪探针如果只盯着端口或“ready to handle connections”日志，可能在FPM子进程还没加载完扩展、初始化好环境时就标记容器就绪。主进程启动不代表所有子进程都能处理请求。

• 修复：
  • 改用TCP探针直接检测FPM监听端口（默认9000）：

    readinessProbe:
      tcpSocket:
        port: 9000
      initialDelaySeconds: 5
      periodSeconds: 3
    

  • 或者用exec探针执行简单的PHP测试，确保能正常执行代码：

    readinessProbe:
      exec:
        command:
          - php
          - -r
          - 'echo "ok";'
      initialDelaySeconds: 5
      periodSeconds: 3
    

  • 要是有Symfony健康检查端点，也可以通过Nginx转发做HTTP探针：

    readinessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
    

    （注意要在Nginx配置里把/healthz路由指向对应的PHP脚本，确保能转发到FPM）

3. OPCache未预热 #

启用OPCache后，PHP脚本第一次加载才会编译缓存，首次请求必然慢。

• 修复：
  • 预热阶段加OPCache预加载操作，遍历项目PHP文件提前缓存：

    php bin/console cache:warmup --env=prod
    # 预加载所有PHP文件到OPCache
    find ./src ./vendor -name "*.php" -exec php -r 'include "{}";' \;
    

  • 同时在php.ini里配置正确的OPCache参数：

    opcache.enable=1
    opcache.enable_cli=1
    opcache.preload=/var/www/html/config/preload.php
    opcache.preload_user=www-data
    

    Symfony 4.4+自带预加载支持，可在config/packages/prod/opcache.yaml里配置预加载路径。

4. Nginx与PHP-FPM连接延迟 #

Nginx用fastcgi_pass连接FPM时，哪怕FPM端口监听了，子进程可能还没就绪，导致第一次请求超时。

• 修复：
  • 在Nginx配置里调整fastcgi超时参数，避免短时间内超时：

    location ~ \.php$ {
        fastcgi_pass php-fpm:9000;
        fastcgi_connect_timeout 10s;
        fastcgi_send_timeout 10s;
        fastcgi_read_timeout 10s;
        # 其他fastcgi配置项...
    }
    

  • 让Nginx的就绪探针依赖FPM的状态，比如延长Nginx探针的initialDelaySeconds，确保FPM完全就绪后再标记Nginx就绪。

5. 文件系统性能拖后腿 #

如果用PVC存项目文件，容器启动时文件可能还在从存储后端同步，导致PHP-FPM读文件慢。

• 修复：
  • 优先用本地存储或高性能SSD存储类；
  • 在Init容器里把项目文件复制到容器本地目录，不要直接挂载PVC到项目目录，减少运行时文件访问延迟；
  • 权限修改操作必须在Init容器里完成，别让PHP-FPM启动时还在处理文件权限。

额外优化点 #

• 根据预热时间调整PHP-FPM和Nginx就绪探针的initialDelaySeconds，别过早标记容器就绪；
• 滚动更新时，调整Deployment的maxSurge和maxUnavailable参数，确保旧Pod等新Pod完全就绪后再终止；
• 用php-fpm -status查看子进程状态，确认FPM启动后是否立刻有可用子进程处理请求。

内容的提问来源于stack exchange，提问作者Bronems