select的本质是采用32个整数的32位，即32*32= 1024来标识，fd值为1-1024。当fd的值超过1024限制时，就必须修改FD_SETSIZE的大小。这个时候就可以标识32*max值范围的fd。
select，poll，epoll 都是 操作系统实现 IO 多路复用的机制。 我们知道，I/O 多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是 读就绪或者写就绪），能够通知程序进行相应的读写操作。那么这三种机制有什 么区别呢。
我们知道Tornado 优秀的大并发处理能力得益于它的 web server 从底层开始就自己实现了一整套基于 epoll 的单线程异步架构，其他 web 框架比如Django或者Flask的自带 server 基本是基于 wsgi 写的简单服务器，并没有自己实现底层结构。而tornado.ioloop 就是 tornado web server 最底层的实现。
select函数监控3类文件描述符，调用select函数后会阻塞，直到描述符fd准备就绪（有数据可读、可写、异常）或者超时，函数便返回。 当select函数返回后，可通过遍历描述符集合，找到就绪的描述符。
今天转载了一篇文章，对如上标题分析的很到位（很容易理解） 这个观点，阿铭不是绝对地赞同。原因如下： 1 如果网站为php站点，抛除静态的页面、图片之类的请求，单纯说php脚本这种请求，无论是apache还是nginx，性能旗鼓相当。因为，这种动态的请求，瓶颈不在web server本身上，而是在php连接的后端MySQL上，MySQL查询有性能问题，nginx跑再快也是没有任何意义的。就好比一台服务器cpu配置很高，但是磁盘比较差，那这个牛逼的cpu就没有啥意义了。 2 apache在最新版的2.4默认使
不同于传统的“一个进程处理一个客户端请求”的方式，IO复用可以让一个进程处理多个客户端的请求，更加节省资源。
I/O模型主要包括：阻塞IO、非阻塞IO、I/O 多路复用、异步I/O和信号I/O;
select本质上是通过设置或检查存放fd标志位的数据结构进行下一步处理。 这带来缺点：
它仅仅知道了，有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。
epoll是select/poll的强化版，都是多路复用的函数，epoll有了很大的改进。 epoll的功能 1、支持监听大数目的socket描述符 一个进程内，select能打开的fd是有限制的，有宏FD_SETSIZE设置，默认值是1024.z在某些时候，这个数值是远远不够用的。解决方法有两种，已是修改宏然后再重新编译内核，但与此同时会引起网络效率的下降;二是使用多进程来解决，但是创建多个进程是有代价的，而且进程间数据同步没有多线程间方便。而epoll没有这个限制，它所支持的最大FD上限远远大于
http://blog.csdn.net/lingfengtengfei/article/details/12392449
epoll 是 linux 内核为处理大批量文件描述符而对 poll 进行的改进版本，是 linux 下多路复用 IO 接口 select/poll 的增强版本，显著提高了程序在大量并发连接中只有少量活跃的情况下的CPU利用率。 在获取事件时，它无需遍历整个被侦听描述符集，只要遍历被内核 IO 事件异步唤醒而加入 ready 队列的描述符集合就行了。 epoll 除了提供 select/poll 所提供的 IO 事件的电平触发，还提供了边沿触发，，这样做可以使得用户空间程序有可能缓存 IO 状态，减少 epoll_wait 或 epoll_pwait 的调用，提高程序效率。
在上文《socket网络编程（二）—— 实现持续发送》我们提到了多客户端的时候，多台客户端发送数据到服务端的话，只能有一台客户端可以正常发送和接受数据，另外一台完全没有反应，那这个问题怎么解决呢？很多人可能第一反应想到利用多线程技术，线程多的话用线程池来维护。的确，多线程确实可以实现这个效果，但是，可能很多看见这个但是就不怎么开心了，却不知很多科学科技的进步都是这个但是引发的。但是一个多线程编程很麻烦又容易出错，二是如果连接有几千个的话，线程间切换的开销确实是很大。如果能够在一个线程里就实现这个效果的话，那该多好啊！
高性能是每个程序员的追求，无论写一行代码还是做一个系统，都希望能够达到高性能的效果。高性能架构设计主要集中在两方面：
早期操作系统通常将进程中可创建的线程数限制在一个较低的阈值，大约几百个。因此， 操作系统会提供一些高效的方法来实现多路IO，例如Unix的select和poll。现代操作系统中，线程数已经得到了极大的提升，如NPTL线程软件包可支持数十万的线程。
I/O Multiplexing 又被称为 Event Driven I/O, 它可以让单个进程具有处理多个 I/O 事件的能力.
同步阻塞IO在等待数据就绪上花去太多时间，而传统的同步非阻塞IO虽然不会阻塞进程，但是结合轮询来判断运维
一、用select实现的并发服务器，能达到的并发数，受两方面限制 1、一个进程能打开的最大文件描述符限制。这可以通过调整内核参数。可以通过ulimit -n来调整或者使用setrlimit函数设置，
作者：jaydenwen，腾讯 pcg 后台开发工程师 在互联网中提起网络，我们都会避免不了讨论高并发、百万连接。而此处的百万连接的实现，脱离不了网络 IO 的选择，因此本文作为一篇个人学习的笔记，特此进行记录一下整个网络 IO 的发展演变过程。以及目前广泛使用的网络模型。 1.网络 IO 的发展 在本节内容中，我们将一步一步介绍网络 IO 的演变发展过程。介绍完发展过程后，再对网络 IO 中几组容易混淆的概念进行对比、分析。 1.1 网络 IO 的各个发展阶段 通常，我们在此讨论的网络 IO 一
Nginx因为它的稳定性、丰富的模块库、灵活的配置和低系统资源的消耗而闻名．业界一致认为它是Apache2.2＋mod_proxy_balancer的轻量级代替者，不仅是因为响应静态页面的速度非常快，而且它的模块数量达到Apache的近2/3。对proxy和rewrite模块的支持很彻底，还支持mod_fcgi、ssl、vhosts ，适合用来做mongrel clusters的前端HTTP响应。 nginx和Apache一样使用模块化设计，nginx模块包括内置模块和第三方模块，其中内置模块中包含主模块和事件模块。
对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待数据到达时，它被复制到内核中的某个缓冲区。第二步就是把数据从内核缓冲区复制到应用进程缓冲区。
什么是epoll epoll是什么？按照man手册的说法：是为处理大批量句柄而作了改进的poll。当然，这不是2.6内核才有的，它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。 epoll的相关系统调用 epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。 1. int ep
nginx系列之一：nginx入门 nginx系列之二：配置文件解读 nginx系列之三：日志配置 nginx系列之四：web服务器 nginx系列之五： 负载均衡 nginx系列之六：cache服务 nginx系列之七：限流配置 nginx系列之八：使用upsync模块实现负载均衡
说到IO模型，都会牵扯到同步、异步、阻塞、非阻塞这几个词。从词的表面上看，很多人都觉得很容易理解。但是细细一想，却总会发现有点摸不着头脑。自己也曾被这几个词弄的迷迷糊糊的，每次看相关资料弄明白了，然后很快又给搞混了。
1.先说select在多路IO中的限制： 1）linux中每个程序能够打开的最多文件描述符是有限制的。默认是1024. 可以通过ulimit -n进行查看和修改：
http://www.cnblogs.com/Anker/archive/2013/08/15/3261006.html
本文经 CyC2018 大佬授权发表，更多技术内容请前往 https://github.com/CyC2018/CS-Notes 查看。
首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。
阻塞方式block，顾名思义，就是进程或是线程执行到这些函数时必须等待某个事件的发生，如果事件没有发生，进程或线程就被阻塞，函数不能立即返回。 使用Select就可以完成非阻塞（所谓非阻塞方式non- block，就是进程或线程执行此函数时不必非要等待事件的发生，一旦执行肯定返回，以返回值的不同来反映函数的执行情况，如果事件发生则与阻塞方式相同，若事件没有发生则返回一个代码来告知事件未发生，而进程或线程继续执行，所以效率较高）方式工作的程序，它能够监视我们需要监视的文件描述符的变化情况读写或是异常。
我们都知道，一般使用printf的打印都会直接打印在终端，如果想要保存在文件里呢？我想你可能想到的是重定向。例如：
作者：mingguangtu，腾讯 IEG 后台开发工程师 select/poll/epoll 是 Linux 服务器提供的三种处理高并发网络请求的 IO 多路复用技术，是个老生常谈又不容易弄清楚其底层原理的知识点，本文打算深入学习下其实现机制。 Linux 服务器处理网络请求有三种机制，select、poll、epoll，本文打算深入学习下其实现原理。 吃水不忘挖井人，最近两周花了些时间学习了张彦飞大佬的文章 图解 | 深入揭秘 epoll 是如何实现 IO 多路复用的 和其他文章 ，及出版的书籍《深入理
Linux 服务器处理网络请求有三种机制，select、poll、epoll，本文打算深入学习下其实现原理。
我们都知道unix世界里、一切皆文件、而文件是什么呢？文件就是一串二进制流而已、不管socket、还是FIFO、管道、终端、对我们来说、一切都是文件、一切都是流、在信息交换的过程中、我们都是对这些流进行数据的收发操作、简称为I/O操作(input and output)、往流中读出数据、系统调用read、写入数据、系统调用write、不过话说回来了、计算机里有这么多的流、我怎么知道要操作哪个流呢？做到这个的就是文件描述符、即通常所说的fd(file descriptor)、一个fd就是一个整数、所以对这个整数的操作、就是对这个文件（流）的操作、我们创建一个socket、通过系统调用会返回一个文件描述符、那么剩下对socket的操作就会转化为对这个描述符的操作、不能不说这又是一种分层和抽象的思想、
以下测试都是在没有优化或修改内核的前提下测试的结果 1. 测试目的：ext3文件系统下filename最大字符长度 测试平台：RHEL5U3_x64 测试过程： LENTH=`for i in {1..255};do for x in a;do echo -n $x;done;done` touch $LENTH 当增加到256时，touch报错，File name too long linux系统下ext3文件系统内给文件/目录命名，最长只能支持127个中文字符，英文则可以支持255个字符 2. 测试目的：ext3文件系统下一级子目录的个数限制 测试平台：RHEL5U3_x64 测试过程： [root@fileserver maxdir]# for i in {1..32000};do mkdir $i;done mkdir: cannot create directory `31999': Too many links mkdir: cannot create directory `32000': Too many links ext3文件系统一级子目录的个数为31998(个)。 Linux为了cpu的搜索效率而规定的,要想改变数目大概要重新编译内核. 3. 测试目的：ext3文件系统下单个目录里的最大文件数 测试平台: RHEL5U3_x64 测试过程： 单个目录下的最大文件数似乎没什么特别限制，也是受限于所在文件系统的inode数限制： df -i或者使用tune2fs -l /dev/sdaX或者dumpe2fs -h /dev/sdaX查看可用inode数，后两个命令 输出结果是一样的，但是跟df所得出的可用inode数会有些误差，至今不明白什么原因。 网上常用两种解决办法： 1） 重新mkfs，ext3默认block大小4096 Bytes，block设置小一些inode数设置大一些 2） 使用loopback文件系统临时解决： 在/usr中（也可以在别处）创建一个大文件，然后做成loopback文件系统，将原来的文件移到这个 文件系统中，并将它mount到/usr下合适的位置。这样可以大大减少你/usr中的文件数目。但是系统 性能会有点损失。 4. 测试目的： 打开文件数限制（文件句柄、文件描述符） 测试平台： RHEL5U3_x64 ulimit -n 65535设置，或者/etc/security/limit.conf里设置用户打开文件数、进程数、CPU等
常见的多路复用实现所依赖的系统调用方法包括select(),poll(),epoll(). 不同的平台, 具体的系统调用方法也不同.
为了讲多路复用，当然还是要跟风，采用鞭尸的思路，先讲讲传统的网络 IO 的弊端，用拉踩的方式捧起多路复用 IO 的优势。
那么为了解决read函数阻塞后，其他客户端无法连接服务端的问题。我们第一个想到的就是，把原有的串行逻辑修改为并行。也就是说，既然read会阻塞整个流程那么我们可不可以把read函数读取数据的这块逻辑，单独拉到一个子线程中进行处理。那么即使这个子线程中的read阻塞了，也不会影响主线程中客户端与服务端直接的连接逻辑。如下所示：
今天给大家分享一篇万字长文《微言 Netty：百万并发基石上的 epoll 之剑》。
相信很多人知道石中剑这个典故，在此典故中，天命注定的亚瑟很容易的就拔出了这把石中剑，但是由于资历不被其他人认可，所以他颇费了一番周折才成为了真正意义上的英格兰全境之王，亚瑟王。
本篇是高性能、高并发系列的第三篇，承接上文《读取文件时程序经历了什么》，在讲解了进程、线程以及I/O后，我们来到了高并发中又一关键技术，即I/O多路复用。
本文主要探讨了在Linux系统中，文件锁的概念、实现方式、相关命令和应用场景。文件锁主要用于保护文件系统，避免因多个进程并发访问同一文件而导致的竞争条件。通过使用锁命令和工具，可以有效地管理文件锁，确保文件系统的安全性和稳定性。
👆点击“博文视点Broadview”，获取更多书讯 程序员编写代码执行I/O操作最终都逃不过文件这个概念。 在Unix/Linux世界中，文件是一个很简单的概念，作为程序员我们只需要将其理解为一个N字节的序列就可以了： b1, b2, b3, b4, ....... , bN 实际上，所有的I/O设备都被抽象为了文件这个概念，一切皆文件（Everything is File），磁盘、网络数据、终端，甚至进程间通信工具管道pipe等都被当成文件对待。 所有的I/O操作也都可以通过文件读写来实现，这一抽
Nachos 实现了两套文件系统，一套是FILESYS_STUB，它是建立在 UNIX 文件系统之上的，而不使用 Nachos 的模拟磁盘，在Makefile文件大概194行使用了该宏定义开关；另一套则是Nachos本身的文件系统，它是实现在Nachos的虚拟磁盘上的。由于Nachos本身的文件系统我还没完全弄明白，所以本文使用的是FILESYS_STUB文件系统。
作为即时通讯技术的开发者来说，高性能、高并发相关的技术概念早就了然与胸，什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来，又或许你对具有这些技术特征的技术框架比如：Java的Netty、Php的workman、Go的nget等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时，方知自已所掌握的不过是皮毛。
多路io转发服务器模型也是为了解决大并发多客户端场景下的问题，比多进程、多线程开销要少。多进程多线程常规情况下都是使用 accept 或 read 函数在阻塞等接收客户端发送过来的数据，而多路io模型则是提供了一个系统函数，该函数负责阻塞判断各路被监控的文件描述符是否有数据读取或写入操作，当有数据读取或写入时再让 accept 或 read 去直接处理从而不会阻塞，系统函数可能会同时返回多个有数据的文件描述符等待后面的代码处理，所以效率上要比多进程和多线程同时只在一个位置阻塞获取数据效率要高一些，下面就介绍一下多路 io 模型 select 和 poll，poll 模型较 select 模型还存在一些优势，在本文后面将介绍。
那么在io事件中，g是怎么把事件交还给g0的呢？这时候就牵扯到我们今天的主角----netpoll。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
