nginx的worker_processes优化

nginx的worker_processes参数 来源: http://bbs.linuxtone.org/thread-1062-1-1.html 分享一: 搜索到原作者的话: As a general rule you need the only worker with large number of worker_connections, say 10,000 or 20,000. However, if nginx does CPU-intensive work as SSL or gzipping and you have 2 or more CPU, then you may set worker_processes to be equal to CPU number. Besides, if you serve many static files and the total size of the files is bigger than memory, then you may increase worker_processes to utilize a full disk bandwidth. Igor Sysoev 一般一个进程足够了,你可以把连接数设得很大。 如果有SSL、gzip这些比较消耗CPU的工作,而且是多核CPU的话,可以设为和CPU的数量一样。 或者要处理很多很多的小文件,而且文件总大小比内存大很多的时候,也可以把进程数增加, 以充分利用IO带宽(主要似乎是IO操作有block)。 根据我配置实践, 服务器是“多个CPU+gzip+网站总文件大小大于内存”的环境,worker_processes设置为CPU个数的两倍比较好。 分享二: 最近PPC经常出现502错误,网页经常无法打开,所以本人决定对Nginx进行深入折腾! Nginx本身没有挂掉,否则不会出现502的错误信息,所以原因一定在Nginx的设置上。 经过我查阅资料和测试,发现有可能是worker_processes的参数设置不当引起的。 worker_processes默认情况下为1,一般情况下不用修改,但考虑到实际情况,可以修改这个数值,以提高性能; 官方的建议是修改成CPU的内核数,这里引用一段翻译过的文章:  worker_processes指明了nginx要开启的进程数, 据官方说法,一般开一个就够了,多开几个,可以减少机器io带来的影响。 据实践表明,nginx的这个参数在一般情况下开4个或8个就可以了,再往上开的话优化不太大。 据另一种说法是,nginx开启太多的进程,会影响主进程调度,所以占用的cpu会增高。 经过我测试发现, 这个数字是不能乱设置的,如果网站没有出现io性能问题,最好不要修改,采用默认的1即可, 如果非要设置,必须要和CPU的内核数匹配,否则要么就假死(主要是Windows),要么就出现502的错误(主要是Linux)。 我的电脑是双核的,按理说应该是2,但是实际上应该是4,因为是双线程的。测试结果如下:  1、worker_processes为1,线程打开2个,有一个是主线程,运行很稳定。 2、worker_processes为2,线程打开3个,有一个是主线程,1分钟左右挂掉   (假死,无法打开网页,浏览器一直处于载入中)。 3、worker_processes为4,线程打开5个,有一个是主线程,运行很稳定。 4、worker_processes为8,线程打开9个,有一个是主线程,和2一样,1分钟左右挂掉。 配置参考 配置1: 4 CPU (4 Core) + 4 worker_processes (每个worker_processes 使用1个CPU) [reistlin@reistlin.com ~]$ cat /proc/cpuinfo | grep processor processor : 0 processor : 1 processor : 2 processor : 3 worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; 配置2: ​8 CPU (8 Core) + 8 worker_processes (每个worker_processes 使用1个CPU) [reistlin@reistlin.com ~]$ cat /proc/cpuinfo | grep processor processor : 0 processor : 1 processor : 2 processor : 3 processor : 4 processor : 5 processor : 6 processor : 7 worker_processes 8; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; 配置3: ​16 CPU (16 Core) + 16 worker_processes (每个worker_processes 使用1个CPU) [reistlin@reistlin.com ~]$ cat /proc/cpuinfo | grep processor processor : 0 processor : 1 processor : 2 processor : 3 processor : 4 processor : 5 processor : 6 processor : 7 processor : 8 processor : 9 processor : 10 processor : 11 processor : 12 processor : 13 processor : 14 processor : 15 worker_processes 16; worker_cpu_affinity  0000000000000001 0000000000000010 0000000000000100 0000000000001000 0000000000010000 0000000000100000 0000000001000000 0000000010000000 0000000100000000 0000001000000000 0000010000000000 0000100000000000 0001000000000000 0010000000000000 0100000000000000 1000000000000000; Nginx worker_cpu_affinity 设置 根据 Nginx Wiki 上的资料显示: worker_cpu_affinity Syntax: worker_cpu_affinity cpumask [cpumask...] Default: none Linux only. With this option you can bind the worker process to a CPU, it calls sched_setaffinity(). For example, worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; Bind each worker process to one CPU only. worker_processes 2; worker_cpu_affinity 0101 1010; Bind the first worker to CPU0/CPU2, bind the second worker to CPU1/CPU3. This is suitable for HTT. worker_cpu_affinity 默认是没有开启的, 根据例子我们可以看得出,0001 0010 0100 1000 分别代表第1、2、3、4个逻辑CPU, 所以我们可以设置0010 0100 1000来将3个进程分别绑定到第2、3、4个逻辑CPU上: worker_processes 3; worker_cpu_affinity 0010 0100 1000; 同时根据例子我们也可以看出, worker_cpu_affinity 可以将同1个进程绑定在2个逻辑CPU上: worker_processes 2; worker_cpu_affinity 0101 1010; 0101也就是第1、3个逻辑CPU上,1010就是第2、4个逻辑CPU上。  分享三: worker_processes指明了nginx要开启的进程数, 据官方说法,一般开一个就够了,多开几个,可以减少机器io带来的影响。 据实践表明,nginx的这个参数在一般情况下开4个或8个就可以了,再往上开的话优化不太大。 据另一种说法是,nginx开启太多的进程,会影响主进程调度,所以占用的cpu会增高, 这个说法我个人没有证实,估计他们是开了一两百个进程来对比的吧。 worker_processes配置的一些注意事项: 1、worker_cpu_affinity配置最好是能写上 我这里服务器多数是双核超线程,相当于4cpu,我一般开8进程,所以这个配置就是这样: worker_cpu_affinity 0001 0100 1000 0010 0001 0100 1000 0010; 另,worker_cpu_affinity不是什么时候都能用的, 我没有认真研究并罗列所有情况,只知道2.4内核的机器用不了, 如果用不了的话,那么最好是加大worker_processes进程数,这样分配cpu就会平均一点啦, 如果不平均只好多重启几下。 2、worker_rlimit_nofile配置要和系统的单进程打开文件数一致,千万不要再画蛇添足地除以worker_processes。 我现在在linux 2.6内核下开启文件打开数为65535,worker_rlimit_nofile就相应应该填写65535。 这是因为nginx调度时分配请求到进程并不是那么的均衡,所以假如填写10240, 总并发量达到3-4万时就有进程可能超过10240了,这时会返回502错误。

转自:http://blog.csdn.net/fireroll/article/details/15756745

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯移动品质中心TMQ的专栏

iOS 静态代码扫描之工具调研

为了进一步加强测试质量,同时探索测试左移在同步中的实践,iOS同步助手尝试接入静态代码扫描工具。希望通过不同的途径提前发现日常测试中难发现的问题。

1.5K1
来自专栏喵了个咪的博客空间

[Golang软件推荐] Frp内网穿透

在一个IP紧缺的时代,连电信也不分配固定IP给到你用,一条专网专用线路贵的不行,那么作为软件开发人员常常要使用到外网,比如和微信调试程序,给到不在同一网段的朋友...

9324
来自专栏企鹅号快讯

入门干货之用DVG打造你的项目主页-Docfx、Vs、Github

由于这三项技术涉及到的要点以及内容较多,希望大家有空能自己挖掘一下更多更深的用法。 0x01、介绍 VS,即VS2017以及以上版本,宇宙最好的IDE,集成了宇...

2156
来自专栏Java后端技术栈

记一次解决业务系统生产环境宕机问题!

Zabbix告警生产环境应用shutdown,通过堡垒机登入生产环境,查看应用容器进程,并发现没有该业务应用的相应进程,第一感觉进程在某些条件下被系统杀死了,然...

921
来自专栏北京马哥教育

让“懒惰” Linux 运维工程师事半功倍的 10 个关键技巧!

好的Linux运维工程师区分在效率上。如果一位高效的Linux运维工程师能在 10 分钟内完成一件他人需要 2 个小时才能完成的任务,那么他应该受到奖励(得到更...

4066
来自专栏Dawnzhang的开发者手册

Maven 那点事儿(转)

毋庸置疑,Jason 也是一个秃顶。James Gosling、Rod Johnson、Gavin King,你们可以告诉我为什么吗?

1972
来自专栏coder修行路

《深入理解计算机系统》阅读笔记--计算机系统漫游

1112
来自专栏数据和云

数据库高可用和分区解决方案-MongoDB 篇

许春植(Luocs) (阿里巴巴高级数据库管理员,7年以上数据库运维管理经验,擅长MySQL、Oracle及MongoDB数据库,目前主要研究并建设Mongo...

8966
来自专栏编程直播室

折腾git pages+hexo+NexT初识hexo开始本地试运行准备服务器准备上传工具先告一段落发表文章主题

2306
来自专栏程序员的知识天地

众多Python Web框架比较,哪个适合你,你就用哪个!

Python程序员有很多很好的选择来创建Web应用程序和API;Django,Weppy,Bottle和Flask引领潮流。

2712

扫码关注云+社区

领取腾讯云代金券