文档章节

nginx大流量负载调优

vstaryw
 vstaryw
发布于 2014/07/14 15:33
字数 1650
阅读 118
收藏 9

优化nginx包括两方面:

1.是自己重写nginx代码(比如tengine)、本身nginx的代码已经足够优秀,如果不是每秒几千的请求,就忽略这个部分吧。

2.另一个就是和优化nginx的配置,这是中小型网站可以重点优化的部分。

nginx的配置文件是一种声明式定义,控制nginx的每一个细节。

所谓负载调优,就是提高单台机器处理效率,降低单台机器的负载。

为了提高单台机器的处理效率,cpu的处理速度是足够快的,我们能解决的就是降低磁盘I/O、网络I/O,减少内存使用。

降低单台机器的负载我们能做的就是负载均衡,把流量打到多台机器处理。

nginx推荐优化内容:

1.open files数量优化
ulimit -a查看系统参数
其中
open files (-n) 1024
表示系统同时最多能打开的文件数,linux下的所有设备都可以认为是文件,包括网络连接,如果同时超过1024个连接,那么nginx的日志就会报“24: Too many open files”

多以优化的第一步就是设置open files为ulimit

修改/etc/profile,增加
ulimit -n 65535

2.Worker Processes数量优化
通常来说设置一个cpu核心对应一个worker processer,最多不超过4个,提高worker process的值是为了提高计算能力,但一般在越到cpu瓶颈前,你会遇到别的瓶颈(如网络问题)。

只有当你要处理大量静态文件的磁盘I/O时,worker进程是单线程的,所以这个读取文件的阻塞IO会降低CPU的处理速度,这是可以增加worker进程数量,其它情况是不需要的。

3.worker进程连接数优化(Worker Connections)
默认情况下这个值是worker_connections 1024,也就是说考虑到keep-alive超时65秒,每个浏览器平均消耗两个链接(chrome会同时打开多个连接来提到加载速度)。

那么默认情况下nginx平均每秒能处理1024/65/2=8,那么8*86440=64w,差不多相当于每天有60万ip。

多以普通网站默认值就可以了,如果你的流量一直提升,可以考虑增加这个值为2048或者更高。

3. CPU Affinity
用来设置worker进程使用哪个cpu核心处理请求并且一直使用这个cpu核心。如果你不知道cpu调度,最好别碰这个,操作系统比你更懂如何调度。

4. Keep Alive

Keep alive 没有数据传输的情况下保持客户端和服务端的连接,也就是保持空连接一段时间,避免重现建立链接的时间消耗。nginx处理空连接的效率非常高,1万个空连接大约消耗2.5M内存。如果流量非常大的网站,减少建立连接的时间开销是非常客观的。keep alive的值设置在10-20s之间比较合理。

5. tcp_nodelay 和 tcp_nopush优化
这两个指令影响nginx的底层网络,它们决定操作系统如何处理网络层buffer和什么时候把buffer内容刷新给终端用户。如果你不懂,就可以保持这两个指令默认不变,对nginx性能影响不明显。

6. access日志优化
默认情况下,access日志会记录所有请求到日志文件,写操作会增加IO操作,如果不需要统计信息,可以使用百度统计或者cnzz统计,完全可以关闭日志,来减少磁盘写,或者写入内存文件,提高IO效率。

7. Error日志优化
错误日志会记录运行中的错误,如果设置的太低,会记录的信息太多,会产生大量IO,推荐设置为warn,这样可以记录大部分信息,而不会有太多IO

8. Open File Cache
nginx会读文件系统的许多文件,如果这些文件的描述符能够缓存起来,那么会提高处理效率。详见http://wiki.nginx.org/HttpCoreModule#open_file_cache

9. Buffers size优化
buffer的大小是你需要调优最重要参数。如果buffer size太小就会到导致nginx使用临时文件存储response,这会引起磁盘读写IO,流量越大问题越明显。

client_body_buffer_size 处理客户端请求体buffer大小。用来处理POST提交数据,上传文件等。client_body_buffer_size 需要足够大以容纳如果需要上传POST数据。

fastcgi_buffers,proxy_buffers 处理后端(PHP,Apache)响应。如果这个buffer不够大,同样会引起磁盘都系IO。需要注意的是它们有一个上限值,这个上限值受 fastcgi_max_temp_file_size 、 proxy_max_temp_file_size控制。

10.磁盘IO
如果能把数据全放到内存,不使用磁盘就可以完全去掉磁盘IO。 默认情况下操作系统也会缓存频繁访问的数据以降低IO。所以预算足够的情况加,加大内存。

11.网络IO
假设我们没有了磁盘IO,所有数据都在内存,那么我们的读IO大概有3-6gbps。这种情况下,如果你网络差,一样会很慢。所以尽可能提高网络带宽,压缩传输数据。

网络带宽买你能买的起的最大带宽,nginx的gzip模块可以用来压缩传输数据,通常gzip_comp_level 设为 4-5,再高就是浪费cpu了。同时也可以采用css,js压缩技术,当然这些技术就与nginx优化无关了。。

绝招
如果你还想提高nginx处理能力,只能祭出大杀器了。别优化了,加机器吧。一点点优化是没有用的,不如扩展机器来的快些。

ps
说道系统的扩展性通常有scale、和extension,区别是前者是数量上扩展,后者是功能上扩展。

本文转载自:

共有 人打赏支持
vstaryw
粉丝 1
博文 18
码字总数 11727
作品 0
深圳
程序员
私信 提问
第五节——NGINX服务静态资源

1 根目录和首页文件 root指令指定用于搜索文件的根目录。为了获得请求文件的路径,NGINX添加请求URI到root指令指定的路径后面。指令可以放在http、server或location上下文中。在下面的例子中...

Leech
03/06
2
0
10倍提升应用性能的10个建议

提升Web应用的性能从未像今天这样刻不容缓。在线经济活动的比例日益提高,就连发展中国家和地区的经济活动都已经有5%以上在线进行了(相关数据请参考本文后面的资源)。在这个超级链接、随时...

李矮矮
2016/09/26
11
0
有经验JAVA程序员如何提升自己?

具有一到五年开发经验 需要学习内容很多 JVM/分布式/高并发/性能优化/Spring MVC/Spring Boot/Spring Cloud/MyBatis/Netty源码分析等等等 01、透彻理解Tomcat原理手写动静态资源的实现 02、分...

阿阳啊啊
2017/11/29
0
0
新型的大型bbs架构(squid+nginx)

这个架构基于squid、nginx和lvs等技术,从架构上对bbs进行全面优化和保护,有如下特点: 1、高性能:所有的点击基本上全部由前端缓存负责,提供最快速的处理。 2、高保障度:不需考虑应用程序...

鉴客
2010/09/13
15.6K
7
新型的大型bbs架构(squid+nginx

这个架构基于squid、nginx和lvs等技术,从架构上对bbs进行全面优化和保护,有如下特点: 1、高性能:所有的点击基本上全部由前端缓存负责,提供最快速的处理。 2、高保障度:不需考虑应用程序...

岭南六少
2011/09/12
0
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周日乱弹 —— 懒床是对冬天最起码的尊重

Osc乱弹歌单(2018)请戳(这里) 【今日歌曲】 @瘟神灬念 :分享daniwellP/桃音モモ的单曲《Nyan Cat》 《Nyan Cat》- daniwellP/桃音モモ 手机党少年们想听歌,请使劲儿戳(这里) @巴拉迪...

小小编辑
今天
54
2
码云项目100,水一发

简单回顾一下: 早期构想最多的,是希望能将PHP一些类和编码分区做得更细,所以很多尝试。但不得不说,PHP的功能过于单一,是的,也许写C/C++扩展,可以解决问题,那我为什么不用C#或者Golan...

曾建凯
今天
4
0
Spring应用学习——AOP

1. AOP 1. AOP:即面向切面编程,采用横向抽取机制,取代了传统的继承体系的重复代码问题,如下图所示,性能监控、日志记录等代码围绕业务逻辑代码,而这部分代码是一个高度重复的代码,也就...

江左煤郎
今天
4
0
eclipse的版本

Eclipse各版本代号一览表 Eclipse的设计思想是:一切皆插件。Eclipse核心很小,其它所有功能都以插件的形式附加于Eclipse核心之上。 Eclipse基本内核包括:图形API(SWT/Jface),Java开发环...

mdoo
今天
3
0
SpringBoot源码:启动过程分析(一)

本文主要分析 SpringBoot 的启动过程。 SpringBoot的版本为:2.1.0 release,最新版本。 一.时序图 还是老套路,先把分析过程的时序图摆出来:时序图-SpringBoot2.10启动分析 二.源码分析 首...

Jacktanger
今天
12
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部