Nginx惊群效应引起的系统高负载
导语：本文从进程状态，进程启动方式，网络io多路复用纬度等方面知识，分享解决系统高负载低利用率的案例
前言：
趣头条SRE团队，从服务生命周期管理、混沌工程、业务核心链路治理、应急预案、服务治理（部署标准化、微服务化、统一研发框架、限流降级熔断），监控预警治理（黄金指标）入手，不断提升系统稳定率，完成符合标准化的服务上线99.99%可用性承诺SLA。
SRE除了是最好的业务partner，对运维生产环境遇到的疑难杂症的分析解决，是快速提升自身技术的良方妙药，下面是对一则系统高负载问题的处理过程总结和分享，希望能为有类似问题场景解决提供一种思路。
案例分享：
让我们先回顾一些OS基本知识：
（一）进程状态（man ps的解释直译）
PROCESS STATE CODES
Here are the different values that the s, stat and state output specifiers
(header "STAT" or "S") will display to describe the state of a process:
D uninterruptible sleep (usually IO) #不可中断睡眠 不接受任何信号，因此kill对它无效，一般是磁盘io,网络io读写时出现
R running or runnable (on run queue) #可运行状态或者运行中，可运行状态表明进程所需要的资源准备就绪，待内核调度
S interruptible sleep (waiting for an event to complete) #可中断睡眠，等待某事件到来而进入睡眠状态
T stopped by job control signal #进程暂停状态 平常按下的ctrl+z,实际上是给进程发了SIGTSTP 信号 （kill -l可查看系统所有的信号量）
t stopped by debugger during the tracing #进程被ltrace、strace attach后就是这种状态
W paging (not valid since the 2.6.xx kernel) #没有用了
X dead (should never be seen) #进程退出时的状态
Z defunct ("zombie") process, terminated but not reaped by its parent #进程退出后父进程没有正常回收，俗称僵尸进程
我们平常top,ps看到最多的应该是S,R 这2个，Z和D应该很少见（因为io一般在很短的时间内完成），但今天的案例就和D相关；僵尸进程产生的原因是，子进程在退出过程中，按步退回资源后，就会进入Z状态，同时会给父进程发一个信号SIGCHLD，通知父进程来回收子进程，正常情况父进程会通过waitpid函数来捕捉，但如果父进程如果没有接收处理，就会变成Z状态
（二）进程启动的两种方式
fork: 子进程复制父进程所有的资源包括堆栈段、数据段,代码段(实际上是copy on write写时才复制）, 子进程结构体(task_struct)除了pid,ppid，其余基本和父进程的结构体一致,默认情况下子进程会继承父进程所有打开的文件描述符fd(这是本文后面问题的关键之一），代码会从fork后那一行开始执行
感兴趣的同学可以研究linux的内外命令，Linux的内建命令都使用exec方式（具体的内建命令可以用man exec查 或者type cmd确认），外部命令基本是fork+exec方式来启动进程
（三）cpu利用率和load average关系
现代OS基本都是多任务多用户操作系统，在我们人类看来是多个程序并行在运行，实际上在计算机硬件内部是并发执行，在某一个cpu核心上的多个任务实际是分时分片轮流执行，1s内切分成多片给各个进程使用（具体的分片配置是在内核编译阶段完成,可以使用grep CONFIG_HZ /boot/config-$(uname -r)命令查看当前内核时钟中断的频率），例如CONFIG_HZ=1000，即是1ms中断一次，每个进程至多跑出1ms后就要被动退出cpu,等待下一次调度。
cpu利用率反应的就是进程一段时间内占用cpu的比率。
这里多提一下，时钟中断的频率对进程有着非常大的影响，频率越小，分片就越大，进程所得的时间就越多，吞吐量自然就越大，频率越大，分片越小，时钟中断越频繁，响应任务就更快，因此业务对实时性要求高就适用高频率，如网络收发包程序，业务对吞吐量高就适用低频率，如计算型程序。
而负载反应的是在一段时间内 CPU正在处理以及等待 CPU处理的进程数、不可中断状态的任务之和的统计信息。
一般情况下：
cpu利用率高，负载会高；反过来不一定成立，也就是负载高，cpu利用率不一定高（下文的case就是这样）
当cpu运行队列数+等待运行+D进程 >= cpu核心数时，系统基本可以认为是满负载，超负载状态了，系统是一种不健康的状态，这种状态出现可能是cpu处理能力不足，也可能因为等待IO引起的
(四）网络IO(这里只讲同步IO)
一般网络编程中有三种网络模型，accept,select/poll,epoll
accept只能监听一个socket fd,因此当网络包量大时，效率非常低下;
select/poll可同时监听多个socket fd,提高了io读写能力，但因使用的主动轮询机制，所以效率也不高；
epoll可同时监听多个socket fd,同时使用了事件通知机制，有消息时立即处理，无消息时阻塞直到超时，nginx高性能的网络就是使用这种模型
好了，上面说了这么多，现在开始正式分享解决系统高负载过程：
我们有一台nginx接入网关(演练环境)告警显示load比较高，上机器top看cpu利用率不高，但load average已经达到满负载，32核心的机器一分钟负载在30左右，同时可以看到nginx 32个worker 绝大部分处于D状态
一般情况下cpu相关的问题，使用排障利器strace, 使用strace -C -T -ttt -p pid -o strac.log可以既生成系统调用的统计信息，还能观察进程所有的调用过程
从统计信息有一个非常大的疑点，35518次的accept调用，居然有32412次返回失败，再去具体的跟踪记录看看过程：
貌似每次epoll_wait阻塞一段时间后，有新的accept事件到来，但始终又读不到数据，这种情况就很像传说中的惊群效应：
所有的工作进程都在等待一个socket，当socket客户端连接时，所有工作线程都被唤醒，但最终有且仅有一个工作线程去处理该连接，其他进程又要进入睡眠状态。
这种频繁的睡眠和唤醒的操作带来的影响就是 cpu要不断地进行进程上下文切换（保存寄存器，压栈，出栈等），十分地消耗cpu资源，同样的请求量大小，线上生产环境和此机的数据对比如下：
演练的上下文切换数据比生产大了3倍多，
另外注意它左边的In(中断数），演练环境的数据比生产大了一倍多，中断一般最多的情况就是网络包的到来，处理收包需要用软中断来处理，从下面的Metric指标看出，演练机器新连接数确实要比生产大许多，
从网络的连接数和strace串起来的分析可推出：大量的新建连接引起的accept事件，引起惊群效应，cpu利用率浪费了（sys非常高），恶性循环。
那为什么nginx会有惊群现象呢？我们可以先从nginx架构模型分析：
nginx使用master/worker模式，master创建socket fd后，根据cpu核心数fork出了32个worker,每个worker复制了master同一个fd,实际上
也就是32个work监听同一个accept事件,因而当一个新连接过来时，所有其它worker都被唤醒，进而产生惊群。
Nginx 处理惊群的解决办法是加锁，有一个参数accept_mutex，当accept_mutex=on时，只有争抢到锁的worker才会去建立连接，尝试在events中打开此功能后，再看一下负载后的情况：
效果立即展现，cpu负载，sys,cpu利用率全部下降，d状态也不见了，但这里还有个问题，nginx每个worker的负载不均，
这个应该好理解，因为worker去争锁，所以大概率不会均匀。
针对epoll的惊群，linux内核其实最新出一个SO_REUSEPORT特性：
SO_REUSEPORT支持多个进程或者线程绑定到同一端口，提高服务器程序的性能，它有以下优势：
允许多个套接字 bind()/listen() 同一个TCP/UDP端口
每一个线程拥有自己的服务器套接字
在服务器套接字上没有了锁的竞争
内核层面实现负载均衡
nginx在1.9已经开始支持此特性，在http监听Port后加入 reuseport即可，打开后的效果如下：
cpu利用更加均衡，没有了锁，利用率也得到提升
实际上在解决问题后，一直还没有提及nginx出现D状态的原因，以及为什么以上两种方法都自动解决了这个D不出现。
前面提及过，D状态出现一般是IO,可能磁盘IO,也可能是网络IO,如果是磁盘io,iowait应该也能体现，但实际上不是
如果是网络IO,那么从tcp连接到收包的时延应该非常大，抓包分析几乎是us级的响应，
网络没有阻塞，当时一直聚焦在io上没有得到原因，最后只好再从Nginx的调用栈分析：
因为Nginx在惊群现象时，worker长期处于D状态，因此很容易通过几次/proc/pid/stack看出到底卡在哪里：
从此图看出主要卡在accept调用，这超乎我的想象，因为strace中看到的accept已经设置非阻塞nonblock，
1594919593.759203 accept4(7, 0x7ffd203bff00, 0x7ffd203bfefc, SOCK_CLOEXEC|SOCK_NONBLOCK) = -1 EAGAIN (Resource temporarily unavailable) <0.000048>
为什么卡在这里，查看__lock_sock后豁然开朗：
static inline void lock_sock(struct sock *sk)
{
lock_sock_nested(sk, 0);
}
void lock_sock_nested(struct sock *sk, int subclass)
{
might_sleep();
spin_lock_bh(&sk->sk_lock.slock);
if (sk->sk_lock.owned)
__lock_sock(sk);
sk->sk_lock.owned = 1;
spin_unlock(&sk->sk_lock.slock);
/*
* The sk_lock has mutex_lock() semantics here:
*/
mutex_acquire(&sk->sk_lock.dep_map, subclass, 0, _RET_IP_);
local_bh_enable();
}
static void __lock_sock(struct sock *sk)
{
DEFINE_WAIT(wait);
for (;;) {
prepare_to_wait_exclusive(&sk->sk_lock.wq, &wait,
TASK_UNINTERRUPTIBLE);
spin_unlock_bh(&sk->sk_lock.slock);
schedule();
spin_lock_bh(&sk->sk_lock.slock);
if (!sock_owned_by_user(sk))
break;
}
finish_wait(&sk->sk_lock.wq, &wait);
}
#define sock_owned_by_user(sk) ((sk)->sk_lock.owned)
居然在accept中有设置TASK_UNINTERRUPTIBLE，因此惊群引起的大量accept调用失败时，就很容易看到此现象了，真相也大白了。
因此，我们在实际遇到问题时，还是需要熟悉依赖产品或者程序的特性，因此只有深度掌握好系统的各种特性，调优才会更加顺手。