php7的配置文件,如何配置PHP7中的php.ini、php-fpm和www.conf文件

如何配置PHP7中的php.ini、php-fpm和www.conf文件

发布时间：2020-06-19 11:00:41

来源：亿速云

阅读：90

作者：Leah

配置PHP7的运行环境，核心就在于处理好三个关键配置文件：php.ini、php-fpm.conf以及www.conf。这听起来有点复杂？别担心，只要理解了每个文件的核心作用，配置起来其实有章可循。下面这份指南，就为你梳理了这三个文件的常用配置项及其背后的逻辑。

php.ini：PHP的核心引擎

作为PHP运行时的核心配置文件，php.ini决定了PHP解释器本身的行为。以下几个是关乎安全与性能的关键设置：

extension_dir = ""：这里需要设置PHP扩展库的存放路径。

expose_php = Off：强烈建议关闭。这能避免PHP的版本信息暴露在HTTP响应头中，减少被针对性攻击的风险。

display_errors = Off：在生产环境中务必关闭。它能防止PHP调用数据库等产生的具体错误信息直接显示给用户，避免泄露敏感数据。

log_errors = On：在关闭了display_errors后，必须开启此项。这样错误信息会被记录到日志中（日志路径通常在php-fpm.conf里配置），方便开发者排查问题。

zend_extension=opcache.so extension=mysqli.so extension=pdo_mysql.so：用于加载OPcache加速模块以及MySQL相关的扩展。

date.timezone = PRC：设置PHP使用的时区，例如“PRC”代表中国时区，确保时间函数返回正确结果。

opcache.enable=1：开启OPcache，这是提升PHP性能的利器，它能将预编译的脚本字节码缓存起来，减少重复编译的开销。

open_basedir = /usr/share/nginx/html;：这是一个重要的安全限制。它定义了PHP脚本可以访问的目录范围，能有效防止脚本越权访问系统文件。需要根据你项目的实际部署目录来配置。

php-fpm.conf与www.conf：进程管理器的控制台

php-fpm.conf是PHP-FPM服务的主配置文件，而www.conf（通常通过主配置中的include指令引入）则定义了具体的进程池设置。两者协同工作，管理着处理PHP请求的“工人”进程。

pid = run/php-fpm.pid：记录PHP-FPM主进程ID的文件路径，默认在安装目录的var/run/下，建议保持开启。

error_log = log/php-fpm.log：PHP-FPM自身的错误日志路径。

log_level = notice：定义日志记录的详细程度。可选级别从紧急到调试依次为：alert, error, warning, notice, debug。默认的notice级别通常够用。

emergency_restart_threshold = 60
emergency_restart_interval = 60s：这两个是“优雅重启”的守护者。意思是，如果在60秒内，出现段错误等严重问题的子进程数超过了60个，PHP-FPM就会自动重启。一般保持默认即可。

process_control_timeout = 0：设置子进程等待主进程信号的最大超时时间。

daemonize = yes：让PHP-FPM以守护进程（后台）模式运行。调试时可设为no，方便查看输出。

listen = 127.0.0.1:9000：这是关键！它定义了PHP-FPM监听的地址和端口，Nginx正是通过这个地址（例如FastCGI方式）将PHP请求转发过来。格式可以是IP:端口、端口或Unix Socket路径。

listen.backlog = -1：设置等待连接队列的长度，-1表示由操作系统决定，通常注释掉或保持默认。

listen.allowed_clients = 127.0.0.1：允许连接到此FastCGI进程的IP地址。如果想让其他服务器的Nginx也能连接，这里需要设置，或者改为“any”（不限制，需评估安全风险）。注意，如果listen设置为127.0.0.1，则只有本机可以访问。

listen.owner = www
listen.group = www
listen.mode = 0666：当使用Unix Socket方式监听时，这些选项用于设置Socket文件的属性和权限。如果使用TCP端口方式，则可以注释掉。

user = www
group = www：运行PHP-FPM子进程的系统用户和用户组。出于安全考虑，通常会使用一个非特权用户（如www、nginx）。

php-fpm 进程池优化方法

这部分配置直接关系到服务器的并发处理能力和稳定性，需要根据服务器硬件和业务量仔细调优。

pm = dynamic：子进程管理方式。对于专用服务器，资源稳定，也可以考虑设置为static。

那么，dynamic和static有什么区别？

如果选择static，进程数量是固定的，由pm.max_children直接指定。简单粗暴，但不够灵活。

如果选择dynamic，进程数会根据负载动态调整，涉及以下几个参数：

pm.max_children：进程池中允许创建的最大子进程数。在static模式下，它就是固定数量；在dynamic模式下，它是硬性上限。

pm.start_servers：服务启动时立即创建的进程数（仅dynamic模式有效）。

pm.min_spare_servers：保证空闲的最小进程数。当空闲进程少于这个数，管理器就会创建新的子进程。

pm.max_spare_servers：保证空闲的最大进程数。当空闲进程多于这个数，管理器就会清理掉多余的子进程。

这里有个关键点：pm.max_spare_servers的值必须小于等于pm.max_children。

如何设定这些值？一个PHP-FPM进程大约会占用20M-40M内存。所以，pm.max_children的设定，必须基于你的物理内存总量，并扣除掉系统、数据库等其他服务的内存占用后，再进行计算。例如，2GB内存的服务器，预留一部分后，大概可以设置为30-50个。

如果设置为dynamic，那么四个参数都会生效。系统启动时会创建pm.start_servers个进程，然后根据请求量，在pm.min_spare_servers和pm.max_spare_servers之间动态调整。要求pm.start_servers的值必须在最小和最大空闲进程数之间。

pm.max_requests = 1000：这是一个非常重要的配置。它规定每个子进程在处理完多少个请求后，就会自动重启。

为什么要重启？主要是为了应对可能存在的内存泄漏。无论是PHP自身还是某些第三方扩展，在长期运行后可能会缓慢地泄漏内存。定期重启进程可以释放这些内存，避免内存耗尽导致服务不稳定。设置为0则表示永不重启。

pm.status_path = /status：启用PHP-FPM状态页的访问路径。通过访问这个URL，可以查看进程池的详细运行状态，一些监控工具（如munin）会用到它。

ping.path = /ping
ping.response = pong：用于健康检查。外部监控可以通过访问/ping路径，如果返回“pong”，则证明PHP-FPM存活且能响应。

request_terminate_timeout = 0：设置单个请求的最大执行时间。这可以作为php.ini中max_execution_time的补充或后备。当经常出现502错误时，可以尝试将此值设置为一个合理的数值（如30s），以终止执行时间过长的脚本。

request_slowlog_timeout = 10s
slowlog = log/$pool.log.slow：慢日志配置。当一个请求的执行时间超过request_slowlog_timeout（例如10秒），其完整的PHP调用堆栈信息就会被记录到slowlog指定的文件中。这是定位性能瓶颈的“神器”。

rlimit_files = 1024：设置PHP-FPM进程可以打开的最大文件描述符数量。可以使用ulimit -n命令查看系统当前限制。

rlimit_core = 0：设置核心转储文件的大小限制。

chroot =：启动时的Chroot目录，用于将进程的文件系统根目录切换到指定路径，增强隔离性。

chdir =：设置进程启动后切换到的初始工作目录。

catch_workers_output = yes：将子进程的标准输出和错误输出重定向到主错误日志中。对调试有帮助。

clear_env = no：是否清理环境变量。

variables_order：该参数的详细解析，可以参考另一篇专门的文章。

常见错误及解决办法整理

在实际运维中，有几个配置项如果设置不当，很容易引发问题。

请求超时与502错误：request_terminate_timeout如果设置为0或过长，PHP脚本可能会无限执行。想象一下，如果所有php-fpm进程都卡在某个网络请求（如file_get_contents）或慢查询上，新的请求就无法被处理，Nginx就会返回“502 Bad Gateway”。治本的办法是给可能耗时的外部调用加上超时参数，同时将request_terminate_timeout设置为一个合理的值（如10-30秒），作为最后的防线。

间歇性502错误：这可能与pm.max_requests配置不当有关。这个配置的本意是好的——通过定期重启进程来预防内存泄漏。但如果设置得过小（比如100），在高并发下，进程会频繁重启。在重启的瞬间，该进程无法处理请求，如果同时有大量进程达到重启阈值，就可能导致瞬时服务能力下降，触发502错误。需要根据实际情况，将其调整为一个较大的值（例如1000或更高）。

慢日志：性能排查的利器：前面提到的request_slowlog_timeout和slowlog配置，是定位线上性能问题的关键。通过tail -f命令实时查看慢日志文件，你经常会发现一些规律：是某个外部API调用超时了？还是某条SQL查询没有用上索引？找到这些具体线索，优化方向就明确了。

说到底，配置的优化是一个持续的过程，需要结合监控数据、业务特性和服务器资源来不断调整。理解每个参数背后的含义，是做好这一切的基础。