博客再次改版了,这次在细节方面做了一些调整。
nginx及php-fpm优化
时间:2020-12-04 17:10:57 +0800 CST 浏览:167

摘要

简单的讲讲nginx+php的一些常用优化,以及相关的内核参数优化。

Nginx 优化

1. TCP 与 UNIX 套接字
UNIX 域套接字提供的性能略高于 TCP 套接字在回送接口上的性能(较少的数据复制,较少的上下文切换)。如果每个服务器需要支持超过 1000 个连接,请使用 TCP 套接字 - 它们可以更好地扩展。

upstream backend 
{
  server unix:/var/run/fastcgi.sock; 
}

2. 调整 worker_processes 参数
现代硬件是多处理器,NGINX 可以利用多个物理或虚拟处理器。在大多数情况下,您的 Web 服务器计算机不会配置为处理多个工作负载(例如同时提供 Web 服务器和打印服务器的服务),因此您需要配置 NGINX 以使用所有可用的处理器,因为 NGINX 工作进程是不是多线程的。
将 nginx.conf 文件中的 worker_processes 设置为计算机所具有的核心数。
当你在它的时候,增加 worker_connections 的数量(每个核心应该处理多少个连接)并将 multi_accept 设置为 ON,如果你在 Linux 上则设置为 epoll:

worker_processes 4;
events 
{ 
  worker_connections 1024; 
  multi_accept on; 
}

3. 禁用访问日志

access_log off; 
log_not_found off; 
error_log /var/log/nginx-error.log warn;

如果有需要不可以关闭,至少是缓存他们

access_log /var/log/nginx/access.log main buffer=16k;

4. 开启 gzip 压缩

gzip on; 
gzip_disable "msie6"; 
gzip_vary on; 
gzip_proxied any; 
gzip_comp_level 6; 
gzip_min_length 1100; 
gzip_buffers 16 8k; 
gzip_http_version 1.1; 
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

5. 缓存访问频次较高的文件

open_file_cache max=2000 inactive=20s; 
open_file_cache_valid 60s; 
open_file_cache_min_uses 5; 
open_file_cache_errors off;

6. 调整客户端超时

client_max_body_size 50M; 
client_body_buffer_size 1m; 
client_body_timeout 15; 
client_header_timeout 15; 
keepalive_timeout 2 2; 
send_timeout 15; 
sendfile on; 
tcp_nopush on; 
tcp_nodelay on;

7. 调整输出缓存

fastcgi_buffers 256 16k; 
fastcgi_buffer_size 128k; 
fastcgi_connect_timeout 3s; 
fastcgi_send_timeout 120s; 
fastcgi_read_timeout 120s; 
fastcgi_busy_buffers_size 256k; 
fastcgi_temp_file_write_size 256k; 
reset_timedout_connection on; 
server_names_hash_bucket_size 100;

8. 负载均衡策略
Nginx 提供轮询(round robin)、用户 IP 哈希(client IP)和指定权重 3 种方式。
默认情况下,Nginx 会为你提供轮询作为负载均衡策略。但是这并不一定能够让你满意。比如,某一时段内的一连串访问都是由同一个用户 Michael 发起的,那么第一次 Michael 的请求可能是 backend2,而下一次是 backend3,然后是 backend1、backend2、backend3…… 在大多数应用场景中,这样并不高效。当然,也正因如此,Nginx 为你提供了一个按照 Michael、Jason、David 等等这些乱七八糟的用户的 IP 来 hash 的方式,这样每个 client 的访问请求都会被甩给同一个后端服务器。

upstream backend {
  ip_hash;
  server unix:/var/run/php7.2-fpm.sock1 weight=100 max_fails=5 fail_timeout=5; 
  server unix:/var/run/php7.2-fpm.sock2 weight=100 max_fails=5 fail_timeout=5; 
}

9. 持续监控日志
尤其是在调优最初期,在一个窗口

tail -f /var/log/nginx/error.log

在另外两个窗口分别:

tail -f /var/log/php-fpm/error.log
tail -f /var/log/php-fpm/www-error.log

PHP-fpm 优化

1. 修改进程管理模式
static 管理模式适合比较大内存的服务器,而 dynamic 则适合小内存的服务器,你可以设置一个 pm.min_spare_servers 和 pm.max_spare_servers 合理范围,这样进程数会不断变动。ondemand 模式则更加适合微小内存,例如 512MB 或者 256MB 内存,以及对可用性要求不高的环境。

pm = dynamic #指定进程管理方式,有3种可供选择:static、dynamic和ondemand。
pm.max_children = 16 #static模式下创建的子进程数或dynamic模式下同一时刻允许最大的php-fpm子进程数量。
pm.start_servers = 10 #动态方式下的起始php-fpm进程数量。
pm.min_spare_servers = 8 #动态方式下服务器空闲时最小php-fpm进程数量。
pm.max_spare_servers = 16 #动态方式下服务器空闲时最大php-fpm进程数量。
pm.max_requests = 2000 #php-fpm子进程能处理的最大请求数。
pm.process_idle_timeout = 10s
request_terminate_timeout = 120

pm = static,始终保持一个固定数量的子进程,这个数由 pm.max_children 定义,这种方式很不灵活,也通常不是默认的。
pm = dynamic,启动时会产生固定数量的子进程(由 pm.start_servers 控制)可以理解成最小子进程数,而最大子进程数则由 pm.max_children 去控制,子进程数会在最大和最小数范围中变化。闲置的子进程数还可以由另 2 个配置控制,分别是 pm.min_spare_servers 和 pm.max_spare_servers。如果闲置的子进程超出了 pm.max_spare_servers,则会被杀掉。小于 pm.min_spare_servers 则会启动进程(注意,pm.max_spare_servers 应小于 pm.max_children)。
pm = ondemand,这种模式和 pm = dynamic 相反,把内存放在第一位,每个闲置进程在持续闲置了 pm.process_idle_timeout 秒后就会被杀掉,如果服务器长时间没有请求,就只会有一个 php-fpm 主进程。弊端是遇到高峰期或者如果 pm.process_idle_timeout 的值太短的话,容易出现 504 Gateway Time-out 错误,因此 pm = dynamic 和 pm = ondemand 谁更适合视实际情况而定。

2. 释放内存的配置

pm.max_requests = 1000

设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ‘0’ 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.
也就是当一个 PHP-CGI 进程处理的请求数累积到 1000 个后,自动重启该进程,防止第三方库造成的内存泄漏。 重启时可能会导致 502 错误,在高并发站点时有出现。

3. php-fpm 慢日志

request_terminate_timeout = 30s #将执行时间太长的进程直接终止
request_slowlog_timeout = 2s #2秒
slowlog = log/$pool.log.slow #日志文件

内核优化

一 TIME_WAIT产生原因:

1、nginx现有的负载均衡模块实现php fastcgi负载均衡,nginx使用了短连接方式,所以会造成大量处于TIME_WAIT状态的连接。
2、TCP/IP设计者本来是这么设计的
主要有两个原因
(1) 防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
(2) 可靠的关闭TCP连接
在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。

二 过多TIME_WAIT危害

TIME_WAIT 并不会占用很大资源的,除非受到攻击。只要把TIME_WAIT所占用内存控制在一定范围。一般默认最大是35600条TIME_WAIT。

三 解决方法

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭。
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭。
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。默 认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。

注:

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

设置这两个参数: reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接; recyse是加速TIME-WAIT sockets回收



如果这篇文章对你有所帮助,可以通过下边的“打赏”功能进行小额的打赏。

本网站部分内容来源于互联网,如有侵犯版权请来信告知,我们将立即处理。


来说两句吧