[转帖]Nginx性能优化-CPU篇

nginx,性能,优化,cpu · 浏览次数 : 0

小编点评

**性能优化方法论软件层面提升硬件使用率增大CPU的利用率增大内存的利用率增大硬盘IO的利用率提升硬件网卡：万兆网卡硬盘：固体硬盘，关注IOPS和BPS指标** **1. CPU缓存命中率** * 每个CPU都有L1、L2、L3的多级缓存。 * 当程序因为CPU的切换而导致程序在不同的CPU上执行时，往往浪费了之前在多级缓存中的信息。 * 查看L1、L2、L3缓存大小并查看多级缓存与哪个CPU核心共享的空间。 **2. NUMA架构** * NUMA架构将内存和CPU核心分成两部分，比如8核CPU64G的分成2个32G总线分别给CPU0-3、CPU4-7使用。 * 邻居节点和远端节点,都称作非本地节点。 * NUMA状态中显示每个节点可以访问的内存大小。 **3. 性能优化技巧** * 配置worker进程数量等于CPU核数。 * 使用`auto/cpumask`绑定worker进程到指定CPU。 * 拒绝类似的第三方模块不被其他进程争抢资源。 * 降低系统上耗资源的非Nginx进程相关配置设置。 **4. 万兆网卡硬盘** * 固体硬盘比硬盘速度更快，可以提升硬盘IO的利用率。 * 固体硬盘支持IOPS和BPS指标，可以提升硬盘IO的性能。

正文

性能优化方法论

软件层面提升硬件使用率
- 增大CPU的利用率
- 增大内存的利用率
- 增大硬盘IO的利用率
- 增大网络带宽的利用率
提升硬件
- 网卡：万兆网卡
- 硬盘：固体硬盘，关注IOPS和BPS指标
- CPU：更快主频，更多核心，更大缓存，更优架构
- 内存：更快访问速度
超出硬件性能上限后使用DNS

CPU基本知识

为何一个CPU就可以同时运行多个进程？

宏观上并行，微观上串行
- 把进程的运行时间分为一段段的时间片
- OS调度系统依次选择每个进程，最多执行时间片指定的时长
阻塞API引发的时间片内主动让出CPU
- 速度不一致引发的阻塞API：例如CPU和硬盘
- 业务场景产生的阻塞API：例如同步读网络报文

何为进程间切换

是指CPU从一个进程或线程切换到另外一个进程或者线程，类别分为主动切换和被动切换：

主动切换：进程或线程IO阻塞
被动切换：时间片耗尽

如何查看上下文切换次数

// 每隔2秒打印一次 vmstat 2 cs字段：所有进程上下文切换次数 in字段：所有进程中断次数

dstat system.csw 进程上下文切换次数

// 每隔2秒打印一次 pidstat -w 2 // 指定2655371 pid进程 pidstat -w 1 -p 2655371 cswch/s字段：主动切换 nvcswch/s字段：被动切换

什么决定CPU时间片的大小？

top命令 NI字段：Nice静态优先级(-20 -- 19),number值越小,CPU时间片占用越长 PR字段：Priority动态优先级(0-139),number值越小,优先级高于其他正常进程

查看进程状态

ps -aux

STAT字段：

R运行：正在运行或在运行队列中等待
S中断：休眠中, 受阻, 在等待某个条件的形成或接受到信号
D不可中断：收到信号不唤醒和不可运行, 进程必须等待直到有中断发生
Z僵死：进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放
T停止：进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行运行

多核CPU间的负载均衡

worker进程间负载均衡

惊群问题：一个网络请求报文进来，激活了所有work进程，然后只有一个work进程处理了这个请求报文，其他进程则进入sleep状态，从而造成了浪费。

由于当时的linux内核处理很有问题，nginx实现了accept_mutex处理惊群问题。早期默认开启accept_mutex on，目前默认关闭 accept_mutex off。linux内核3.9以上采用reuseport处理大大提升了效率。

经测试得出以下数据：

吞吐量由小到大：accept_mutex on<accept_mutex off<reuseport
时延由长到短：accept_mutex off<accept_mutex on<reuseport
处理的波动情况由大到小，越大有些用户体验就很差：accept_mutex on<accept_mutex off<reuseport

可以看出reuseport全面的优于前面的方案，linux3.9以上、centos7以上可以打开reuseport大大提升性能。

reuseport是怎么做到的呢?它是在kernel层面上实际所有的worker都处于listener

多队列网卡对多核CPU的优化

处理网络报文分为硬中断和软中断

RSS(Receive Side Scaling)硬中断负载均衡：需要网卡支持，现在大部分网卡都支持。网卡在各个CPU上创建队列可以并发处理硬中断
RPS(Receive Packet Steering)软中断负载均衡
RFS(Receive Flow Steering)

不是说把RSS、RPS、RFS都打开，性能就能得到提升。而是在做性能优化的时候，可以考虑这一点，根据场景进行配置优化性能。

提升CPU缓存命中率：worker_cpu_affinity

每个CPU都有L1、L2、L3的多级缓存,一个程序的运行都是从内存->L3>L2>L1>cpu0。其中L3、L2、L1上有缓存信息，如果一个处理过程因为CPU的切换，导致程序在不同的CPU上执行往往浪费了之前在多级缓存中的信息(速度比没有缓存要慢点)。

查看L1、L2、L3缓存大小

~# cat /sys/devices/system/cpu/cpu0/cache/index1/size 32K ~# cat /sys/devices/system/cpu/cpu0/cache/index2/size 4096K ~# cat /sys/devices/system/cpu/cpu0/cache/index3/size 16384K

查看多级缓存与哪个CPU核心共享的空间,奇数之间共享，偶数之间共享。下面因为云主机只有2核，所以只有一个

~# cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list 0 ~# cat /sys/devices/system/cpu/cpu1/cache/index3/shared_cpu_list 1

NUMA架构

随着CPU核数增多16核、32核、内存总线就这么一个，这么多核心并发访问的时候就受限了。NUMA怎把内存和CPU核心分成两部分，比如8核CPU64G的分成2个32G总线分别给CPU0-3、CPU4-7使用。

NUMA节点概念：

本地节点:对于某个节点中的所有CPU，此节点称为本地节点。
邻居节点:与本地节点相邻的节点称为邻居节点。
远端节点:非本地节点或邻居节点的节点，称为远端节点。
邻居节点和远端节点,都称作非本地节点(Off Node)。

列举系统上的NUMA节点

~# numactl --hardware available: 1 nodes (0) node 0 cpus: 0 1 node 0 size: 1987 MB node 0 free: 208 MB node distances: node 0 0: 10

查看NUMA状态

~# numastat node0 numa_hit 1097599967 numa_miss 0 numa_foreign 0 interleave_hit 21312 local_node 1097599967 other_node 0

numa_hit—命中的，也就是为这个节点成功分配本地内存访问的内存大小
numa_miss—把内存访问分配到另一个node节点的内存大小，这个值和另一个node的numa_foreign相对应。
numa_foreign–另一个Node访问我的内存大小，与对方node的numa_miss相对应
local_node----这个节点的进程成功在这个节点上分配内存访问的大小
other_node----这个节点的进程在其它节点上分配的内存访问大小
很明显，miss值和foreign值越高，就要考虑绑定的问题。比如配置：禁止访问远程节点

如何增大Nginx使用CPU的有效时长？

能够使用全部CPU资源
- master-worker多进程架构
- worker进程数量应当大于等于CPU核数
Nginx进程间不做无用功浪费CPU资源
- worker进程不应在繁忙时，主动让出CPU
- worker进程间不应由于争抢造成资源耗散：worker进程数量应当等于CPU核数
- worker进程不应调用一些API导致主动让出CPU：拒绝类似的第三方模块
不被其他进程争抢资源
- 提升进程优先级占用CPU更长时间
- 减少操作系统上耗资源的非Nginx进程