纯手工打造每一篇开源资讯与技术干货，数十万程序员和Linuxer已经关注。
不过看了很多这些相关Nginx的文档之后，发现一个比较大的问题，就是这些文档基本也就从两个方面着手，一是修改Nginx的配置文件，二是调整操作系统的相关内核参数；而且文档说明也不够明了，缺乏比较系统级别的优化。本文将从Nginx源码编译安装开始，到修改配置文件，调整系统内核参数以及架构四个方面着手分别介绍如何优化。 一. 安装(1) 精简模块 Nginx由于不断添加新的功能，附带的模块也越来越多。很多操作系统厂商为了用户方便安装管理，都增加了rpm、deb或者其他自有格式软件包，可以本地甚至在线安装。不过我不太建议使用这种安装方式。这虽然简化了安装，在线安装甚至可以自动解决软件依赖关系，但是安装后软件的文件布局过于分散，不便管理维护；同时也正是由于存在软件包之间的依赖关系，导致当有安全漏洞、或者其它问题，想要通过更新升级Nginx新版本时却发现yum、deb源还未发布新版本(一般都落后于官网发布的软件版本)。最重要的是采用非源码编译安装的方式，默认会添加入许多模块，比如邮件相关、uwsgi、memcache等等，很多网站运行时这些模块根本未用到，虽然平时占用的资源很小，但是仍然可能是压弯骆驼的一根稻草。各种非必需模块默认安装运行的同时，也给Web系统带来了安全隐患。尽量保持软件的轻装上阵，是每个运维应当尽力做到的，所以我建议一般常用的服务器软件使用源码编译安装管理。。我一般使用的编译参数如下，PHP相关模块fastcgi被保留用作后文优化说明，：
编译参数根据网站是否真正用到的原则增添或者减少，比如我们公司如果需要用到ssi模块,从而能够实现访问shtml页面，可以将第17行删除，那么Nginx将默认安装。大家可以通过运行 "./configure --help" 查看编译帮助，决定是否需要安装哪些模块。 (2) GCC编译参数优化 [可选项】 GCC总共提供了5级编译优化级别： -O0:无优化。 -O和-O1:使用能减少目标代码尺寸以及执行时间并且不会使编译时间明显增加的优化。在编译大型程序的时候会显著增加编译时内存的使用。 -O2:包含-O1的优化并增加了不需要在目标文件大小和执行速度上进行折衷的优化。编译器不执行循环展开以及函数内联。此选项将增加编译时间和目标文件的执行性能。 -Os:可以看成 -O2.5，专门优化目标文件大小，执行所有的不增加目标文件大小的-O2优化选项，并且执行专门减小目标文件大小的优化选项。适用于磁盘空间紧张时使用。但有可能有未知的问题发生，况且目前硬盘容量很大，常用程序无必要使用。 -O3:打开所有 -O2 的优化选项外增加 -finline-functions、-funswitch-loops、-fgcse-after-reload 优化选项。相对于 -O2 性能并未有较多提高，编译时间也最长，生成的目标文件也更大更占内存，有时性能不增反而降低，甚至产生不可预知的问题(包括错误)，所以并不被大多数软件安装推荐，除非有绝对把握方可使用此优化级别。 修改GCC编译参数，提高编译优化级别，此方法适用于所有通过GCC编译安装的程序，不止Nginx。稳妥起见用 -O2，这也是大多数软件编译推荐的优化级别。查看Nginx源码文件 auto/cc/gcc，搜索NGX_GCC_OPT，默认GCC编译参数为-O，可以直接修改内容为NGX_GCC_OPT="-O2"或者在 ./configure配置时添加--with-cc-opt='-O2'选项。 二. 配置应用服务器的性能优化主要在合理使用CPU、内存、磁盘IO和网络IO四个方面，现在我们从Nginx配置文件 nginx.conf 入手进行优化： (1) 工作进程数的选择 指令：worker_processes 定义了Nginx对外提供web服务时的工作进程数。最优值取决于许多因素，包括（但不限于）CPU核心的数量、存储数据的硬盘数量及负载模式。不能确定的时候，将其设置为可用的CPU内核数将是一个好的开始（设置为“auto”将尝试自动检测它）。Shell执行命令ps ax | grep "nginx: worker process" | grep -v "grep" 可以看到运行中的Nginx工作进程数，一般建议设置成服务器逻辑核心数，Shell执行命令cat /proc/cpuinfo | grep processor | wc -l 可以检测出服务器逻辑核心总数，偷懒可以直接写auto，Nginx自适应。 (2) 是否绑定CPU 指令：worker_cpu_affinity 绑定工作进程到对应CPU核心，Nginx默认未开启CPU绑定。目前的服务器一般为多核CPU，当并发很大时，服务器各个CPU的使用率可能出现严重不均衡的局面，这时候可以考虑使用CPU绑定，以达到CPU使用率相对均匀的状态，充分发挥多核CPU的优势。top、htop等程序可以查看所有CPU核心的使用率状况。绑定样例：
(3) 打开文件数** 指令：worker_rlimit_nofile 设定了每个Nginx工作进程打开的最大文件数，受限于系统的用户进程打开文件数**，未设置则使用系统默认值。理论上应该设置为当前Shell启动进程的最大打开文件数除以Nginx的工作进程数。由于Nginx的工作进程打开文件数并不一完全均匀，所以可以将其设置成Shell启动进程的最大打开文件数。Shell执行命令 ulimit -n可以查看当前登录Shell会话最大打开文件数数**。Linux系统用户进程默认同时打开文件最大数为1024，这个值太小，访问量稍大就报“too many open files"。Shell执行命令先修改用户打开文件数**：
| ||
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
