1).减少Nginx编译后的文件大小css
在编译Nginx时,默认以debug模式进行,而在debug模式下会插入不少跟踪和ASSERT之类的信息,编译完成后,一个Nginx要有好几兆字节。而在编译前取消Nginx的debug模式,编译完成后Nginx只有几百千字节。所以能够在编译以前,修改相关源码,取消debug模式。具体方法以下:linux
在Nginx源码文件被解压后,找到源码目录下的auto/cc/gcc文件,在其中找到以下几行:nginx
注释掉或删掉这两行,便可取消debug模式。缓存
2.为特定的CPU指定CPU类型编译优化服务器
在编译Nginx时,默认的GCC编译参数是“-O”,要优化GCC编译,可使用如下两个参数:cookie
要肯定CPU类型,能够经过以下命令:网络
TCMalloc的全称为Thread-Caching Malloc,是谷歌开发的开源工具google-perftools中的一个成员。与标准的glibc库的Malloc相比,TCMalloc库在内存分配效率和速度上要高不少,这在很大程度上提升了服务器在高并发状况下的性能,从而下降了系统的负载。下面简单介绍如何为Nginx添加TCMalloc库支持。并发
要安装TCMalloc库,须要安装libunwind(32位操做系统不须要安装)和google-perftools两个软件包,libunwind库为基于64位CPU和操做系统的程序提供了基本函数调用链和函数调用寄存器功能。下面介绍利用TCMalloc优化Nginx的具体操做过程。app
1).安装libunwind库socket
能够从http://download.savannah.gnu.org/releases/libunwind下载相应的libunwind版本,这里下载的是libunwind-0.99-alpha.tar.gz。安装过程以下:
2).安装google-perftools
能够从http://google-perftools.googlecode.com下载相应的google-perftools版本,这里下载的是google-perftools-1.8.tar.gz。安装过程以下:
至此,google-perftools安装完成。
3).从新编译Nginx
为了使Nginx支持google-perftools,须要在安装过程当中添加“–with-google_perftools_module”选项从新编译Nginx。安装代码以下:
到这里Nginx安装完成。
4).为google-perftools添加线程目录
建立一个线程目录,这里将文件放在/tmp/tcmalloc下。操做以下:
5).修改Nginx主配置文件
修改nginx.conf文件,在pid这行的下面添加以下代码:
接着,重启Nginx便可完成google-perftools的加载。
6).验证运行状态
为了验证google-perftools已经正常加载,可经过以下命令查看:
因为在Nginx配置文件中设置worker_processes的值为4,所以开启了4个Nginx线程,每一个线程会有一行记录。每一个线程文件后面的数字值就是启动的Nginx的pid值。
至此,利用TCMalloc优化Nginx的操做完成。
内核参数的优化,主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化。
下面给出一个优化实例以供参考。
将上面的内核参数值加入/etc/sysctl.conf文件中,而后执行以下命令使之生效:
下面对实例中选项的含义进行介绍:
net.ipv4.tcp_max_tw_buckets :选项用来设定timewait的数量,默认是180 000,这里设为6000。
net.ipv4.ip_local_port_range:选项用来设定容许系统打开的端口范围。在高并发状况不然端口号会不够用。
net.ipv4.tcp_tw_recycle:选项用于设置启用timewait快速回收.
net.ipv4.tcp_tw_reuse:选项用于设置开启重用,容许将TIME-WAIT sockets从新用于新的TCP链接。
net.ipv4.tcp_syncookies:选项用于设置开启SYN Cookies,当出现SYN等待队列溢出时,启用cookies进行处理。
net.core.somaxconn:选项的默认值是128, 这个参数用于调节系统同时发起的tcp链接数,在高并发的请求中,默认的值可能会致使连接超时或者重传,所以,须要结合并发请求数来调节此值。
net.core.netdev_max_backlog:选项表示当每一个网络接口接收数据包的速率比内核处理这些包的速率快时,容许发送到队列的数据包的最大数目。
net.ipv4.tcp_max_orphans:选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。若是超过这个数字,孤立链接将当即被复位并打印出警告信息。这个限制只是为了防止简单的DoS攻击。不能过度依靠这个限制甚至人为减少这个值,更多的状况下应该增长这个值。
net.ipv4.tcp_max_syn_backlog:选项用于记录那些还没有收到客户端确认信息的链接请求的最大值。对于有128MB内存的系统而言,此参数的默认值是1024,对小内存的系统则是128。
net.ipv4.tcp_synack_retries参数的值决定了内核放弃链接以前发送SYN+ACK包的数量。
net.ipv4.tcp_syn_retries选项表示在内核放弃创建链接以前发送SYN包的数量。
net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。正确设置这个值很是重要,有时即便一个负载很小的Web服务器,也会出现大量的死套接字而产生内存溢出的风险。
net.ipv4.tcp_syn_retries选项表示在内核放弃创建链接以前发送SYN包的数量。
若是发送端要求关闭套接字,net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。接收端能够出错并永远不关闭链接,甚至意外宕机。
net.ipv4.tcp_fin_timeout的默认值是60秒。须要注意的是,即便一个负载很小的Web服务器,也会出现由于大量的死套接字而产生内存溢出的风险。FIN-WAIT-2的危险性比FIN-WAIT-1要小,由于它最多只能消耗1.5KB的内存,可是其生存期长些。
net.ipv4.tcp_keepalive_time选项表示当keepalive启用的时候,TCP发送keepalive消息的频度。默认值是2(单位是小时)。
nginx要开启的进程数 通常等于cpu的总核数 其实通常状况下开4个或8个就能够。
每一个nginx进程消耗的内存10兆的模样
worker_cpu_affinity
仅适用于linux,使用该选项能够绑定worker进程和CPU(2.4内核的机器用不了)
假如是8 cpu 分配以下:
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000
nginx可使用多个worker进程,缘由以下:
to use SMP
to decrease latency when workers blockend on disk I/O
to limit number of connections per process when select()/poll() is
used The worker_processes and worker_connections from the event sections
allows you to calculate maxclients value: k max_clients = worker_processes * worker_connections
worker_rlimit_nofile 102400;
每一个nginx进程打开文件描述符最大数目 配置要和系统的单进程打开文件数一致,linux 2.6内核下开启文件打开数为65535,worker_rlimit_nofile就相应应该填写65535 nginx调度时分配请求到进程并非那么的均衡,假如超过会返回502错误。我这里写的大一点
use epoll
Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(freebsd)网络I/O模型,而Apache则使用的是传统的select模型。
处理大量的链接的读写,Apache所采用的select网络I/O模型很是低效。在高并发服务器中,轮询I/O是最耗时间的操做 目前Linux下可以承受高并发
访问的Squid、Memcached都采用的是epoll网络I/O模型。
worker_connections 65535;
每一个工做进程容许最大的同时链接数 (Maxclient = work_processes * worker_connections)
keepalive_timeout 75
keepalive超时时间
这里须要注意官方的一句话:
The parameters can differ from each other. Line Keep-Alive:
timeout=time understands Mozilla and Konqueror. MSIE itself shuts
keep-alive connection approximately after 60 seconds.
client_header_buffer_size 16k
large_client_header_buffers 4 32k
客户请求头缓冲大小
nginx默认会用client_header_buffer_size这个buffer来读取header值,若是header过大,它会使用large_client_header_buffers来读取
若是设置太小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request
求行若是超过buffer,就会报HTTP 414错误(URI Too Long) nginx接受最长的HTTP头部大小必须比其中一个buffer大,不然就会报400的HTTP错误(Bad Request)。
open_file_cache max 102400
使用字段:http, server, location 这个指令指定缓存是否启用,若是启用,将记录文件如下信息: ·打开的文件描述符,大小信息和修改时间. ·存在的目录信息. ·在搜索文件过程当中的错误信息 -- 没有这个文件,没法正确读取,参考open_file_cache_errors 指令选项:
·max - 指定缓存的最大数目,若是缓存溢出,最长使用过的文件(LRU)将被移除
例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache_errors
语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误.
open_file_cache_min_uses
语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中必定的时间范围内可使用的最小文件数,如 果使用更大的值,文件描述符在cache中老是打开状态.
open_file_cache_valid
语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了什么时候须要检查open_file_cache中缓存项目的有效信息.
开启gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-JavaScript text/css
application/xml;
gzip_vary on;
缓存静态文件:
location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {root /usr/local/ku6/ktv/show.ku6.com/;expires 1m;}