Nginx 压测和性能分析的一些经验

[TOC]

Nginx 压测和性能分析的一些经验

Nginx 压测的一些经验

关注网卡带宽、网卡队列

• 单个千兆网卡的机器，去压测 nginx 的性能，会存在带宽的瓶颈，这个时候观察 CPU 和带宽，发现 CPU 没有跑满，si 也没有满，可是网卡带宽流量已经达到了瓶颈，对于千兆网卡这个说的小 b，而不是大 B；而后理论上千兆网卡的上限是 128MB/s，可是因为种种因素，通常很难达到 128，可是通常而言到了 110MB/s 以上就已是瓶颈了。

  • 千兆网卡基础上，网卡会存在瓶颈，在这个基础上Nginx 当作 Web Server 的话，针对 http：

    • 0KB，QPS = 48w (return 200)
    • 0KB，QPS = 29w (return 302)
    • 1B， QPS = 23w
    • 1KB，QPS = 9w

  • Nginx 直接 return 200 和 return 302，QPS 相差不少（千兆网卡基础上）

    • 在千兆网卡上， return 200， QPS 48w；return 302， QPS 29w。缘由是由于 return 302 的返回结果的 Response 的数据量要大些，从而致使致使了每秒中处理不了那么多请求，由于网卡流量存在瓶颈

• 当压测端的网卡有 4 个千兆网卡了以后，施压端的网卡流量就到瓶颈了，这个时候就须要调整施压端了。

• 4 个网卡绑定后，压测短链接的时候，发现 si 已经到 100%，而且是固定的几个 CPU，这个就说明网卡绑定重复了。

  • 网卡从新绑定没有重复以后，si 有改善，总体性能也稍有提升

• 单机 24 核下，单千兆网卡的场景下，网卡先出现瓶颈； 4 个千兆网卡的场景下，CPU si 软中断先出现瓶颈。

• 压测时候，要关注大包、小包的不一样处理，对于小包，CPU 消耗会更多，由于软中断问题、解包头、校验包数据等层面的问题。 sar 观察数据的时候，通常而言，rxpck/s 和 txpck/s 只须要关注数据而不会存在瓶颈，这个的瓶颈会创建在 CPU 上；而须要关注的是 rxkB/s 和 txkB/s ，这个决定了网卡流量带宽的上限。不只仅是要观察服务端，还要看客户端是否有瓶颈（CPU、网卡带宽）、错误状况等

关注 Nginx CPU 消耗是否均匀

• 正常而言，nginx 的各个 worker 进程的 CPU 消耗应该都要比较均匀，若是相差 10% 以上，甚至 20% 以上，那么就必定存在 CPU 消耗不均的问题。nginx 目前的版本会使得 CPU 不均，由于关闭了 accept_mutex，正常的话，各个 worker 进程应该都是要差很少的 CPU 消耗，若是开启accept_mutex on；会均匀到前面几个 nginx worker 进程。

• 最优的姿式是开启 reuseport，可是这个须要注意要和 dynamic upstream 一块儿使用，不然若是出现频繁 reload 则会致使出现大量 RST。

关注 CPU 超线程

• 禁能、使能 CPU 超线程，在 nginx 单进程的状况下，并无明显差别
  • 压测时候， 是否关闭超线程，没有明显差别

关注单机多实例

• 单机单实例性能达到极限后或者出现瓶颈后，单机多实例仍是同样，没有提高； 单机单实例没有性能瓶颈的话，多实例能够提高性能

关注施压端

• 压测的时候，要找到一个性能拐点；若是一上来就是瓶颈了，那么还须要往回调，直到找到一个最佳的性能拐点。

  • 长链接的时候，若是 wrk 给的线程数、并发数太大，反而会使得 Nginx 只有 1 个 worker 进程的时候的性能下降； 短进程的时候，wrk 端的系统参数 net.ipv4.tcp_tw_recycle 要设置为 1，让端口复用，不然会出现一些链接错误

  • 所以一个过程就是会将施压端的压力（线程数、并发数）会减小、增大，从而观察 Nginx 服务端的数据，而后获得最佳性能数据

• wr 压力上不去? 要想为啥上不去？ CPU遇到瓶颈了，仍是内存遇到瓶颈了？ 若是cpu的话，那么怎么给更多CPU？固然的线程数。可是线程数也要和施压方的CPU核心数匹配。

  • top -H 看线程，要让每一个线程都没跑满，这样才能发挥最大的性能，若是每一个线程跑满了，那么wrk则没法发挥最大性能，也就是没法提供最高压力。若是每一个线程都没跑满，可是QPS 仍是上不去，那么就是Nginx这边性能的问题了。

压测时必需要观察的指标

CPU【top】

top ，观察 CPU 消耗状况，同时也要观察每一个 CPU 核数的状况，而且关注 si 软中断的数据，si 到了 100% 就有问题了

网卡带宽【sar -n DEV 1 100 |grep em1】

sar -n DEV 1 100 |grep em1

观察网卡带宽状况，看网卡带宽是否到了瓶颈

而后能够 ifconfig 查看是否有丢包之类的。

每秒建连数【netstat -s |grep active】

netstat -s |grep active
    6262441249 active connections openings
复制代码

经过 netstat -s |grep active 获取当前活跃的链接，而后作差值。

5W 短链接的 QPS， 若是还有upstream是短链接，那么每秒建连数应该是10W左右

链接队列 【ss -lnt 】

ss -lnt

ss -lnt |grep -E ":6001|:6002"

State       Recv-Q Send-Q                                   Local Address:Port                                                  Peer Address:Port
复制代码

• 当套接字处于监听状态（Listening）时，

  • Recv-Q 表示 syn backlog 的当前值。
  • Send-Q 表示最大的 syn backlog 值。

• 链接队列若是过小，那么须要调整系统和 nginx 的配置

磁盘 IO

Nginx 调优的一些经验

Nginx 的性能指标

相关基础指标：

• Requests per second (RPS) ： nginx 每秒处理的请求数（也就是： QPS）

  • RPS for HTTP Requests： nginx 每秒处理的 http 请求数

  • RPS for HTTPS Requests (SSL/TLS transactions per second )(TPS) ： nginx 每秒处理的 https 请求数

  • 要关注响应数据在 0 - 1 - 10 - 100 KB 的不一样状况的表现

    • 0KB 表示一个空的 http 响应，好比返回 302 错误码

• Connections per Second (CPS) ： nginx 每秒处理的新建链接请求数

  • 包括 http 和 https

• Throughput：吞吐量，反应 nginx 能够处理的数据量的大小的能力

• latency： 延迟和延迟分布

其余关注点：

• 关注 CPU 核数从 1 - n 下，nginx 性能的表现

  • 利用 taskset，能够将一个 wrk 进程绑定到一个 CPU 核上；能够准确的测试不一样 CPU 核下的性能状况

• 关注 nginx 的角色是 webserver 或者 反向代理的不一样表现

• 链接数，有时候也会被称为并发数，指的是同时在服务中的请求数。也就是那些已经发送请求（Request），可是尚未收完应答（Response）的请求数量。

Nginx 必需要调整的参数

Nginx 必需要调整的参数：

worker_processes     auto;
worker_rlimit_nofile 10240;

worker_connections 10240;

tcp_nopush  on;
tcp_nodelay on;


keepalive_timeout  300s;     
keepalive_requests 1000000;
复制代码

建议调整的参数：

proxy_connect_timeout 60;
proxy_send_timeout 60;
proxy_read_timeout 60;
复制代码

Linux 系统必需要调整的参数

conntrack 参数

通常，设置 nf_conntrack_max 为 200w， nf_conntrack_buckets 为 1/4 或者 1/2 倍 nf_conntrack_max，防止桶太大致使性能影响。

[wdb@BJZW-K8SM-ZW-1-23-25.meitu-inc.com ingress]$ cat /proc/sys/net/netfilter/nf_conntrack_buckets
524288

[wdb@BJZW-K8SM-ZW-1-23-25.meitu-inc.com ingress]$ cat /proc/sys/net/netfilter/nf_conntrack_max
2097152
复制代码

backlog 队列

• net.core.somaxconn

  • 能够排队等待 Nginx 接受的最大链接数。一般若是过小致使了 Nginx 性能问题能够查看内核日志发现这个状态
  • 配合 NGINX listen 指令一块儿调整。

• net.core.netdev_max_backlog

  • 数据包在发送给 CPU 以前被网卡缓冲的速率；增长该值能够提升具备高带宽的机器的性能

echo 32768 > /proc/sys/net/core/somaxconn
echo 819200 > /proc/sys/net/ipv4/tcp_max_syn_backlog
复制代码

文件描述符

• sys.fs.file-max

  • Linux 系统容许的最大文件描述数

• nofile

  • 应用层面容许的最大文件描述符数，通常设置 /etc/security/limits.conf文件

端口 【修改 /etc/sysctl.conf，而后 sysctl -p 生效】

• net.ipv4.ip_local_port_range

  • port 端口的范围

• 对压测端而言，若是是短连接

  • net.ipv4.tcp_tw_reuse = 1
    • 表示开启端口复用。容许将TIME-WAIT sockets从新用于新的 TCP接，默认为0，表示关闭；
  • net.ipv4.tcp_tw_recycle = 1
    • 表示开启TCP链接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

网卡队列、CPU 软中断 si

• 单机 20-24 核下，单千兆网卡的场景下，网卡先出现瓶颈； 4 个千兆网卡的场景下，CPU si 软中断先出现瓶颈。

• 4 个网卡绑定后，压测短链接的时候，发现 si 已经到 100%，而且是固定的几个 CPU，这个就说明网卡绑定重复了。网卡从新绑定没有重复以后，si 有改善，总体性能也稍有提升

• CPU idle 为 0 不会有问题，只有 si 为 100% 才会有问题

  • si 到 100%，表示 CPU 在大量处理软中断，这个时候，说明网卡软中断和 CPU 绑定这个有些瓶颈。要么就是网卡队列不够，要么就是 CPU 核心太少，要么就是网卡队列和 cpuset 对进程的 CPU 绑定重复了。

【"欢迎关注个人微信公众号：Linux 服务端系统研发，后面会大力经过微信公众号发送优质文章"】