Configuration PHP Paramètres de démarrage php-fpm et détails de configuration

Explication détaillée des paramètres de démarrage de php-fpm et des configurations importantes Il va sans dire que tous les étudiants effectuant du développement PHP doivent l'utiliser.

Convenir de plusieurs répertoires

/usr/local/php/sbin/php-fpm
/usr/local/php/etc/php-fpm.conf
/usr/ local/php/etc/php.ini
1. Paramètres de démarrage de php-fpm

Copier le code Le code est le suivant :

#测试php-fpm配置
/usr/local/php/sbin/php-fpm -t
/usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf -t

#启动php-fpm
/usr/local/php/sbin/php-fpm
/usr/local/php/sbin/php-fpm -c /usr/local/php/etc/php.ini -y /usr/local/php/etc/php-fpm.conf

#关闭php-fpm
kill -INT `cat /usr/local/php/var/run/php-fpm.pid`

#重启php-fpm
kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid`

Deuxièmement, explication détaillée des paramètres importants de php-fpm.conf

Copier le code Le code est le suivant :

pid = run/php-fpm.pid
#pid设置，默认在安装目录中的var/run/php-fpm.pid，建议开启

error_log = log/php-fpm.log
#错误日志，默认在安装目录中的var/log/php-fpm.log

log_level = notice
#错误级别. 可用级别为: alert（必须立即处理）, error（错误情况）, warning（警告情况）, notice（一般重要信息）, debug（调试信息）. 默认: notice.

emergency_restart_threshold = 60
emergency_restart_interval = 60s
#表示在emergency_restart_interval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数如果超过 emergency_restart_threshold个，php-fpm就会优雅重启。这两个选项一般保持默认值。

process_control_timeout = 0
#设置子进程接受主进程复用信号的超时时间. 可用单位: s(秒), m(分), h(小时), 或者 d(天) 默认单位: s(秒). 默认值: 0.

daemonize = yes
#后台执行fpm,默认值为yes，如果为了调试可以改为no。在FPM中，可以使用不同的设置来运行多个进程池。 这些设置可以针对每个进程池单独设置。

listen = 127.0.0.1:9000
#fpm监听端口，即nginx中php处理的地址，一般默认值即可。可用格式为: 'ip:port', 'port', '/path/to/unix/socket'. 每个进程池都需要设置.

listen.backlog = -1
#backlog数，-1表示无限制，由操作系统决定，此行注释掉就行。backlog含义参考：http://www.3gyou.cc/?p=41

listen.allowed_clients = 127.0.0.1
#允许访问FastCGI进程的IP，设置any为不限制IP，如果要设置其他主机的nginx也能访问这台FPM进程，listen处要设置成本地可被访问的IP。默认值是any。每个地址是用逗号分隔. 如果没有设置或者为空，则允许任何服务器请求连接

listen.owner = www
listen.group = www
listen.mode = 0666
#unix socket设置选项，如果使用tcp方式访问，这里注释即可。

user = www
group = www
#启动进程的帐户和组

pm = dynamic #对于专用服务器，pm可以设置为static。
#如何控制子进程，选项有static和dynamic。如果选择static，则由pm.max_children指定固定的子进程数。如果选择dynamic，则由下开参数决定：
pm.max_children #，子进程最大数
pm.start_servers #，启动时的进程数
pm.min_spare_servers #，保证空闲进程数最小值，如果空闲进程小于此值，则创建新的子进程
pm.max_spare_servers #，保证空闲进程数最大值，如果空闲进程大于此值，此进行清理

pm.max_requests = 1000
#设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 '0' 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.

pm.status_path = /status
#FPM状态页面的网址. 如果没有设置, 则无法访问状态页面. 默认值: none. munin监控会使用到

ping.path = /ping
#FPM监控页面的ping网址. 如果没有设置, 则无法访问ping页面. 该页面用于外部检测FPM是否存活并且可以响应请求. 请注意必须以斜线开头 (/)。

ping.response = pong
#用于定义ping请求的返回相应. 返回为 HTTP 200 的 text/plain 格式文本. 默认值: pong.

request_terminate_timeout = 0
#设置单个请求的超时中止时间. 该选项可能会对php.ini设置中的'max_execution_time'因为某些特殊原因没有中止运行的脚本有用. 设置为 '0' 表示 'Off'.当经常出现502错误时可以尝试更改此选项。

request_slowlog_timeout = 10s
#当一个请求该设置的超时时间后，就会将对应的PHP调用堆栈信息完整写入到慢日志中. 设置为 '0' 表示 'Off'

slowlog = log/$pool.log.slow
#慢请求的记录日志,配合request_slowlog_timeout使用

rlimit_files = 1024
#设置文件打开描述符的rlimit限制. 默认值: 系统定义值默认可打开句柄是1024，可使用 ulimit -n查看，ulimit -n 2048修改。

rlimit_core = 0
#设置核心rlimit最大限制值. 可用值: 'unlimited' 、0或者正整数. 默认值: 系统定义值.

chroot =
#启动时的Chroot目录. 所定义的目录需要是绝对路径. 如果没有设置, 则chroot不被使用.

chdir =
#设置启动目录，启动时会自动Chdir到该目录. 所定义的目录需要是绝对路径. 默认值: 当前目录，或者/目录（chroot时）

catch_workers_output = yes
#重定向运行过程中的stdout和stderr到主要的错误日志文件中. 如果没有设置, stdout 和 stderr 将会根据FastCGI的规则被重定向到 /dev/null . 默认值: 空.

Trois erreurs et solutions courantes

1. Problèmes de ressources causés par request_terminate_timeout
Si la valeur de request_terminate_timeout est définie sur 0 ou trop longue. , cela peut entraîner des problèmes de ressources dans la question file_get_contents.

Si la ressource distante demandée par file_get_contents répond trop lentement, file_get_contents sera toujours bloqué là et n'expirera pas. Nous savons que max_execution_time dans php.ini peut définir le temps d'exécution maximum des scripts PHP, mais dans php-cgi (php-fpm), ce paramètre ne prendra pas effet. Ce qui peut vraiment contrôler le temps d'exécution maximum des scripts PHP, c'est le paramètre request_terminate_timeout dans le fichier de configuration php-fpm.conf.

La valeur par défaut de request_terminate_timeout est de 0 seconde, ce qui signifie que le script PHP continuera à s'exécuter. De cette façon, lorsque tous les processus php-cgi sont bloqués dans la fonction file_get_contents(), ce serveur Web Nginx+PHP ne peut plus gérer les nouvelles requêtes PHP, et Nginx renverra "502 Bad Gateway" à l'utilisateur. La modification de ce paramètre est nécessaire pour définir le temps d'exécution maximum d'un script PHP, mais elle ne traite que les symptômes plutôt que la cause première. Par exemple, s'il est modifié en 30s, si file_get_contents() met du temps à obtenir le contenu d'une page Web, cela signifie que 150 processus php-cgi ne peuvent gérer que 5 requêtes par seconde, et il est également difficile pour le serveur Web d'éviter "502 Bad Porte". La solution consiste à définir request_terminate_timeout sur 10 s ou une valeur raisonnable, ou à ajouter un paramètre timeout à file_get_contents.

Copier le code Le code est le suivant :

$ctx = stream_context_create(array(
    'http' => array(
        'timeout' => 10    //设置一个超时时间，单位为秒
    )
));

file_get_contents($str, 0, $ctx);

2. Une mauvaise configuration du paramètre max_requests peut provoquer un 502 intermittent. erreurs :

Copier le code Le code est le suivant :

pm.max_requests = 1000

Définissez le nombre de requêtes servies avant la renaissance de chaque processus enfant. Pour la première fois, il peut y avoir une fuite de mémoire. C'est très utile pour les modules tiers. Si défini sur '0', les requêtes seront toujours acceptées. Valeur par défaut de PHP_FCGI_MAX_REQUESTS.
Ceci. La configuration signifie que lorsqu'un processus PHP-CGI traite une requête une fois que le nombre s'accumule à 500, le processus sera automatiquement redémarré.
Mais pourquoi relancer le processus ?
Généralement dans les projets, nous utiliserons dans une certaine mesure certaines bibliothèques tierces de PHP. Ces bibliothèques tierces ont souvent des problèmes de fuite de mémoire. Si le processus PHP-CGI n'est pas redémarré régulièrement, cela provoquera inévitablement des problèmes. augmentation continue de l’utilisation de la mémoire. Par conséquent, PHP-FPM, en tant que gestionnaire de PHP-CGI, fournit une telle fonction de surveillance pour redémarrer le processus PHP-CGI qui a demandé un nombre de fois spécifié afin de garantir que l'utilisation de la mémoire n'augmente pas.
C'est précisément à cause de ce mécanisme que les erreurs 502 sont souvent provoquées sur les sites à forte concurrence. Je suppose que la raison est que PHP-FPM ne gère pas bien la file d'attente des requêtes provenant de NGINX. Cependant, j'utilise toujours PHP 5.3.2. Je ne sais pas si ce problème existe toujours en PHP 5.3.3.
Notre solution actuelle consiste à définir cette valeur aussi grande que possible afin de réduire autant que possible le nombre de réapparitions de PHP-CGI, tout en améliorant également les performances globales. Dans notre propre environnement de production actuel, nous avons constaté que la fuite de mémoire n'était pas évidente, nous avons donc défini cette valeur très grande (204 800). Chacun doit fixer cette valeur en fonction de sa situation réelle et ne peut pas l'augmenter aveuglément.
Cela dit, le but de ce mécanisme est uniquement de garantir que PHP-CGI n'occupe pas une mémoire excessive. Pourquoi ne pas y remédier en détectant la mémoire ? Je suis tout à fait d'accord avec ce que Gao Chunhui a dit, redémarrer le processus PHP-CGI en définissant le pic d'utilisation intrinsèque du processus serait une meilleure solution.

3, artefact de journal lent, de débogage et de dépannage des exceptions de php-fpm :
request_slowlog_timeout définit un paramètre de délai d'attente, slowlog définit l'emplacement de stockage du journal lent

Copiez le code Le code est le suivant :

tail -f /var/log/www.slow.log

La commande ci-dessus permet de voir le processus php qui s'exécute trop lentement.
Vous pouvez voir les problèmes courants de lecture réseau excessive et de requête Mysql lente. Si vous suivez les informations invitées pour résoudre le problème, vous aurez une direction claire.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!