Linux内核：进程管理——IO优化

Linux加油站

于 2023-04-24 15:36:34 发布

阅读量158

点赞数

文章标签： linux 进程管理 Linux内核

本文链接：https://blog.csdn.net/m0_74282605/article/details/130344317

版权

阻塞I/O，非阻塞IO，IO复用，信号驱动，异步IO
1. 其中阻塞IO就是那种recv, read，一直等，等到有了拷贝了数据才返回；
2. 非阻塞就是不用等，立即返回，设置描述符为非阻塞就行了，但是要进程自己一直检查是否可读；
3. IO复用其实也是阻塞的，不过可以用来等很多描述符；
4. 信号驱动采用信号机制等待；（信号通信，中断处理程序向进程发出信号）
5. 异步IO就不用等待了，当他告知你的时候，已经可以返回了，数据都拷贝好了。（aio_read略）
同步阻塞I/O，同步非阻塞IO
read+中断方式即为同步阻塞
read+轮询方式即为同步非阻塞

什么是IO复用？

对于一般IO，当数据未到达时，进程会阻塞，可以看出一个进程一次只能读写一个fd。IO多路复用就是让一个进程同时监听多个fd。select/poll/epoll对应的是IO复用模型，优势是能够监听多个socket。
select, poll是为了解決同时大量IO的情況（尤其网络服务器），但是随着连接数越多，性能越差，epoll是select和poll的改进方案，在 linux 上可以取代 select 和 poll，可以处理大量连接的性能问题。故只对epoll进行学习。
epoll分为两种工作方式LT和ET。LT(level triggered) 是默认/缺省的工作方式，同时支持 block和no_block socket；ET(edge-triggered) 是高速工作方式，仅支持no_block socket。LT可以理解为水平触发，只要有数据可以读，不管怎样都会通知。而ET为边缘触发，只有状态发生变化时才会通知，可以理解为电平变化。
LT模式下，只要内核缓冲区中还有未读数据，就会一直返回描述符的就绪状态，即不断地唤醒应用进程。在ET模式下，缓冲区从不可读变成可读，会唤醒应用进程，缓冲区数据变少的情况，则不会再唤醒应用进程。
水平触发优、缺点及应用场景：
优点：当进行socket通信的时候，保证了数据的完整输出，进行IO操作的时候，如果还有数据，就会一直的通知你。
缺点：由于只要还有数据，内核就会不停的从内核空间转到用户空间，所有占用了大量内核资源，试想一下当有大量数据到来的时候，每次读取一个字节，这样就会不停的进行切换。内核资源的浪费严重。效率来讲也是很低的。
应用场景：
边沿触发优、缺点及应用场景：
优点：每次内核只会通知一次，大大减少了内核资源的浪费，提高效率。
缺点：不能保证数据的完整。不能及时的取出所有的数据。
应用场景：处理单次大数据。使用non-block模式的socket。
对于nginx这种高性能服务器，ET模式是很好的，而其他的通用网络库，更多是使用LT，避免使用的过程中出现bug。

当数据到达，中断处理程序一步步向上调用，经过链路层（驱动）、网络车、传输层、并最终调用到回调函数，其回调过程如图红色箭头所示：

安装回调函数
把回调函数安装到每个被监听fd对应的socket上
ep_poll_callback执行任务：
将文件的epitem节点拷贝到rdlist链表上（就绪句柄拷贝到rdlist）
如果有进程在wq等待队列上（即有进程在调用epoll_wait等待），则唤醒，将之放入就绪队列。

被放入就绪队列的进程等待内核调度执行，epoll_wait会把rdlist上的epitem拷贝进入用户空间的txlist链表上，根据ET模式与LT模式的不同，其拷贝方式不同。
ET和LT模式下的epitem都可以通过插入红黑树时的回调（ep_poll_callback）方式加入rdlist从而唤醒epoll_wait，但LT模式下的epitem还可以通过txlist重新加入rdlist唤醒epoll_wait。所以ET模式下，fd就绪，只会被通知一次，而LT模式下只要满足相应读写条件就返回就绪（通过txlist加入rdlist）。

epoll_wait会回调fd的epoll_events中用户定义的相应的事件处理函数

内核资料直通车：Linux内核源码技术学习路线+视频教程代码资料

学习直通车：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈

对epoll的封装libevent

epoll是操作系统提供的API，epoll相关函数的形参也是操作系统提供的，故需要对epoll函数、epoll相关形参比如fd进行封装
event_base机构体即保存有fd信息，eventop封装有epoll，event则对epitem封装
event_base reactor：监听中断、
event_op event_handler
event_base_dispatch(封装有epoll) demultiplexer

reactor模式

Reactor 释义“反应堆”,是一种事件驱动机制。先向Reactor注册事件和回调函数，然后等事件发生时，reactor自动去调用对应的回调函数去处理事件（I/O 读写、定时和信号）。
使用 Reactor 模型,必备的几个组件:事件源、Reactor 框架、多路复用机制和事件处理程序
1) 事件源
Linux 上是文件描述符,Windows 上就是 Socket 或者 Handle 了,这里统一称为“句柄集”;程序在指定的句柄上注册关心的事件,比如 I/O 事件。
2) event demultiplexer——事件多路分发机制
由操作系统提供的 I/O 多路复用机制,比如 select 和 epoll。程序首先将其关心的句柄(事件源)及其事件注册到 event demultiplexer 上;当有事件到达时,event demultiplexer 会发出通知“在已经注册的句柄集中,一个或多个句柄的事件已经就绪”;程序收到通知后,就可以在非阻塞的情况下对事件进行处理了。对应到 libevent 中,依然是 select、poll、epoll 等,但是 libevent 使用结构体 eventop 进行了封装,以统一的接口来支持这些 I/O 多路复用机制,达到了对外隐藏底层系统机制的目的。
3) Reactor——反应器
Reactor,是事件管理的接口,内部使用 event demultiplexer 注册、注销事件;并运行事件循环,当有事件进入“就绪”状态时,调用注册事件的回调函数处理事件。对应到 libevent 中,就是 event_base 结构体。
4) Event Handler——事件处理程序
事件处理程序提供了一组接口,每个接口对应了一种类型的事件,供 Reactor 在相应的事件发生时调用,执行相应的事件处理。通常它会绑定一个有效的句柄。对应到 libevent 中,就是 event 结构体。

event_handler即event，绑定了fd（handle）和回调函数
dispatcher 监听事件的到达，根据不同的事件比如请求连接、可读等注册相应handler，并唤醒demultiplexer
demultiplexer 即epoll_wait 会阻塞、会唤醒for循环进程
dispatcher内有指向event_handler、demultiplexer的指针
多reactor即多个循环one thread per loop
主reactor负责accept，其它reactor负责read、write
read过程中把decode交给线程池（适用于密集计算，否则无需单独分配线程）

基本reactor

并发处理多个请求，实际上是在一个线程中完成。无法充分利用多核CPU
不适合执行时间比较长的服务，所以为了让客户感觉是在“并发”处理而不是“循环”处理，每个请求必须在相对较短时间内执行。
Nginx就是这种模型，因为http的应用场景是短链接

单线程+线程池

把非IO操作分离出来，适用于密集型计算

线程池大小的选择
如果池中执行任务时，密集计算所占时间比重为P（0<P<=1)，而系统一共有C个CPU，为了让C个CPU跑满而不过载，线程池大小的经验公式T=C/P，即T*P=C（让CPU刚好跑满）
假设C=8，P=1.0，线程池的任务完全密集计算，只要8个活动线程就能让CPU饱和
假设C=8，P=0.5，线程池的任务有一半是计算，一半是IO，那么T=16，也就是16个“50%繁忙的线程”能让8个CPU忙个不停。