- 主题:到底并行程序，用的是多线程还是多进程
【 在 zli07 的大作中提到: 】
: nginx 的并发高，靠的是异步 io，也就是 io 不会等待，实际上它是单线程+多进程模式：首先有个 master process，解析配置文件，然后根据配置 fork 出 n 个 worker process, 当客户端连接过来的时候，会有某一个 worker process 处理这个连接的请求，同时由于异步 io 的机制，一个进程可以同时处理很多个（成千上万）用户的请求。
epoll这种是不是需要手动修改linux中对进程中文件描述符的限制
--
FROM 106.37.187.*
【 在 z16166 的大作中提到: 】
: 多进程容错能力强一些（可用性），一个进程崩了，不会影响其他进程；如果只有多线程而没有多进程，只要有一个崩了，就全崩了。
: Nginx作为网络服务，高可用性是必须的。
: 网络服务端的话，尽可能利用SO_REUSEPORT，针对同一个端口开多个socket，用多个线程/进程去执行accept()，提高accept()的速度。
这个需要是linux吧，并且还不能太老的内核，别的系统好像不支持？
--
修改:stub FROM 106.37.187.*
FROM 106.37.187.*
【 在 z16166 的大作中提到: 】
: Linux kernel 3.9+
:
用epoll做高并发是不是要手动修改操作系统单进程中文件描述符数量限制
--
FROM 106.37.187.*
【 在 z16166 的大作中提到: 】
: 这个不是epoll独有的问题吧。连接数大的话，用别的API也会有这个问题，也得改。
: 限制epoll自己的watch数目的是/proc/sys/fs/epoll/max_user_watches
:
感谢
--
FROM 106.37.187.*
【 在 z16166 的大作中提到: 】
: 这个不是epoll独有的问题吧。连接数大的话，用别的API也会有这个问题，也得改。
: 限制epoll自己的watch数目的是/proc/sys/fs/epoll/max_user_watches
:
另外也需要修改进程文件描述符数量限制吧，否则，文件描述符数量限制比较小，epoll watch设置的大也没意义
--
FROM 106.37.187.*