Nginx 之 I/O模型介绍
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Nginx 之 I/O模型介绍相关的知识,希望对你有一定的参考价值。
1 概述
I指从网络中读取主机的信息,O指从主机磁盘中读出数据响应给用户
I/O分为两种:
.网络IO:本质是socket读取
.磁盘IO:每次磁盘IO,都要经由两个阶段:
.第一步:将数据从文件先加载至内核内存空间(缓冲区),等待数据准备完成,时间较长
.第二步:将数据从内核缓冲区复制到用户空间的进程的内存中,时间较短
本文将介绍五种I/O模型,同时介绍I/O模型的具体实现
2 I/O模型分类
.同步/异步:关注的是消息通知机制
.同步:synchronous,调用者自已主动等待被调用者返回消息,才能继续执行
.异步:asynchronous,被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态。
.阻塞/非阻塞:关注调用者在等待结果返回之前所处的状态
.阻塞:blocking,指IO操作需要彻底完成后才返回到用户空间,调用结果返回之前,调用者被挂起
.非阻塞:nonblocking,指IO操作被调用后立即返回给用户一个状态值,无需等到IO操作彻底完成,最终的调用结果返回之前,调用者不会被挂起
可以是组合模型,如同步非阻塞,同步阻塞,异步非阻塞,异步阻塞
.I/O模型:企业一般用到以下的类型:阻塞型、非阻塞型、复用型、信号驱动型、异步
2.1 同步阻塞IO模型
PIO是指CPU参与IO过程
DMA,直接内存访问,值涉及磁盘访问的时候,CPU不全程参与数据转发过程,而是内核发指令给磁盘进行处理。目前DMA是主流。磁盘会将数据发给内核的缓存区,这样下次访问相同数据的时候可以加快访问数据
进程通过系统调用和内核进行通信
.同步阻塞IO模型是最简单的IO模型,用户线程在内核进行IO操作时被阻塞。
.用户线程通过系统调用read发起IO读操作,由用户空间转到内核空间。内核等到数据包到达后,然后将接收的数据拷贝到用户空间,完成read操作。
.用户需要等待read将数据读取到buffer后,才继续处理接收的数据。整个IO请求的过程中,用户线程是被阻塞的,这导致用户在发起IO请求时,不能做任何事情,对CPU的资源利用率不够。
2.2 同步非阻塞IO模型
.用户线程发起IO请求时立即返回。但并未读取到任何数据,用户线程需要不断地发起IO请求,直到数据到达后,才真正读取到数据,继续执行。即“轮询”机制
.整个IO请求的过程中,虽然用户线程每次发起IO请求后可以立即返回,但是为了等到数据,仍需要不断地轮询、重复请求,消耗了大量的CPU的资源
.是比较浪费CPU的方式,一般很少直接使用这种模型,而是在其他IO模型中使用非阻塞IO这一特性
2.3 IO多路复用模型
这里多了一个select,相当于是多了一个代理,把阻塞挡在了前端,减少了服务器的工作负载。可以同时监控多个请求
select可以理解为现实生活中的传达室,由传达室统一发通知给对应的用户做对应的事情
.本模型会阻塞进程,但是进程是阻塞在select或者poll这两个系统调用上,而不是阻塞在真正的IO操作上
.用户首先将需要进行IO操作添加到select中,继续执行做其他的工作(异步),同时等待select系统调用返回。当数据到达时,IO被激活,select函数返回。用户线程正式发起read请求,读取数据并继续执行。
.从流程上来看,使用select函数进行IO请求和同步阻塞模型没有太大的区别,甚至还多了添加监视IO,以及调用select函数的额外操作,效率更差。并且阻塞了两次,但是第一次阻塞在select上时,select可以监控多个IO上是否已有IO操作准备就绪,即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种,一次只能监控一个IO
.虽然上述方式允许单线程内处理多个IO请求,但是每个IO请求的过程还是阻塞的(在select函数上阻塞),平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求,然后去做自己的事情,等到数据到来时再进行处理,则可以提高CPU的利用率
.IO多路复用是最常使用的IO模型,但是其异步程度还不够“彻底”,因为它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO模型,而非真正的异步IO
.IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取,它就通知该进程
.IO多路复用适用如下场合:
.当客户处理多个描述符时(一般是交互式输入和网络套接口),必须使用I/O复用
.当一个客户同时处理多个套接口时,这种情况是可能的,但很少出现
.当一个TCP服务器既要处理监听套接口,又要处理已连接套接口,一般也要用到I/O复用。
.当一个服务器即要处理TCP,又要处理UDP,一般要使用I/O复用
.当一个服务器要处理多个服务或多个协议,一般要使用I/O复用
2.4 信号驱动IO模型
.信号驱动IO:signal-driven I/O
.就是说用户进程可以通过sigaction系统调用注册一个信号处理程序,然后主程序可以继续向下执行,当有IO操作准备就绪时,由内核通知触发一个SIGIO信号处理程序执行,然后将用户进程所需要的数据从内核空间拷贝到用户空间
.此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行,只要等待来自信号处理函数的通知,但是,该模型并不常用。
2.5 异步IO模型:
这个模型不阻塞,其他模型都是要阻塞的。这个过程进程比较空闲,大部分工作是内核完成,应用进程比较空闲,就能支持更多的并发连接
.异步IO与信号驱动IO最主要的区别是信号驱动IO是由内核通知何时可以进行IO操作,而异步IO则是由内核告诉我们IO操作何时完成了。具体来说就是,信号驱动IO当内核通知触发信号处理程序时,信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到用户空间缓冲区这个阶段,而异步IO直接是在第二个阶段完成后内核直接通知可以进行后续操作了
.相比于IO多路复用模型,异步IO并不十分常用,不少高性能并发服务程序使用IO多路复用模型+多线程任务处理的架构基本可以满足需求。况且目前操作系统对异步IO的支持并非特别完善,更多的是采用IO多路复用模型模拟异步IO的方式(IO事件触发时不直接通知用户线程,而是将数据读写完毕后放到用户指定的缓冲区中)
2.6 五种I//O模型总结
异步是被通知,全程非阻塞。其他四个模型都有阻塞
目前,主要用的I/O模型是多路复用或者信号驱动。
3 I/O模型的具体实现
.主要实现方式有以下几种:
.Select:Linux实现,对应I/O复用模型,BSD4.2最早实现
.Poll:Linux实现,对应I/O复用模型,System V unix最早实现
.Epoll:Linux实现,对应I/O复用模型,具有信号驱动I/O模型的某些特性,nginx用的的是Epoll,所以性能更好,而apache用的是select,性能相对较差
.Kqueue:FreeBSD实现,对应I/O复用模型,具有信号驱动
./dev/poll:SUN的Solaris实现,对应I/O复用模型,具有信号驱动I/O模型的某些特性
.Iocp Windows实现,对应第5种(异步I/O)模型
select/poll/epoll对比
其中
遍历相当于查看所有的位置
回调相当于查看对应的位置
.Select
POSIX所规定,目前几乎在所有的平台上支持,其良好跨平台支持也是它的一个优点,本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理
.缺点
.单个进程可监视的fd数量被限制,即能监听端口的数量有限,数值存在如下文件里
cat /proc/sys/fs/file-max
.对socket是线性扫描,即采用轮询的方法,效率较低
.select采取了内存拷贝方法来实现内核将FD消息通知给用户空间,这样一个用来存放大量fd的数据结构,这样会使得用户空间和内核空间在传递该结构时复制开销大
.poll
.本质上和select没有区别,它将用户传入的数组拷贝到内核空间,然后查询每个fd对应的设备状态
.其没有最大连接数的限制,原因是它是基于链表来存储的
.大量的fd的数组被整体复制于用户态和内核地址空间之间,而不管这样的复制是不是有意义
.poll特点是“水平触发”,如果报告了fd后,没有被处理,那么下次poll时会再次报告该fd
.边缘触发:只通知一次,epoll用的就是边缘触发
.epoll
在Linux2.6内核中提出的select和poll的增强版本
.支持水平触发和边缘触发,最大的特点在于边缘触发,它只告诉进程哪些fd刚刚变为就绪态,并且只会通知一次
.使用“事件”的就绪通知方式,通过epoll_ctl注册fd,一旦该fd就绪,内核就会采用类似callback的回调机制来激活该fd,epoll_wait便可以收到通知
.优点:
.没有最大并发连接的限制:能打开的FD的上限远大于1024(1G的内存能监听约10万个端口)
.效率提升:非轮询的方式,不会随着FD数目的增加而效率下降;只有活跃可用的FD才会调用callback函数,即epoll最大的优点就在于它只管理“活跃”的连接,而跟连接总数无关
.内存拷贝,利用mmap()文件映射内存加速与内核空间的消息传递;即epoll使用mmap减少复制开销
文件映射内存直接通过地址空间访问,效率更高,把文件映射到内存中。
本文出自 “阳光运维” 博客,请务必保留此出处http://ghbsunny.blog.51cto.com/7759574/1976130
以上是关于Nginx 之 I/O模型介绍的主要内容,如果未能解决你的问题,请参考以下文章