【Linux】一个epoll惊群导致的性能问题

古城微笑少年丶 2022-11-03 10:51 15阅读 0赞

## linux服务器开发相关视频解析： ##

[从nginx“惊群”问题来看高并发锁的方案][nginx]  
[程序性能优化 — 异步帮你解决80%的问题][_ _80]

c/c++ linux服务器开发免费学习地址：[c/c++ linux后台服务器高级架构师][c_c_ linux]

在我们内部的系统中，有一个tcp的代理服务，用户所有的网络相关的请求，比如访问外网，或者访问在内网的某些服务，都需要通过这个服务，一方面是实现对外网访问的计费，另外也通过白名单机制，对应用的内网访问进行相应的限制。  
随着业务量的增加，发现提供服务的机器负载逐渐变高，当流量高峰的时候，经常出现客户端无法连接的情况，本来这个服务也是一个无状态的服务，可以很方便的水平扩容，在添加机器的同时，也尝试去分析一下程序本身的瓶颈，看能否提升一下程序本身的处理能力，通过分析和优化，还是在一定程度上提升了处理能力

首先还是在线上使用perf工具生成了一下火焰图：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTg5NzY5_size_16_color_FFFFFF_t_70]

火焰图

第一次看到这个火焰图感觉很奇怪，主要的问题集中在为什么\_\_accept\_nocancel也就是accept的调用会如此频繁，首先想到的就是惊群效应了，但是应该在Linux内核2.6.18的时候，accept的惊群问题在内核中就已经解决了，我们线上用的CentOS 6.5内核版本已经到了2.6.32，理论上不应该会有类似的问题。  
于是还是到线上尝试strace看一下程序的系统调用：

epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)
    epoll_wait(7, { { EPOLLIN, { u32=9484480, u64=9484480}}}, 1024, 500) = 1
    accept(6, 0x7fff90830890, [128]) = -1 EAGAIN (Resource temporarily unavailable)

绝大部分都是epoll\_wait返回，尝试accept，但是accept返回EAGAIN，这应该就是火焰图中那么多accept调用的原因。又查找了一下资料，发现在epoll编程模型中是不会处理惊群的，当一个socket有事件，内核会唤醒所有监听的epoll\_wait调用，从而导致这个问题。  
我们先分析一下程序，目前程序的工作流程是：

1.  master进程启动，bind并监听一系列fd;
2.  fork n个worker进程;
3.  在worker进程中，获取master进程监听的fd，调用epoll\_create创建epoll instance，并监听listen  
    fd的事件;
4.  如果有新连接，直接accept，然后进入代理流程;
5.  重复执行第4步。

由于线上机器是24核，所以线上运行的时候，会fork 24个worker进程，其实，当worker进程数比较少的时候，这个现象体现的不是很明显，但是当worker进程比较多的时候，惊群产生的而外的损耗，看起来已经无法忽略了。  
对于这个问题，nginx的解决办法是，创建一个全局的锁，只有拿到这个锁的woker进程，才会去监听listen fd的事件进行accept，当某些条件满足，worker会放弃该锁，并停止监听listen fd事件，由其他woker得到锁后继续监听listen fd事件。  
在nginx 1.9.1版本中，支持了一个新的特性reuseport，在Linux 3.9或更新内核中，可以开启SO\_REUSEPORT选项，通过操作系统实现类似之前accept的隔离，来避免惊群现象，同时，能更好的利用多核，提升系统性能。

由于类似nginx的accpet锁实现比较复杂，刚好在我们线上系统CentOS 6.5中，SO\_REUSEPORT这个特性已经被redhat backport回来了，也就说在CentOS 6.5的2.6.32内核中，也能开启SO\_REUSEPORT这个选项，因此就修改了一下proxy的代码，尝试开启SO\_REUSEPORT:

1.  master进程启动;
2.  fork n个worker进程;
3.  在worker进程中，bind并监听一系列fd，在bind之前设置SO\_REUSEPORT选项，调用epoll\_create创建epoll  
    instance，并监听listen fd的事件;
4.  如果有新连接，直接accept，然后进入代理流程;
5.  重复执行第4步。

修改后，同样进行strace，当有新连接的时候，只会有一个worker进程被唤醒进行accept，大大提升了效率，再看一眼火焰图：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTg5NzY5_size_16_color_FFFFFF_t_70 1]

火焰图

可以看到已经看不到accept的调用了，取代的是recv和send以及connect，对于一个tcp代理来说，实现消耗在网络上，是比较正常的，epoll\_wait的调用依然偏多，仍然有优化空间。

通过一个简单的测试，500个线程，50000个请求，在相同机器和配置的情况下，总体时间从约14.38秒减少到约10.27秒，性能大约提升了30%。

PS：在Linux 4.5内核中，引入了EPOLLEXCLUSIVE选项，同样可以解决epoll的惊群问题。

[nginx]: https://www.bilibili.com/video/BV18r4y1A78j/
[_ _80]: https://www.bilibili.com/video/BV1QA411Y73A/
[c_c_ linux]: https://ke.qq.com/course/417774?flowToken=1013300
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTg5NzY5_size_16_color_FFFFFF_t_70]: /images/20221024/5b2da9d8324247459e125aa45abf7e22.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwOTg5NzY5_size_16_color_FFFFFF_t_70 1]: /images/20221024/811ef59521b241d68ae304acccda2a5a.png