|
|
|
|
公众号矩阵

从头捋了一遍Epoll原理,收获颇丰!

Epoll 是个很老的知识点,是后端工程师的经典必修课。这种知识具备的特点就是研究的人多,所以研究的趋势就会越来越深。当然分享的人也多,由于分享者水平参差不齐,也产生的大量错误理解。

作者:冯志明来源:Qunar技术沙龙|2021-03-11 07:14

Epoll 是个很老的知识点,是后端工程师的经典必修课。这种知识具备的特点就是研究的人多,所以研究的趋势就会越来越深。当然分享的人也多,由于分享者水平参差不齐,也产生的大量错误理解。

图片来自 Pexels

今天我再次分享 epoll,肯定不会列个表格,对比一下差异,那就太无聊了。

我将从线程阻塞的原理,中断优化,网卡处理数据过程出发,深入的介绍 epoll 背后的原理,最后还会 diss 一些流行的观点。相信无论你是否已经熟悉 epoll,本文都会对你有价值。

正文开始前,先问大家几个问题:

①epoll 性能到底有多高。很多文章介绍 epoll 可以轻松处理几十万个连接。而传统 IO 只能处理几百个连接,是不是说 epoll 的性能就是传统 IO 的千倍呢?

②很多文章把网络 IO 划分为阻塞,非阻塞,同步,异步。并表示:非阻塞的性能比阻塞性能好,异步的性能比同步性能好。

如果说阻塞导致性能低,那传统 IO 为什么要阻塞呢?epoll 是否需要阻塞呢?Java 的 NIO 和 AIO 底层都是 epoll 实现的,这又怎么理解同步和异步的区别?

③都是 IO 多路复用。既生瑜何生亮,为什么会有 select,poll 和 epoll 呢?为什么 epoll 比 select 性能高?

PS:本文共包含三大部分:初识 epoll、epoll 背后的原理 、Diss 环节。本文的重点是介绍原理,建议读者的关注点尽量放在:“为什么”。

Linux 下进程和线程的区别其实并不大,尤其是在讨论原理和性能问题时,因此本文中“进程”和“线程”两个词是混用的。

初识 epoll

epoll 是 Linux 内核的可扩展 I/O 事件通知机制,其最大的特点就是性能优异。

下图是 libevent(一个知名的异步事件处理软件库)对 select,poll,epoll ,kqueue 这几个 I/O 多路复用技术做的性能测试。

很多文章在描述 epoll 性能时都引用了这个基准测试,但少有文章能够清晰的解释这个测试结果。

这是一个限制了 100 个活跃连接的基准测试,每个连接发生 1000 次读写操作为止。纵轴是请求的响应时间,横轴是持有的 socket 句柄数量。

随着句柄数量的增加,epoll 和 kqueue 响应时间几乎无变化,而 poll 和 select 的响应时间却增长了非常多。

可以看出来,epoll 性能是很高的,并且随着监听的文件描述符的增加,epoll 的优势更加明显。

不过,这里限制的 100 个连接很重要。epoll 在应对大量网络连接时,只有活跃连接很少的情况下才能表现的性能优异。

换句话说,epoll 在处理大量非活跃的连接时性能才会表现的优异。如果15000个 socket 都是活跃的,epoll 和 select 其实差不了太多。

为什么 epoll 的高性能有这样的局限性?问题好像越来越多了,看来我们需要更深入的研究了。

epoll 背后的原理

阻塞

①为什么阻塞

我们以网卡接收数据举例,回顾一下之前我分享过的网卡接收数据的过程。

为了方便理解,我尽量简化技术细节,可以把接收数据的过程分为四步:

  • NIC(网卡)接收到数据,通过 DMA 方式写入内存(Ring Buffer 和 sk_buff)。
  • NIC 发出中断请求(IRQ),告诉内核有新的数据过来了。
  • Linux 内核响应中断,系统切换为内核态,处理 Interrupt Handler,从RingBuffer 拿出一个 Packet, 并处理协议栈,填充 Socket 并交给用户进程。
  • 系统切换为用户态,用户进程处理数据内容。

网卡何时接收到数据是依赖发送方和传输路径的,这个延迟通常都很高,是毫秒(ms)级别的。而应用程序处理数据是纳秒(ns)级别的。

也就是说整个过程中,内核态等待数据,处理协议栈是个相对很慢的过程。这么长的时间里,用户态的进程是无事可做的,因此用到了“阻塞(挂起)”。

②阻塞不占用 CPU

阻塞是进程调度的关键一环,指的是进程在等待某事件发生之前的等待状态。

请看下表,在 Linux 中,进程状态大致有 7 种(在 include/linux/sched.h 中有更多状态):

从说明中其实就可以发现,“可运行状态”会占用 CPU 资源,另外创建和销毁进程也需要占用 CPU 资源(内核)。重点是,当进程被"阻塞/挂起"时,是不会占用 CPU 资源的。

换个角度来讲。为了支持多任务,Linux 实现了进程调度的功能(CPU 时间片的调度)。

而这个时间片的切换,只会在“可运行状态”的进程间进行。因此“阻塞/挂起”的进程是不占用 CPU 资源的。

另外讲个知识点,为了方便时间片的调度,所有“可运行状态”状态的进程,会组成一个队列,就叫“工作队列”。

③阻塞的恢复

内核当然可以很容易的修改一个进程的状态,问题是网络 IO 中,内核该修改那个进程的状态。

socket 结构体,包含了两个重要数据:进程 ID 和端口号。进程 ID 存放的就是执行 connect,send,read 函数,被挂起的进程。

在 socket 创建之初,端口号就被确定了下来,操作系统会维护一个端口号到 socket 的数据结构。

当网卡接收到数据时,数据中一定会带着端口号,内核就可以找到对应的 socket,并从中取得“挂起”进程的 ID。

将进程的状态修改为“可运行状态”(加入到工作队列)。此时内核代码执行完毕,将控制权交还给用户态。通过正常的“CPU 时间片的调度”,用户进程得以处理数据。

④进程模型

上面介绍的整个过程,基本就是 BIO(阻塞 IO)的基本原理了。用户进程都是独立的处理自己的业务,这其实是一种符合进程模型的处理方式。

上下文切换的优化

上面介绍的过程中,有两个地方会造成频繁的上下文切换,效率可能会很低:

  • 如果频繁的收到数据包,NIC 可能频繁发出中断请求(IRQ)。CPU 也许在用户态,也许在内核态,也许还在处理上一条数据的协议栈。但无论如何,CPU 都要尽快的响应中断。这么做实际上非常低效,造成了大量的上下文切换,也可能导致用户进程长时间无法获得数据。(即使是多核,每次协议栈都没有处理完,自然无法交给用户进程)
  • 每个 Packet 对应一个 socket,每个 socket 对应一个用户态的进程。这些用户态进程转为“可运行状态”,必然要引起进程间的上下文切换。

①网卡驱动的 NAPI 机制

在 NIC 上,解决频繁 IRQ 的技术叫做 New API(NAPI)。

原理其实特别简单,把 Interrupt Handler 分为两部分:

  • 函数名为 napi_schedule,专门快速响应 IRQ,只记录必要信息,并在合适的时机发出软中断 softirq。
  • 函数名为 netrxaction,在另一个进程中执行,专门响应 napi_schedule 发出的软中断,批量的处理 RingBuffer 中的数据。

所以使用了 NAPI 的驱动,接收数据过程可以简化描述为:

  • NIC 接收到数据,通过 DMA 方式写入内存(Ring Buffer 和 sk_buff)。
  • NIC 发出中断请求(IRQ),告诉内核有新的数据过来了。
  • driver 的 napi_schedule 函数响应 IRQ,并在合适的时机发出软中断(NET_RX_SOFTIRQ)。
  • driver 的 net_rx_action 函数响应软中断,从 Ring Buffer 中批量拉取收到的数据。并处理协议栈,填充 Socket 并交给用户进程。
  • 系统切换为用户态,多个用户进程切换为“可运行状态”,按 CPU 时间片调度,处理数据内容。

一句话概括就是:等着收到一批数据,再一次批量的处理数据。

②单线程的 IO 多路复用

内核优化“进程间上下文切换”的技术叫的“IO 多路复用”,思路和 NAPI 是很接近的。

每个 socket 不再阻塞读写它的进程,而是用一个专门的线程,批量的处理用户态数据,这样就减少了线程间的上下文切换。

作为 IO 多路复用的一个实现,select 的原理也很简单。所有的 socket 统一保存执行 select 函数的(监视进程)进程 ID。

任何一个 socket 接收了数据,都会唤醒“监视进程”。内核只要告诉“监视进程”,那些 socket 已经就绪,监视进程就可以批量处理了。

IO 多路复用的进化

①对比 epoll 与 select

select,poll 和 epoll 都是“IO 多路复用”,那为什么还会有性能差距呢?篇幅限制,这里我们只简单对比 select 和 epoll 的基本原理差异。

对于内核,同时处理的 socket 可能有很多,监视进程也可能有多个。所以监视进程每次“批量处理数据”,都需要告诉内核它“关心的 socket”。

内核在唤醒监视进程时,就可以把“关心的 socket”中,就绪的 socket 传给监视进程。

换句话说,在执行系统调用 select 或 epoll_create 时,入参是“关心的 socket”,出参是“就绪的 socket”。

而 select 与 epoll 的区别在于:

select (一次O(n)查找):

  • 每次传给内核一个用户空间分配的 fd_set 用于表示“关心的 socket”。其结构(相当于 bitset)限制了只能保存 1024 个 socket。
  • 每次 socket 状态变化,内核利用 fd_set 查询 O(1),就能知道监视进程是否关心这个 socket。
  • 内核是复用了 fd_set 作为出参,返还给监视进程(所以每次 select 入参需要重置)。

然而监视进程必须遍历一遍 socket 数组 O(n),才知道哪些 socket 就绪了。

epoll (全是O(1)查找):

  • 每次传给内核一个实例句柄。这个句柄是在内核分配的红黑树 rbr+双向链表 rdllist。只要句柄不变,内核就能复用上次计算的结果。
  • 每次 socket 状态变化,内核就可以快速从 rbr 查询O(1),监视进程是否关心这个 socket。同时修改 rdllist,所以 rdllist 实际上是“就绪的 socket”的一个缓存。
  • 内核复制 rdllist 的一部分或者全部(LT 和 ET),到专门的 epoll_event 作为出参。

所以监视进程,可以直接一个个处理数据,无需再遍历确认。

Select 示例代码:

Epoll 示例代码:

另外,epoll_create 底层实现,到底是不是红黑树,其实也不太重要(完全可以换成 hashtable)。

重要的是 efd 是个指针,其数据结构完全可以对外透明的修改成任意其他数据结构。

②API 发布的时间线

另外,我们再来看看网络 IO 中,各个 api 的发布时间线:

  • 1983,socket 发布在 Unix(4.2 BSD)
  • 1983,select 发布在 Unix(4.2 BSD)
  • 1994,Linux 的 1.0,已经支持 socket 和 select
  • 1997,poll 发布在 Linux 2.1.23
  • 2002,epoll 发布在 Linux 2.5.44

就可以得到两个有意思的结论:

  • socket 和 select 是同时发布的。这说明了,select 不是用来代替传统 IO 的。这是两种不同的用法(或模型),适用于不同的场景。
  • select、poll 和 epoll,这三个“IO 多路复用 API”是相继发布的。这说明了,它们是 IO 多路复用的 3 个进化版本。

因为 API 设计缺陷,无法在不改变 API 的前提下优化内部逻辑。所以用 poll 替代 select,再用 epoll 替代 poll。

总结

我们花了三个章节,阐述 epoll 背后的原理,现在用三句话总结一下:

  • 基于数据收发的基本原理,系统利用阻塞提高了 CPU 利用率。
  • 为了优化上线文切换,设计了“IO 多路复用”(和 NAPI)。
  • 为了优化“内核与监视进程的交互”,设计了三个版本的 API(select,poll,epoll)。

Diss 环节

讲完“epoll 背后的原理”,已经可以回答最初的几个问题。这已经是一个完整的文章,很多人劝我删掉下面的 diss 环节。

我的观点是:学习就是个研究+理解的过程。上面是研究,下面再讲一下我的个人“理解”,欢迎指正。

关于 IO 模型的分类

关于阻塞,非阻塞,同步,异步的分类,这么分自然有其道理。但是在操作系统的角度来看“这样分类,容易产生误解,并不好”。

①阻塞和非阻塞

Linux 下所有的 IO 模型都是阻塞的,这是收发数据的基本原理导致的。阻塞用户线程是一种高效的方式。

你当然可以写一个程序,socket 设置成非阻塞模式,在不使用监视器的情况下,依靠死循环完成一次 IO 操作。但是这样做的效率实在是太低了,完全没有实际意义。

换句话说,阻塞不是问题,运行才是问题,运行才会消耗 CPU。IO 多路复用不是减少了阻塞,是减少了运行。

上下文切换才是问题,IO 多路复用,通过减少运行的进程,有效的减少了上下文切换。

②同步和异步

Linux 下所有的 IO 模型都是同步的。BIO 是同步的,select 同步的,poll 同步的,epoll 还是同步的。

Java 提供的 AIO,也许可以称作“异步”的。但是 JVM 是运行在用户态的,Linux 没有提供任何的异步支持。

因此 JVM 提供的异步支持,和你自己封装成“异步”的框架是没有本质区别的(你完全可以使用 BIO 封装成异步框架)。

所谓的“同步“和”异步”只是两种事件分发器(event dispatcher)或者说是两个设计模式(Reactor 和 Proactor)。

都是运行在用户态的,两个设计模式能有多少性能差异呢?

  • Reactor 对应 Java 的 NIO,也就是 Channel,Buffer 和 Selector 构成的核心的 API。
  • Proactor对应 java 的 AIO,也就是 Async 组件和 Future 或 Callback 构成的核心的 API。

③我的分类

我认为 IO 模型只分两类:

  • 更加符合程序员理解和使用的,进程模型。
  • 更加符合操作系统处理逻辑的,IO 多路复用模型。

对于“IO 多路复用”的事件分发,又分为两类:Reactor 和 Proactor。

关于 mmap

epoll 到底用没用到 mmap?答案:没有!

这是个以讹传讹的谣言。其实很容易证明的,用 epoll 写个 demo。strace 一下就清楚了。

作者:冯志明

简介:2019 年至今负责搜索算法的相关工作,擅长处理复杂的业务系统,对底层技术有浓厚兴趣。

编辑:陶家龙

出处:转载自公众号Qunar技术沙龙(ID:QunarTL)

【编辑推荐】

  1. LA13 多天线技术【LTE技术与原理】
  2. 机器学习入门与中级——数学原理到百例代码演示
  3. 深入理解Spring事务原理
  4. 聊聊Thread类线程常用操作
  5. 从底层汇编理解C++多态原理
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

7人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

36人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

228人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微