epoll accept 惊群

最新推荐文章于 2025-03-16 13:02:54 发布
最新推荐文章于 2025-03-16 13:02:54 发布
阅读量599 收藏
点赞数
分类专栏： linux 网络 文章标签： epoll accept 惊群
本文介绍 Linux 中 epoll 新增的 EPOLLEXCLUSIVE 选项如何解决新建连接的‘惊群’问题。通过使用 add_wait_queue_exclusive 函数，在监听套接字的 sk_sleep 队列中只唤醒一个等待源，有效避免了因多个进程同时被唤醒而产生的资源浪费。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

Epoll 新增 EPOLLEXCLUSIVE 选项解决了新建连接的’惊群‘问题


epoll最终和accept一样解决了新建连接的惊群问题 patch地址：
 https://github.com/torvalds/linux/commit/df0108c5da561c66c333bb46bfe3c1fc65905898
patch比较简单， 下面摘录了一部分关键修改~~



在加入listen socket的sk_sleep队列 的唤醒队列里使用了 add_wait_queue_exculsive()函数，  当tcp 收到 
三次握手最后一个 ack 报文时调用sock_def_readable时，只唤醒一个等待源， 从而避免’惊群‘.
调用栈如下：

[cpp]  view plain  copy
  1. //  tcp_v4_do_rcv()  
  2. //  
  3. //  -->tcp_child_process()  
  4. //  
  5. //  --->sock_def_readable()  
  6. //  
  7. //  ---->wake_up_interruptible_sync_poll()  
  8. //  
  9. //  ----->__wake_up_sync_key()  
Epoll 新增 EPOLLEXCLUSIVE 选项解决了新建连接的’惊群‘问题
mumumuwudi的博客
01-25 7780
epoll最终和accept一样解决了新建连接的惊群问题 patch地址：  https://github.com/torvalds/linux/commit/df0108c5da561c66c333bb46bfe3c1fc65905898 patch比较简单， 下面摘录了一部分关键修改~~ 在加入listen socket的sk_sleep队列 的唤醒队列里使用了 add_wait
epoll 惊群
spch2008的专栏
01-15 4750
起因： 最近，一直在学习nginx。对于事件模块所解决的”惊群“现象完全不明白，遂产生了此文。 套接字： 可以将服务器端的套接字分为 监听套接字 与 连接套接字。 监听套接字负责等待用户连接，而通过accept，获得一个新的套接字， 该套接字为连接套接字，通过连接套接字与用户传送数据。 何谓惊群： nginx 分为 master 进程 与 worker 进程，worke
epoll在多线程中的应用-EPOLLEXCLUSIVE和REUSEPORT(一)
dream0130__的博客
01-16 4007
以下均为对epoll在多线程中的使用的一些笔记，如果有不对的地方，烦请指出 主要对于我所遇到的问题进行讨论，不会讨论代码如何改写，探讨如何解决这个问题 一.引言 这些问题均是我在编写我的Web服务器遇到的,我在编写多线程Web服务器的时候,思考如何利用多核的优势来编写Web服务器.在学习了muduo网络库之后，我的先前一个版本的Web服务器采用这种方式,一个master线程+多个工人线程,但是我觉...
深入了解epoll模型（特别详细）
木牛的博客
07-28 530
有的朋友可能对select也不是很了解啊，我这里稍微科普一下：网络连接，服务器也是通过文件描述符来管理这些连接上来的客户端，既然是供连接的服务器，那就免不了要接收来自客户端的消息。那么多台客户端，消息那么的多，要是漏了一条两条重要消息，那也不要用TCP了，那怎么办？前辈们就是有办法，轮询，轮询每个客户端文件描述符，查看他们是否带着消息，如果带着，那就处理一下；如果没带着，那就一边等着去。这就是select，轮询，颇有点领导下基层的那种感觉哈。
linux 多线程或多进程 epoll处理 accept 惊群问题
Linux高级开发的博客
02-21 3176
什么是惊群 简单说，惊群是因为多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），当时间发生时，就会唤醒所有等待的（休眠的）进程（线程）。但是事件只能被一个进程或线程处理，而其他进程（线程）获取失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群。 产生惊群的条件 多个进程或者多个线程 同时等待处理一个事件 具体场景复现 测试环境 : debian11 内核5.10.0-8 编译器 clang11 多线程和多进程在惊群问题上差不多，为了少些一点，下文中没有特殊说明，多线程 也包含
【高级IO】epoll的惊群效应
奇点的博客
10-28 554
epoll惊群效应主要发生在多进程（或多线程）环境中，当多个进程（或线程）同时阻塞等待同一个事件（如客户端连接请求）时，如果事件发生，就会唤醒所有等待的进程（或线程）。然而，由于事件只能被一个进程（或线程）处理，其他进程（或线程）在获取事件失败后会重新进入休眠状态。这种现象不仅浪费了系统资源，还降低了服务器的性能，被称为惊群效应。
accept和epoll惊群问题剖析
你又来看我了，一起学习吧
09-17 1978
文章目录惊群问题1. 不使用epoll/select的情况下多进程是如何共享端口监听的？2. epoll下共享监听端口的行为3. 内核对惊群效应的解决 惊群问题 1. 不使用epoll/select的情况下多进程是如何共享端口监听的？ 不使用多路复用的情况，进程要接收TCP连接必然要调用accept并且被阻塞，直到有一条连接到达。 单进程：一次只能处理一个连接，业务处理完毕之后close掉客户端连接，然后再调用accept。 多进程一：一个主进程accept连接，来了一个连接再fork一个子进程，把来的连
Linux上的TCP监听fd的accept/select/poll/epoll惊群问题
herongoal的博客
11-20 2289
同一个TCP端口(地址相同)是不能被多次绑定、监听的。因此，多线程程序无法并发地accept连接。而多进程可以并发accept新连接，办法就是先创建、绑定好端口，完成listen调用，然后fork出子进程，子进程继承父进程的文件描述符，然后子进程、父进程都可以accept。        很多石器时代的C/C++程序员认为，如果有一个新连接建立完成，此时阻塞在accept系统调用上的进程都会被唤...
epoll惊群效应深度剖析
guanggonglinux的博客
03-19 546
前情提要 我们一个基于Nginx+uWSGI+python的服务最近在高峰期经常会遇到负载高导致一些请求报错的情况，在单机qps只有差不多2000-3000左右的时候内核的cpu占用竟然高达超过20%，内核每秒上下文切换超过200w次，分析之后发现是nginx+uwsgi引发了惊群效应，导致性能急剧下降，通过上锁解决惊群问题之后服务恢复。基于这个排查过程，再加上我之前写过的关于epoll的分析最后也把惊群效应一笔带过，当时没有写完整，那咱这次就好好聊聊这个话题，我会先详细分析一下惊群效应产生的原因，然后拿.
epoll惊群效应
qq_41583040的博客
05-19 408
epoll惊群效应
惊群现象
nanjunxiao的专栏
06-20 6850
今天再看nginx架构发现了它也存在惊群现象，之前师兄的socks5代理服务器同样存在着惊群现象。 惊群（thundering herd）是指，只有一个子进程能获得连接，但所有N个子进程却都被唤醒了，这种情况将使性能受损。 nginx架构如上图所示，每个worker都是从master fork过来，在master里先建立好需listen的socket之后，然后fork出多个wo
epoll介绍
逆风水手的博客
04-04 338
EPOLL
惊群汇总（含epoll惊群）
编程爱好者的博客
03-14 785
原文查看https://www.cnblogs.com/Anker/p/7071849.html https://blog.youkuaiyun.com/lyztyycode/article/details/78648798 https://blog.youkuaiyun.com/dog250/article/details/80837278 汇总一下他们的博客供自己复习使用，我就不自己写了，他们...
accpet惊群和epoll惊群现象
我是一片云
03-01 918
 http://www.citi.umich.edu/projects/linux-scalability/reports/accept.html accpet惊群现象的解决（独占） https://github.com/torvalds/linux/commit/df0108c5da561c66c333bb46bfe3c1fc65905898 epoll惊群现象的解决主要参考上面的两篇文章在做负...
Linux 中的 epoll 原理及使用
热门推荐
私房菜
02-12 1万+
epoll 简介 epoll是Linux内核中的一种可扩展IO事件处理机制，最早在 Linux 2.5.44内核中引入，可被用于代替POSIX select 和 poll 系统调用，并且在具有大量应用程序请求时能够获得较好的性能（ 此时被监视的文件描述符数目非常大，与旧的 select 和 poll 系统调用完成操作所需 O(n) 不同， epoll能在O(1)时间内完成操作，所以性能相当高）...
Linux Epoll 一网打尽
weixin_46837673的博客
04-11 279
1 前言 epoll利用了Linux中的重要数据结构 wait queue, 有了select的基础，其实epoll就没那么复杂了。 通过阅读本文 ，你除了可以了解到epoll的原理外，还可以搞清epoll存不存在惊群问题，LT和 ET模式在实现上有什么 区别，epoll和select相比有什么不同， epoll是如何处理多核并发的等等问题 。当然内容难免有疏漏之处，请大家多多指证。 2 主要数据...
select、poll、epoll的使用
dengwodaer的博客
01-12 295
select、poll、epoll的使用 首先我们从数据结构上的不同来看待linux给我们提供的用于监控fd是否处于读写状态的API之间的差异: 1. select int select(int nfds, fd_set *readfds, fd_set *writefds,fd_set *exceptfds, struct timeval *timeout); select允许程序监控三种类型的fd：可读的fd、可写的fd、异常的fd，nfds=1 +max(*readfds,*writefds,*e
【epoll的实现原理】
最新发布
hw1287789687的专栏
03-16 1243
高效事件管理：红黑树和就绪列表的组合，实现快速注册与精准通知。减少系统调用：一次epoll_wait批量返回多个事件，避免select的多次遍历。灵活触发模式：ET模式在极端高并发下显著降低CPU占用。通过以上机制，epoll在处理数十万并发连接时仍能保持低延迟与高吞吐，成为现代高性能服务器的核心基础。
epoll多路复用-----epoll_create1()、epoll_ctl()、epoll_wait()
displayMessage的博客
07-22 5873
int epoll_create1(int flags); int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);
nginx 惊群
03-15
<think>嗯，用户想了解Nginx中惊群现象的解决方案和原理。首先，我需要回忆一下惊群效应是什么。根据之前的引用，惊群效应指的是当多个进程或线程同时等待同一个资源时，资源就绪导致所有等待者都被唤醒，但最终只有一个能获得资源，其他只能重新进入等待，这样导致性能浪费。 接下来，用户提到了Nginx的解决方案。根据引用[3]和[4]，Linux本身部分解决了accept惊群，但epoll在fork之后仍有问题。Nginx使用了自实现的互斥锁，也就是ngx_shmtx_t结构体中的锁机制。 然后，我需要解释Nginx的具体解决步骤。根据引用[4]，Nginx的worker进程在监听端口时，会通过共享锁来避免同时处理事件。每个worker进程在监听事件前会尝试获取锁，只有成功获取锁的进程才能处理事件，其他进程则继续等待。这样避免了多个进程被同时唤醒。 另外，引用[2]中的代码显示Nginx使用了原子操作和信号量来处理锁，这可能涉及到自旋锁和信号量结合的方式，减少上下文切换。spin字段可能用于控制自旋次数，优化性能。 可能用户还关心为什么传统方法会有问题，比如频繁的上下文切换，而Nginx的锁机制如何优化这一点。需要说明Nginx通过竞争锁的方式，确保只有一个worker进程处理连接，减少无效唤醒。 最后，生成相关问题时要覆盖原理、锁实现、性能优化、适用场景以及与其他方案对比等方面，确保用户能全面理解。</think>### Nginx惊群现象的解决方案与原理 #### 1. 惊群现象的定义 在Nginx多进程模型中，当客户端发起新连接请求时，所有监听了相同端口的`worker`进程会被**同时唤醒**，但最终只有一个进程能成功处理该连接，其他进程因“事件失效”而重新休眠。这种**无效唤醒导致的资源浪费**被称为惊群效应[^3][^4]。 #### 2. Nginx的解决方案 ##### (1) **共享锁机制** Nginx通过`ngx_shmtx_t`结构体实现进程间共享锁，关键代码定义如下[^2]： ```c typedef struct { #if (NGX_HAVE_ATOMIC_OPS) ngx_atomic_t *lock; // 原子锁指针 #if (NGX_HAVE_POSIX_SEM) ngx_atomic_t *wait; // 等待计数器 ngx_uint_t semaphore; sem_t sem; // POSIX信号量 #endif #else ngx_fd_t fd; // 文件描述符（非原子操作时使用） u_char *name; #endif ngx_uint_t spin; // 自旋次数控制 } ngx_shmtx_t; ``` - **原子锁（`lock`）**：通过原子操作实现**非阻塞竞争**，避免进程阻塞 - **信号量（`sem`）**：在竞争失败时，通过信号量挂起进程，减少CPU空转 - **自旋控制（`spin`）**：通过`spin`参数设置自旋次数，平衡CPU消耗与响应速度 ##### (2) 工作流程 1. **事件监听阶段** 所有`worker`进程通过`epoll_wait()`监听端口事件[^4] 2. **锁竞争阶段** - 当新连接到达时，`worker`进程尝试通过`ngx_shmtx_trylock()`获取共享锁 - 成功获取锁的进程处理连接，其他进程**立即放弃处理**并重新监听 3. **负载均衡** 通过`ngx_accept_disabled`变量实现进程间的**动态负载均衡**，避免某个进程长期独占锁 #### 3. 性能优化原理 | 传统惊群问题 | Nginx解决方案 | |------------------------------|-----------------------------| | 所有进程被唤醒→上下文切换 | 仅一个进程被唤醒→减少切换 | | 频繁的无效系统调用 | 原子操作+信号量减少系统调用 | | 固定进程负载分配 | 动态权重调整负载均衡 | 该方案将惊群效应发生的概率从$O(n)$降低到$O(1)$（n为进程数），实测中可减少约80%的无效上下文切换[^1]。 #### 4. 适用场景 - **高并发连接**：适用于`keepalive`长连接较少的场景 - **短时请求**：对连接建立阶段的优化效果最显著 - **Linux 2.6+系统**：依赖内核的`EPOLLEXCLUSIVE`特性[^3]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值