Nginx的优化配置

雨点打透心脏的1/2处 2023-02-19 03:29 14阅读 0赞

Nginx相关的内容有点延迟，趁着今天有空就给大家整理完，本篇文章来给大家把Nginx我们在工作中常用的配置来给大家分享下，希望能对大家有所帮助。

# Nginx的优化配置 #

## 全局配置 ##

<table> 
 <thead> 
  <tr> 
   <th>选项</th> 
   <th align="left">设置</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>user root root;</td> 
   <td align="left">默认用户是nobody，如果nginx需要访问某些比如root类权限的文件，会提示403错误，修改这个可以通过root去访问</td> 
  </tr> 
  <tr> 
   <td>worker_processes 2;<br>worker_cpu_affinity 01 10</td> 
   <td align="left">nginx默认是没有开启利用多核cpu的配置的。需要通过增加worker_cpu_affinity配置参数来充分利用多核cpu，cpu是任务处理，当计算最费时的资源的时候，cpu核使用上的越多，性能就越好。解释：01表示启用第一个CPU内核，10表示启用第二个CPU内核worker_cpu_affinity 01 10;表示开启两个进程，第一个进程对应着第一个CPU内核，第二个进程对应着第二个CPU内核。</td> 
  </tr> 
  <tr> 
   <td>error_log /var/log/nginx/error.log warn;</td> 
   <td align="left">错误日志级别</td> 
  </tr> 
  <tr> 
   <td>worker_rlimit_nofile 20480;</td> 
   <td align="left">更改worker进程的最大打开文件数限制, 如果没设置的话，这个值为操作系统的限制, 所以把这个值设高，这样nginx就不会有“too many open files”问题了。设置了这个后，修改worker_connections值时，是不能超过worker_rlimit_nofile的这个值（其实核心原因就是程序打开的文件/socket链接数量超过系统设定值）</td> 
  </tr> 
  <tr> 
   <td>use epoll;</td> 
   <td align="left">使用epoll的I/O模型，这个不用说了吧。{select/pool/kqueue/epool ; select、poll是标准工作模式、kquque、epoll是搞笑工作模式，epoll是用在linux系统。kqueue是用在bsd系统（unix的衍生系统）</td> 
  </tr> 
  <tr> 
   <td>worker_connections 20480;</td> 
   <td align="left">nginx默认的并发连接数是1024，如果网站访问量过大，就需要调整这个值，值越大能够支撑的并发数也就越大。但是最终的天花板是CPU; 理论上每台nginx服务器的最大连接数为worker_processes*worker_connections</td> 
  </tr> 
  <tr> 
   <td>accept_mutex off;</td> 
   <td align="left">当一个新连接到达时，如果激活了accept_mutex，那么多个Worker将以串行方式来处理，其中有一个Worker会被唤醒，其他的Worker继续保持休眠状态；如果没有激活accept_mutex，那么所有的Worker都会被唤醒，不过只有一个Worker能获取新连接，其它的Worker会重新进入休眠状态，这就是「惊群问题」。假设你养了一百只小鸡，现在你有一粒粮食，那么有两种喂食方法：你把这粒粮食直接扔到小鸡中间，一百只小鸡一起上来抢，最终只有一只小鸡能得手，其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。你主动抓一只小鸡过来，把这粒粮食塞到它嘴里，其它九十九只小鸡对此浑然不知，该睡觉睡觉。这就相当于激活了accept_mutex。可以看到此场景下，激活accept_mutex相对更好一些，让我们修改一下问题的场景，我不再只有一粒粮食，而是一盆粮食，怎么办？此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了，一盆粮食不知何年何月才能喂完，大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间，让它们自己去抢，虽然这可能会造成一定程度的混乱，但是整体的效率无疑大大增强了。</td> 
  </tr> 
  <tr> 
   <td>include /etc/nginx/mime.types;</td> 
   <td align="left">这里我们使用它来加载文件扩展名与文件类型映射表。nginx根据映射关系，设置http请求响应头的Content-Type值。当在映射表找不到时，使用nginx.conf中default-type指定的默认值。</td> 
  </tr> 
  <tr> 
   <td>default_type application/octet-stream;</td> 
   <td align="left">指定默认类型为二进制流，也就是当文件类型未 定义时使用这种方式</td> 
  </tr> 
  <tr> 
   <td>sendfile on;</td> 
   <td align="left">开启高效传输模式</td> 
  </tr> 
  <tr> 
   <td>keepalive_timeout 60;</td> 
   <td align="left">http连接的超时时间</td> 
  </tr> 
  <tr> 
   <td>include extra/*.conf;</td> 
   <td align="left">通过不同配置文件进行管理</td> 
  </tr> 
 </tbody> 
</table>

## extra/upstream.conf ##

upstream gupaoedu{ 
      server   192.168.11.152:8080;
      server   192.168.11.153:8080;
    }

## extra/vhost.conf ##

server { 
       listen       80;
       server_name  www.gupao.com
       access_log   off;
       error_log    off;
       location / { 
          proxy_pass                http://gupaoedu;        #选择对应的负载均衡配置 
          proxy_read_timeout        60;    #与后端处理机timeout时间一致; 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应 
          proxy_connect_timeout     60;     #该指令设置与upstream server的连接超时时间，有必要记住，这个超时不能超过75秒
          proxy_send_timeout        60; 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间，而是在两次write操作期间。如果超时后，upstream没有收到新的数据，nginx会关闭连接
          proxy_set_header          Host             $host;  #设置头信息
          proxy_set_header          X-Real-IP       $remote_addr;   #设置头信息
       }
    }