Nginx优化，优化并发量，优化Linux内核，解放CPU处理能力，做定期日志切割，做404错误页面等技术

本案例要求对Nginx服务器进行适当优化，解决如下问题，以提升服务器的处理性能：

• 如何自定义返回给客户端的404错误页面
• 如何查看服务器状态信息
• 如果客户端访问服务器提示“Too many open files”如何解决
• 如何解决客户端访问头部信息过长的问题
• 如何让客户端浏览器缓存数据
• 日志切割
• 开启gzip压缩功能，提高数据传输效率
• 开启文件缓存功能

然后客户机访问此Web服务器验证效果：

• 使用ab压力测试软件测试并发量
• 编写测试脚本生成长头部信息的访问请求
• 客户端访问不存在的页面，测试404错误页面是否重定向

 

1.自定义404错误页面

在nginx配置文件下添加error_page 404 /404.html即可

1. [root@proxy ~]# vim /usr/local/nginx/html/404.html        //生成错误页面
2. Oops,No NO no page …
3. [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
4. http{
5. ....
6. error_page 404   /404.html
7. ....
8. }
9. [root@proxy ~]# nginx -s reload
10. [root@client ~]# firefox http://192.168.4.5/abcsda.html        //访问一个不存在的页面,跳转到404.html即为成功

常见错误列表

 

2.如何查看服务器状态信息（非常重要的功能）

  安装的时候添加一些配置属性

1. [root@proxy ~]# tar -zxvf nginx-1.12.2.tar.gz
2. [root@proxy ~]# cd nginx-1.12.2
3. [root@proxy nginx-1.12.2]# ./configure \
4. > --with-http_ssl_module                        //开启SSL加密功能
5. > --with-stream                                //开启TCP/UDP代理模块
6. > --with-http_stub_status_module                //开启status状态页面
7. [root@proxy nginx-1.12.2]# make && make install    //编译并安装

修改配置文件

1. [root@proxy ~]# cat /usr/local/nginx/conf/nginx.conf  //修改配置文件
2. … …
3. location /status {
4. stub_status on;
5. }
6. … …
7. [root@proxy ~]# /usr/local/nginx/sbin/nginx   //开启nginx服务

测试

1. [root@proxy ~]# firefox http://192.168.4.5/status      //本机ip下的status
2. …

　状态显示，Active connections，当前连接数量为１

　Server Accepts 已经接受客户端的连接总量为2,这是从nginx开启之时开始记录，你可以关闭浏览器再启动，连接数会加１

　Handled  已经处理客户端的连接总数量为2,与接受数一样，除非访问量超过服务器能承受的最大值

　Requests　当前处理的请求数为2，说明请求了两次，你可以刷新浏览器，将会加１

　Reading　当前服务器正在读取客户端请求头的数量为０，因为Handled已经处理完了所以这里显示为0除非目前正在有请求

　Writing　当前服务器写响应数量为１，这是指当前的页面

　Waiting　当前多少客户端在等待服务器的响应为０，这个值为客户端请求数与服务器能处理数的差值

Active connections：当前活动的连接数量。

Accepts：已经接受客户端的连接总数量。

Handled：已经处理客户端的连接总数量。

（一般与accepts一致，除非服务器限制了连接数量）。

Requests：客户端发送的请求数量。

Reading：当前服务器正在读取客户端请求头的数量。

Writing：当前服务器正在写响应信息的数量。

Waiting：当前多少客户端在等待服务器的响应。

 

3.优化Nginx并发量

   ab,ab是apachebench命令的缩写,是apache自带的压力测试工具。ab非常实用，它不仅可以对apache服务器进行网站访问压力测试，也可以对或其它类型的服务器进行压力测试。比如nginx、tomcat、IIS等

   ab的原理：ab命令会创建多个并发访问线程，模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的，因此，它既可以用来测试apache的负载压力，也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。

   ab命令对发出负载的计算机要求很低，它既不会占用很高CPU，也不会占用很多内存。但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也需要注意，否则一次上太多的负载。可能造成目标服务器资源耗完，严重时甚至导致死机。

测试安装是否成功：
[root@vic html]# ab -V
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

没有安装的话． yum -y install httpd-tools

常用参数：

-n在测试会话中所执行的请求个数。默认时，仅执行一个请求。请求的总数量

-c一次产生的请求个数。默认是一次一个。请求的用户量

-t测试所进行的最大秒数。其内部隐含值是-n 50000，它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。

-V显示版本号并退出。

注意，-c不能大于-n，即用户数小于请求数，不然会执行失败

1. [root@proxy ~]# ab -n 2000 -c 2000 http://192.168.4.5/
2. Benchmarking 192.168.4.5 (be patient)
3. socket: Too many open files (24)                //提示打开文件数量过多

这里用2000个用户与访问，出现socket不够用的情况，说明服务器已经达到请求阀值，下面要增加服务器的并发量

1. [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
2. .. ..
3. worker_processes 2;                    //与CPU核心数量一致，我的虚拟机只申请了２个ｃｐｕ，以自己的为准
4. events {
5. worker_connections 65535;        //每个worker最大并发连接数65535是最大值
6. }
7. .. ..
8. [root@proxy ~]# nginx -s reload

做完并发量设置后，还需要优化Linux内核参数（最大文件数量）

1. [root@proxy ~]# ulimit -a                        //查看所有属性值
2. [root@proxy ~]# ulimit -Hn 100000                //设置硬限制（临时规则）
3. [root@proxy ~]# ulimit -Sn 100000                //设置软限制（临时规则）
4. [root@proxy ~]# vim /etc/security/limits.conf　　　　//非临时限制，这里只需要用到临时限制即可
5.     .. ..
6. * soft nofile 100000
7. * hard nofile 100000
8.  
9. #该配置文件分4列，分别如下：
10. #用户或组 硬限制或软限制 需要限制的项目 限制的值

修改之前，看到open files那一列，显示的最大可打开文件数为1024，我们把他修改到100000

修改之后

优化后测试服务器并发量

[root@proxy ~]# ab -n 2000 -c 2000 http://192.168.4.5/

100%　证明请求全部被接受

[root@proxy ~]# ab -n 20000 -c 20000 http://192.168.4.5/

只有19918条请求被响应，说明已经超过服务器的负荷

 

4.浏览器本地缓存静态数据

 如果经常访问某个页面，可以将改页面下的视频与图片做一个缓存，用户体验效果会比较好

以Firefox浏览器为例，在Firefox地址栏内输入about:cache将显示Firefox浏览器的缓存信息，如图-3所示，点击List Cache Entries可以查看详细信息。

清空firefox本地缓存数据

修改Nginx配置文件，定义对静态页面的缓存时间，和缓存文件类型

1. [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
2. server {
3. listen 80;
4. server_name localhost;
5. location / {
6. root html;
7. index index.html index.htm;
8. }
9. location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
10. expires        30d;            //定义客户端缓存时间为30天
11. }
12. }
13. [root@proxy ~]# cp /usr/share/backgrounds/day.jpg /usr/local/nginx/html
14. [root@proxy ~]# nginx -s reload

优化后，使用Firefox浏览器访问图片，再次查看缓存信息

1. [root@client ~]# mv /day.jpg  /var/www/html/day.jgp    //将一张图片移动到httpd默认路径下
2. [root@client ~]# firefox http://192.168.4.5/day.jpg

在firefox地址栏内输入about:cache，查看本地缓存数据，查看是否有图片以及过期时间是否正确。

点击Disk下的List Cache Entries可以查看详细信息。

 

5.日志切割

日志文件越来越大怎么办？单个文件10G? 如何切割？（非常常见的面试题）

我们不希望一个日志文件过于庞大，这样在检查日志文件的时候效率很低，我们希望一个星期做一次日志切割．

日志切割的思路如下：

1.将当前日志文件备份，然后清空原日志文件内容

2.通过kill -USER1 $pid 命令通知并情况某个服务进程的日志文件，如Nginx

注意：USR1亦通常被用来告知应用程序重载配置文件；例如，向Apache HTTP服务器发送一个USR1信号将导致以下步骤的发生：停止接受新的连接，等待当前连接停止，重新载入配置文件，重新打开日志文件，重启服务器，从而实现相对平滑的不关机的更改。

可以看到kill -USER1 $pid 命令的功能还是非常强大的，kill的作用其实不是如它的单词意思＇杀死＇一致,杀死进程其实只是它功能的一部分，它有非常多的功能，可以通过kill -l 查看，所以说kill真正的意义在于调控进程

我们可以使用kill -HUP(SIG之后的单词） 或者　kill -1　使用命令

[root@web2 base_git]# kill -l
 1) SIGHUP     2) SIGINT     3) SIGQUIT     4) SIGILL     5) SIGTRAP
 6) SIGABRT     7) SIGBUS     8) SIGFPE     9) SIGKILL    10) SIGUSR1
11) SIGSEGV    12) SIGUSR2    13) SIGPIPE    14) SIGALRM    15) SIGTERM
16) SIGSTKFLT    17) SIGCHLD    18) SIGCONT    19) SIGSTOP    20) SIGTSTP
21) SIGTTIN    22) SIGTTOU    23) SIGURG    24) SIGXCPU    25) SIGXFSZ
26) SIGVTALRM    27) SIGPROF    28) SIGWINCH    29) SIGIO    30) SIGPWR
31) SIGSYS    34) SIGRTMIN    35) SIGRTMIN+1    36) SIGRTMIN+2    37) SIGRTMIN+3
38) SIGRTMIN+4    39) SIGRTMIN+5    40) SIGRTMIN+6    41) SIGRTMIN+7    42) SIGRTMIN+8
43) SIGRTMIN+9    44) SIGRTMIN+10    45) SIGRTMIN+11    46) SIGRTMIN+12    47) SIGRTMIN+13
48) SIGRTMIN+14    49) SIGRTMIN+15    50) SIGRTMAX-14    51) SIGRTMAX-13    52) SIGRTMAX-12
53) SIGRTMAX-11    54) SIGRTMAX-10    55) SIGRTMAX-9    56) SIGRTMAX-8    57) SIGRTMAX-7
58) SIGRTMAX-6    59) SIGRTMAX-5    60) SIGRTMAX-4    61) SIGRTMAX-3    62) SIGRTMAX-2
63) SIGRTMAX-1    64) SIGRTMAX    

1)手动执行日志切割

备注：/usr/local/nginx/logs/nginx.pid文件中存放的是nginx的进程PID号。

1. [root@proxy ~]cd /usr/local/nginx/logs
2. [root@proxy logs]# mv access.log access2.log  //清空并备份日志
3. [root@proxy logs]# kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid)　

kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid)这一条命令在这里起到的作用非常强大，它首先暂停进程，然后重新载入配置文件，可以看到我们第一步已经相当与删除原日志文件，但是因为我们重新载入了配置文件，所有它又一次创建了access.log日志文件,最后重启服务．

2)自动切割

每周5的03点03分自动执行脚本完成日志切割工作。

1. [root@proxy ~]# vim /usr/local/nginx/logbak.sh　　　//创建一个自动切割脚本
2. #!/bin/bash
3. date=`date +%Y%m%d`　　　　　　　　　　　//获取当前时间
4. logpath=/usr/local/nginx/logs　　　　　　　　//获取日志路径
5. mv $logpath/access.log $logpath/access-$date.log　//备份并删除日志，备份日志记录备份时间
6. mv $logpath/error.log $logpath/error-$date.log
7. kill -USR1 $(cat $logpath/nginx.pid)　　　　　　//重建日志并重启服务
8.  
9. [root@proxy ~]# crontab -e　　　　　　　　　//设置自动执行任务
10. 03 03 * * 5 /usr/local/nginx/logbak.sh

 

6.服务器内存缓存

如果需要处理大量静态文件，可以将文件缓存在内存，下次访问会更快。要求服务器内存空间较为宽裕，适用与经常被访问的某个网站．

1. [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
2. .....
3. http {
4. open_file_cache max=2000 inactive=20s;
5. open_file_cache_valid 60s;
6. open_file_cache_min_uses 5;
7. open_file_cache_errors off;
8. //设置服务器最大缓存2000个文件句柄，关闭20秒内无请求的文件句柄
9. //文件句柄的有效时间是60秒，60秒后过期
10. //只有访问次数超过5次会被缓存
11. }

补充［文件句柄］：在文件I/O中，要从一个文件读取数据，应用程序首先要调用操作系统函数并传送文件名，并选一个到该文件的路径来打开文件。该函数取回一个顺序号，即文件句柄（file handle），该文件句柄对于打开的文件是唯一的识别依据。要从文件中读取一块数据，应用程序需要调用函数ReadFile，并将文件句柄在内存中的地址和要拷贝的字节数传送给操作系统。当完成任务后，再通过调用系统函数来关闭该文件。

linux下文件句柄相当与inode

 

7.对页面进行压缩处理

如果某些静态文件过于庞大，可以设置压缩处理

1. [root@proxy ~]# cat /usr/local/nginx/conf/nginx.conf
2. http {
3. .. ..
4. gzip on;                            //开启压缩
5. gzip_min_length 1000;                //小文件不压缩
6. gzip_comp_level 4;                //压缩比率
7. gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
8.                                     //对特定文件压缩，类型参考mime.types
9. .. ..
10. }

 

8.优化Nginx数据包头缓存

　1)优化前，使用脚本测试长头部请求是否能获得响应

1. [root@proxy ~]# cat lnmp_soft/buffer.sh   //创建一个脚本用于创建表头文件
2. #!/bin/bash
3. URL=http://192.168.4.5/index.html?　　　　　//?后跟一个参数，存于表头之中
4. for i in {1..5000}
5. do
6.     URL=${URL}v$i=$i
7. done
8. curl $URL                                //经过5000次循环后，生成一个长的URL地址栏
9. [root@proxy ~]# ./buffer.sh
10. .. ..
11. <center><h1>414 Request-URI Too Large</h1></center>        //提示头部信息过大

2）修改Nginx配置文件，增加数据包头部缓存大小

1. [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
2. .. ..
3. http {
4. client_header_buffer_size 1k;        //默认请求包头信息的缓存    
5. large_client_header_buffers 4 4k;        //大请求包头部信息的缓存个数与容量4 4k　相当与16k
6. .. ..
7. }
8. [root@proxy ~]# nginx -s reload

3）优化后，使用脚本测试长头部请求是否能获得响应

1. [root@proxy ~]#cat cat buffer.sh
2. #!/bin/bash
3. URL=http://192.168.4.5/index.html?
4. for i in {1..5000}
5. do
6.     URL=${URL}v$i=$i
7. done
8. curl $URL
9. [root@proxy ~]# ./buffer.sh　　　　　//没有提示<center><h1>414 Request-URI Too Large</h1></center>  即成功