Nginx多线程原理
2015-11-11 09:12
846 查看
一、问题
一般情况下,nginx 是一个事件处理器,一个从内核获取连接事件并告诉系统如何处理的控制器。实际上,在操作系统做读写数据调度的时候,nginx是协同系统工作的,所以nginx能越快响应越好。nginx处理的事件可以是 超时通知、socket可读写的通知 或 错误通知。nginx 接收到这些消息后,会逐一进行处理。但是所有处理过程都是在一个简单的线程循环中完成的。nginx 从消息队列中取出一条event后执行,例如 读写socket的event。在大多数情况下这很快,Nginx瞬间就处理完了。
如果有耗时长的操作发生怎么办?整个消息处理的循环都必须等待这个耗时长的操作完成,才能继续处理其他消息。所以,我们说的“阻塞操作”其实意思是长时间占用消息循环的操作。操作系统可能被各种各样的原因阻塞,或者等待资源的访问,例如硬盘、互斥锁、数据库同步操作等。
例如,当nginx 想要读取没有缓存在内存中的文件时,则要从磁盘读取。但磁盘是比较缓慢的,即使是其他后续的事件不需要访问磁盘,他们也得等待本次事件的访问磁盘结束。结果就是延迟增加和系统资源没有被充分利用。
有些操作系统提供了异步读写文件接口,在nginx中可以使用这些接口(http://nginx.org/en/docs/http/ngx_http_core_module.html?&&&_ga=1.197764335.1343221768.1436170723#aio)。例如FreeBSD就是一个较好的例子,但不幸的是,linux提供的一系列异步读文件接口有不少缺陷。其中一个问题是:文件访问和缓冲需要队列,但是Nginx已经很好解决了。但是还有一个更严重的问题:使用异步接口需要对文件描述符设置O_DIRECT标识,这意味着任何对这个文件的访问会跳过缓存直接访问磁盘上的文件。在大多数情况下,这不是访问文件的最佳方法。
二、线程池
为了解决这个问题,Nginx 1.7.11 引入了线程池概念。现在让我们了解一下线程池是怎样工作的。在nginx中,线程池执行的是分发服务,他由一个任务队列和一些执行任务的线程组成。当一个工作线程在执行一个可能会存在潜在长时间操作的任务时,这个任务会被”卸下“并重新放到任务队列中去,这个被”卸下“的任务可能会被其他线程再执行。
现在,只有2个基础操作会造成“卸下任务”到任务队列:
在大多操作系统上的read()系统调用
linux系统的sendfile()
如果这个机制被证实是有益于nginx的,我们以后还会添加其他的操作。
三、线程池并非灵丹妙药
大多数读写文件操作都需要通过缓慢的磁盘。如果有充足的内存来存储数据,那么操作系统会缓存频繁使用的文件,也就是“页面缓存”(page cache)机制。由于页面缓存机制,nginx几乎在所有情况下都能体现非常好的性能。通过页面缓存读取数据非常快,并且不会阻塞。另一方面,卸下任务到任务池是有瓶颈的。所以在内存充足并且使用的数据不是非常大的时候,nginx即使不使用线程池也是几乎工作在最佳状态。
卸下写操作到任务池中,是一个适用于特殊场景的处理方案,适用于大量无法使用VM缓存的请求操作。
例如一个高负荷的基于Nginx的视频流服务器。另外FreeBSD的用户不需要担心这些,因为FreeBSD已经有很好的异步读操作接口,无需使用线程池。
四、配置线程池
如果你确定在你的场景中适合使用线程池,那么一起看看如何配置线程池。准备工作步骤如下:使用 nginx 1.7.11 或更新的版本
使用--with-threads参数编译nginx
最简单的例子,添加一个aio线程标识(可以添加到http、server 或 location段中):
1 | aio threads; |
1 2 3 4 | # in the 'main' context thread_pool default threads=32 max_queue=65536; # in the 'http', 'server', or 'location' context aio threads=default; |
1 | thread pool "NAME" queue overflow: N tasks waiting |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # in the 'main' context thread_pool one threads=128 max_queue=0; thread_pool two threads=32; http { server { location /one { aio threads=one; } location /two { aio threads=two; } } … } |
现在假设你有一台有3个硬盘的服务器,你希望这台服务器作为缓存代理使用,这是你CDN的一个缓存节点,缓存的数据已经超过了可用内存。在这个场景中最重要的事情就是提高磁盘读写的性能。一个方案就是使用RAID,另一个方案就是使用Nginx:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | # We assume that each of the hard drives is mounted on one of these directories: # /mnt/disk1, /mnt/disk2, or /mnt/disk3 # in the 'main' context thread_pool pool_1 threads=16; thread_pool pool_2 threads=16; thread_pool pool_3 threads=16; http { proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:256m max_size=1024G use_temp_path=off; proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:256m max_size=1024G use_temp_path=off; proxy_cache_path /mnt/disk3 levels=1:2 keys_zone=cache_3:256m max_size=1024G use_temp_path=off; split_clients $request_uri $disk { 33.3% 1; 33.3% 2; * 3; } server { … location / { proxy_pass http://backend; proxy_cache_key $request_uri; proxy_cache cache_$disk; aio threads=pool_$disk; sendfile on; } } } |
以上的例子说明可以根据自身硬件灵活调整nginx,通过细微调整,可以让你的软件、操作系统、硬件协同工作在最佳状态,尽可能的利用所有资源。
结论
线程池机制是一个非常好的机制,通过解决大量数据情况下导致的阻塞问题,使得nginx的性能达到一个新的高度。如之前提到的,接下来会有新的接口可能会实现在不损耗性能的情况下实现”卸下“任务机制。注:原文中的一些翻译(1)offloading 翻译为 卸下,其实就是把一个任务塞回到任务池中;
(2)原文中有提到把任务offloading到thread pool中,但其实是task是存放在task pool中,所以我译为”把任务卸下到任务池中“;
(3)性能测试阶段译文略过,可以参考原帖
相关文章推荐
- nginx 服务启动脚本 chkconfig service
- 源码安装一般用途nginx+php
- CentOS7 重启gitlab nginx
- nginx优化
- 配置nginx 高并发 php
- 分布式文件系统FastDFS部署
- nginx: if逻辑运算 (与或非) 实现
- Nginx实战之让用户通过用户名密码认证访问web站点
- Linux下nginx安装笔记
- nginx之location详解
- mac 安装 nginx 环境
- LNMP平滑升级nginx并安装ngx_lua模块教程
- nginx的luajit安装luarocks并安装luafilesystem
- 使用Nginx后获取用户IP,以及防止伪造IP
- 搭建nginx+ffmpeg服务
- 在centos安装bugzilla4.4.10、nginx,安装简体中文包
- nginx 404 跳转到自定义的页面
- nginx的hash
- Nginx重新编译添加模块
- 彻底隐藏Nginx版本号的安全性与方法