Tengine/Nginx性能优化及杂谈

谷歌、度娘搜索Nginx优化，能搜索出很多的文章，动不动就几万并发，十万并发，看着好像真是那么回事似的。

从使用Tengine的过程中，对Tengine/Nginx的优化，我个人认为Tengine的优化是脱离不开使用它的环境及部署结构的，单说优化
Tengine的意义并不大，况且每家公司的业务各不相同，所以优化不是简单的事情。即便如此，我总结了下，从以下几个方便入手浅谈下
Tengine/Nginx的性能优化。本文以Tengine为主，Nginx大部分都适用。

1、网络

带宽

一个需要支持1万并发且平均页面内容在100KB的情况下，就需要大概1G的带宽，如果带宽只有100M，需要支持这样的场景无论如何也是不可能的。更好的带宽可以支持更高的并发

路由

现在的IDC运营商有很多，越小的运营商在路由优化上就不怎么样，例如在对IDC进行测试的时候，大部分运维使用ping来测试机房的网络质量，这种测试
其实是点到点的测试，中间大网的情况就测试不到。在使用mtr进行测试的时候，可以看到每一跳的延迟及路由，很多时候会发现浮动路由。这种情况下网络质量
一定不好。最好通过mtr对机房提供的IP连续进行一周的测试，路径都比较稳定的时候这样的机房值得选择。

2、硬件

CPU

一般情况下作为Tengine/Nginx的应用，CPU的频率我认为对性能影响还是较小的，但是核心数对于Tengine/Nginx而言确实很有用，
更多的核心数外加HT技术，可以让Tengine/Nginx运行更多的worker，从而提升Tengine/Nginx的负载能力

内存

内存的容量直接对Tengine/Nginx可承载的连接数有影响（主要指ESTAB连接）。另外大容量的内存在结合tmpfs进行合理使用的话，可以作为Tengine/Nginx的各种temp目录及各种缓存目录，降低对磁盘IO的消耗

网卡

目前在互联网公司DELL的服务器应该是用的最多的了，而且在用户没有特殊需求的时候，配置的网卡通常是Broadcom
BCM57XX的，这种网卡比较便宜所有在处理小包的时候，带宽利用率不高，且流量大的时候会出现大量丢包。在Tengine/Nginx的机器上还是推
荐使用Intel X350I QP的网卡，在使用最新的网卡驱动后，可以对网卡做出更多性能控制（X350默认的RSS队列最大为8个）

磁盘

磁盘的IO能力个人认为在硬件里的比重不高，在拿Tengine/Nginx作为专用缓存服务器的时候，使用SATA
SSD或者PCIe-SSD卡时可以作为缓存存放的目录路径。一般Intel S3710 800G的大概7000左右，同容量宝存的800G
PCIe-SSD大约1.5W。

3、系统

TCP/IP协议栈

CLOSE_WAIT与TIME_WAIT

这两种连接状态是Web服务器中大家最关心的也是最让大家头疼的，虽然很多的博客里说现在服务器内存大，这种连接达到几万、几十万时对内存的消耗不是问题
不用去理会，但是在一些场景中可能会对应用造成很大的影响。例如在我们的业务中出现CLOSE-WAIT状态时，是数据库有长事务执行时导致Resin出
现了CLOSE-WAIT连接，当这种连接数高于10个时，应用就会打开慢直到应用打不开。所以需要对其进行优化。尽量避免系统中出现过多的这两种连接。

当Tengine/Nginx反向代理后端服务器的时候，Tengine所在的服务器上会出现TIME-WAIT（跟后端服务器断开后产生的状态）以及
CLOSE-WAIT（客户端断开后产生的状态）的连接，一般为了减少Tengine/Nginx与后端服务器通信时造成的TIME-WAIT连接，主要
需要如下的配置，例如：

配置一

upstream example {
        server 192.168.0.1:8080;
        keepalive 4;
}
server{
        listen 80 backlog=2048;
        server_name www.example.com;
        location = /favicon.ico {
                error_page 404 = 200;
                log_not_found off;
                access_log off;
        }
        location = /robots.txt {
                error_page 404 = 200;
                log_not_found off;
                access_log off;
        }
        location / {
                include proxy_opt.conf;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_pass      http://example;
        }
}

配置二

server{
        listen 80 backlog=2048;
        server_name www.example.com;
        location = /favicon.ico {
                error_page 404 = 200;
                log_not_found off;
                access_log off;
        }
        location = /robots.txt {
                error_page 404 = 200;
                log_not_found off;
                access_log off;
        }
        location / {
                include proxy_opt.conf;
                proxy_pass      http://192.168.0.1:8080;
        }
}

两种配置，都可以实现www.example.com的访问，区别在于配置一因为使用upstream且在upstream里配置了keepalive连
接，在压力较大的时候Nginx与后端server之间的CLOSE-WAIT以及TIME-WAIT将非常少，因为有长连接。而配置二是直接
proxy_pass，在压力大的时候CLOSE-WAIT和TIME-WAIT的数量将比较多，在这种情况下，容易产生孤儿连接，孤儿连接一般占用内存
约64K且为不可交换内存（可参考内核文档）。在Tengine中不光可以在upstream中配置与upstream的长连接，还支持长连接超时参数。
（此处估计有人说优化TCP/IP协议栈就可以降低CLOSE-WAIT和TIME-WAIT的连接数了，真的吗？你去试试就知道了。）

除了在Nginx上启用upstream来减少CLOSE-WAIT和TIME-WAIT的连接数外，还有2种方式：
a)在/etc/sysctl.conf中将net.ipv4.tcp_max_tw_buckets的值改为0,可以快速释放TIME-WAIT连接（此法比较暴力，但在系统负载比较高时比较好使，有点像Haproxy中的option forceclose）

b)编辑kernel中include/net/tcp.h
将
#define TCP_TIMEWAIT_LEN (60*HZ)
修改为
#define TCP_TIMEWAIT_LEN (5*HZ)
重新编译内核

4、Tengine本身

安装方式的选择

对于Tengine的安装，目前貌似官方只提供源码包，只能编译安装。

对于Nginx的安装，可以通过在线的软件源进行在线安装，也可以源码编译安装

在线安装一般使用通用的CPU指令集对Nginx进行编译，这种方式不能很好的利用当前CPU的指令集，且配置文件、可执行文件均不能自定义安装目录。对于大规模进行批量化部署时不方便。

源码编译可以通过指定gcc的参数结合CPU的指令集对Nginx进行编译，可以充分使用CPU的指令集提升性能，且安装目录可以自定义，通过修改可执行文件的rpath还可以被fpm打包成公司专用的rpm包，适合批量部署。

对于GCC可使用的参数，可以参考GCC的官方手册

基本配置的优化

#自动设置Nginx启动的worker数量，默认是CPU的processor数（不是core数）
worker_processes auto;
#自动将Nginx的worker进程绑定到CPU的processor上,1.9.10才支持auto,Tegine默认支持
worker_cpu_affinity auto;
#设置所有worker的open files数，如不设置默认为系统ulimit -n的大小
worker_rlimit_nofile 100000;
#开启pcre jit功能，编译pcre的时候需要开启jit功能
pcre_jit on;
events{
        use epoll;
        worker_connections 8192;
每个worker的最大连接数，这个数字不光光只Nginx与Client间的连接，还包括Nginx与后端Server的连接数，配置的时候须注意
worker_rlimit_nofile>worker_connections*workers
        accept_mutex off;在访问量较大的网站上建议关闭accept_mutex机制
}

client_header_buffer_size 8k;
client_header_timeout 10;
client_body_buffer_size 256k;
client_body_timeout 10;
large_client_header_buffers 4 8k;
client_max_body_size 20m;
send_timeout 10;
keepalive_timeout 30;
keepalive_requests 5000;
reset_timedout_connection on;
log_format access

配置文件中的各种buffer

proxy_pass

proxy_connect_timeout   60;
proxy_send_timeout      60;
proxy_read_timeout      60;
proxy_buffer_size       64k;
proxy_buffers           4 64k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 512k;
proxy_next_upstream error timeout invalid_header http_503 http_404 http_502 http_504;
proxy_max_temp_file_size 32m;
proxy_intercept_errors  on;

fastcgi_pass

fastcgi_connect_timeout 30;
fastcgi_send_timeout 15;
fastcgi_read_timeout 15;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 512k;

单台Tengine最大连接数估算

合理利用proxy_cache和fastcgi_cache

SO_REUSEPORT && TCP Fast Open

关于SO_REUSEPORT和TCP Fast Open的原理以及它们是做什么的，可以自行谷歌上查找

就这reuseport功能Tengine 2.1.0就支持，Nginx直到1.9.1才支持reuseport

SO_REUSEPORT特性本来是kernel 3.9以上才支持的功能，不过Red Hat在其6.5版本开始就支持该特性了，所以使用CentOS 6系列的童鞋只需要升级内核大于6.5版本的就可以使用了。

TCP Fast Open这个特性RHEL
6中并没有支持，真的需要3.7以上的内核才支持，有需要使用这个特性的童鞋可以升级内核，升级可以安装UEK内核，或者通过ELRepo安装高版本的内
核，通知需要重新编译Tengine或者Nginx用以支持TFO,另Haproxy 1.5已经支持TFO功能

合理使用tmpfs

在使用Nginx的过程中，总是会考虑使用proxy_cache，fastcgi_cache，同时也会产生各种临时文件，大多数情况下，运维工程师都
会使用物理磁盘去承担这部分工作，但这样会产生额外的IO，重要的是响应速度方面磁盘要低于内存，所以在针对各种cache，以及各种temp的情况，有
以下建议可参考:

a)用Nginx做缓存服务器
在使用1U DELL R630且内存为128G的前提条件下，如果被缓存的数据小于64G，可考虑直接使用tmpfs来作为proxy_cache或者fastcgi_cache的存储介质，当缓存数量非常大时也可以使用PCIe-SSD来做缓存的存储介质
b)将Nginx产生的临时文件放入tmpfs
本人使用的做法，将mount tmpfs的命令写入Nginx的启动脚本中。读者可自行研究，以下为自用启动脚本
注意tmpfs如果使用echo {1,2,3} > /proc/sys/vm/drop_caches是无法释放tmpfs占用的内存的，除非清空tmpfs

#! /bin/sh
# Description: Startup script for Tengine
# chkconfig: 2345 55 25
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DESC="Tengine daemon"
NAME=tengine
DAEMON=/opt/websuite/tengine/sbin/nginx
CONFIGFILE=/opt/config/tengine/nginx.conf
PIDFILE=/opt/run/tengine/$NAME.pid
SCRIPTNAME=/etc/init.d/rc.tengine
TESTPATH=/opt/websuite
CACHEDIR=/opt/websuite/tengine/cache
TEMPDIR=/opt/websuite/tengine/temp
set -e
[ -x "$DAEMON" ] || exit 0

do_start() {
 $DAEMON -c $CONFIGFILE || echo -n "tengine already running"
}

do_stop() {
 $DAEMON -c $CONFIGFILE -s stop || echo -n "tengine not running"
}

do_reload() {
 $DAEMON -c $CONFIGFILE -s reload || echo -n "tengine can‘t reload"
}

do_mount_ramdisk() {
 mount -t tmpfs tmpfs $TEMPDIR/client -o defaults,size=32M,uid=websuite,mode=755
 mount -t tmpfs tmpfs $TEMPDIR/proxy -o defaults,size=32M,uid=websuite,mode=755
 mount -t tmpfs tmpfs $TEMPDIR/fastcgi -o defaults,size=32M,uid=websuite,mode=755
 mount -t tmpfs tmpfs $TEMPDIR/hmux -o defaults,size=32M,uid=websuite,mode=755
 mount -t tmpfs tmpfs $CACHEDIR/proxy -o defaults,size=512M,uid=websuite,mode=755
 mount -t tmpfs tmpfs $CACHEDIR/fastcgi -o defaults,size=512M,uid=websuite,mode=755
}

do_umount_ramdisk() {
 umount $TEMPDIR/client
 umount $TEMPDIR/proxy
 umount $TEMPDIR/fastcgi 
 umount $TEMPDIR/hmux
 umount $CACHEDIR/proxy
 umount $CACHEDIR/fastcgi
}

case "$1" in
 start)
 echo -n "Starting $DESC: $NAME"
 if [ $(mount|grep $TESTPATH|wc -l) -eq 0 ];then
        do_mount_ramdisk
 fi
 do_start
 echo "."
 ;;
 stop)
 echo -n "Stopping $DESC: $NAME"
 do_stop
 if [ $(mount|grep $TESTPATH|wc -l) -gt 0 ];then
        do_umount_ramdisk
 fi
 echo "."
 ;;
 reload)
 echo -n "Reloading $DESC configuration..."
 do_reload
 echo "."
 ;;
 restart)
 echo -n "Restarting $DESC: $NAME"
 do_stop
 sleep 1
 do_start
 echo "."
 ;;
 *)
 echo "Usage: $SCRIPTNAME {start|stop|reload|restart}" >&2
 exit 3
 ;;
esac
exit 0

5、Nginx常见部署场景

静态资源网站

Tengine+PHP-FPM

Tengine+Tomcat

Tengine使用hmux构建Resin集群

Tengine结合KVM构建Web集群

Haproxy/LVS+Tengine的配合使用

6、监控

Tengine基本状态输出

利用nginx-module-vts输出更多数据

7、其他

分布式缓存

缓解机器人压力

动态更新upstream

有Varnish的架构中Tengine扮演的角色

时间： 2024-10-19 09:07:13

Tengine/Nginx性能优化及杂谈的相关文章

Nginx性能优化配置（三）

Nginx性能优化配置(三)  本文主要介绍Nginx的性能优化配置,文章的层次架构如图所示. 1.Nginx的工作进程优化 1.worker_processes 作用:worker进程的数量:通常应该等于小于当前主机的cpu的物理核心数:auto表示根据CPU的物理核心数自动调整工作进程数.使用lscpu或或者cat /proc/cpuinfo | grep 'processor' | wc -l 可以查看CPU的物理核心数. 配置:worker_processes auto: 配置段:mai

Nginx 性能优化

1.安全优化:隐藏Nginx版本号,server_tokens off; 2.安全优化:更改掉默认的用户  user nginx; 3.性能优化:  根据硬件配置,调整nginx worker 进程数 ,一般为cpu的核数 4.性能优化:绑定不同的进程到不同的cpu上,硬件资源平均分配,比如4个worker进程数,即work_cpu_affinity 0001 0010 面试题:命令行如何通过调整命令来调整不同的进程或服务到不同的cpu上,资源平均分配 5.性能优化:nginx的事件处理模型优化

nginx性能优化技巧

前几天买了本高俊峰的<高性能Linux服务器构建实战I>,网上都说运维必备手册,昨天看了目录加小50页感觉还是比较扩充视野的,很多东西在学校是不可能学到的,就是感觉有的地方讲的仍然不是很清楚,毕竟79块的书其实可以写到800页的.... 个人对于nginx比较感兴趣,源码的编译安装是比较熟的了,配置文件本来以为挺熟的,但是看了书上配置文件的N多命令我感觉根本玩不起来.因为实在是太多了,要背根本不现实,就算背下来不去用也会很快就忘掉.十分蛋疼~~ 书上对于Nginx的性能优化写了4种方法,下面分

nginx性能优化调优之google-perftools

什么是google-perftools?google-perftools是google公司开发的一款针对 C/C++ 程序的性能分析开源工具,使用该工具可以对 CPU 时间片.内存等系统资源的分配和使用进行分析google-perftools包含四个工具,分别是:TCMalloc.heap-checker.heap-profiler和cpu-profiler,其中我们本次需要的一个工具TCMalloc是google-perftools的其中一个工具,用于优化内存分配的效率和速度,帮助在高并发的情

Nginx性能优化技巧（6）

一.编译安装过程优化 1.减小Nginx编译后的文件大小 在编译Nginx时,默认以debug模式进行,而在debug模式下会插入很多跟踪和ASSERT之类的信息,编译完成后,一个Nginx要有好几兆字节.在编译前取消Nginx的debug模式,编译完成后Nginx只有几百千字节,因此可以在编译之前,修改相关源码,取消debug模式,具体方法如下: 在Nginx源码文件被解压后,找到源码目录下的auto/cc/gcc文件,在其中找到如下几行: # debug CFLAGS="$CFLAGS -g

nginx性能优化及内核参数调整

Nginx配置参数优化 Nginx作为高性能web服务器,即使不特意调整配置参数也可以处理大量的并发请求.以下的配置参数是借鉴网上的一些调优参数,仅作为参考,不见得适于你的线上业务. worker进程 worker_processes 该参数表示启动几个工作进程,建议和本机CPU核数保持一致,每一核CPU处理一个进程. worker_rlimit_nofile 它表示Nginx最大可用的文件描述符个数,需要配合系统的最大描述符,建议设置为102400. 还需要在系统里执行ulimit -n 10

Nginx 性能优化有这篇就足够了！

1.Nginx运行工作进程数量 Nginx运行工作进程个数一般设置CPU的核心或者核心数x2.如果不了解cpu的核数,可以top命令之后按1看出来,也可以查看/proc/cpuinfo文件 grep ^processor /proc/cpuinfo | wc -l [[email protected]~]# vi/usr/local/nginx1.10/conf/nginx.conf worker_processes 4; [[email protected]~]# /usr/local/ngi

nginx性能优化

event段优化 使用epoll事件驱动,比默认selec.poll更高效. 加大worker_connection 65535,使得nginx并发能够执行更多的连接 如果设定过小,在高并发的情况下,会在日志中有 work_connection is not enough while accepting new connection on 同时也要修改操作系统的进程最大可处理的文件句柄值 echo 131070 > /proc/sys/fs/file-max; sysctl –p 否则有可能会出

Nginx 性能优化（配置文件详解）

随着访问量的不断增加,需要对 Nginx 和内核做相应的优化来满足高并发用户的访问,那下面在单台 Nginx 服务器来优化相关参数. Nginx.conf 配置优化: worker_processes 8; nginx 进程数,建议按照 cpu 数目来指定,一般为它的倍数.worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; 为每个进程分配 cpu,上例中将 8 个