一,nginx 介绍
(一)nginx 与apache
1, Apache event 模型
相对于 prefork 模式 可以同时处理更多的请求
相对于 worker 模式 解决了keepalive场景下,长期被占用的线程的资源浪费问题 因为有监听线程(某些线程因为被keepalive,空挂在哪里等待,中间几乎没有请求过来,甚至等到超时)
但是在生产环境中 apache event 的表现不尽人意,这时就要说到他的缺点:
没有线程安全控制
处理高并发 进程切换问题
2,更高性能的Web服务端 Nginx
基于Nginx的工作场景
正向代理: 代理的客户端( 科学上网 )
反向代理: 代理的服务端
二 Input Output 模型
(一)常见名词介绍
1,磁盘I/O (本地I/O)
磁盘I/O是进程向内核发起系统调用,请求磁盘上的某个资源比如是html 文件或者图片,然后内核通过相应的驱动程序将目标文件加载到内核的内存空间,加载完成之后把数据从内核内存再复制给进程内存,如果是比较大的数据也需要等待时间
2,网络I/O
一切皆文件,本质为对socket文件的读写 网络通信就是网络协议栈到用户空间进程的IO就是网络IO
3,用户态
用户态:应用程序 我们可以控
4,内核态
内核态:操作系统层面,我们不容易去控制的 操作系统
(二)客户端上网的过程
1.客户端发起请求 先发送到网卡
2.网卡收到的报文复制到内核空间
3.内核空间再复制到用户空间的应用程序空间
4.nginx 分析得到一个磁盘页面文件
5.再将需求反馈给内核空间,应为应用程序没有权限从磁盘上直接读取文件,需要依靠内核
6.内核去磁盘上找到所需要的文件,加载到内核空间
7.加载后再复制到用户空间
8.用户空间构建响应报文,交给内核空间,内核空间再复制给网卡,返回给用户
整个过程会来回切换 用户空间,内核空间 那么我们可以再次基础上做优化处理
为了优化客户体验 ,要么解决的是本地 io (零拷贝技术 ) 要么 解决的是网络 io(多路复用 )
(三)零拷贝技术
1,零拷贝技术目的
解决的是本地 i/o
2,零拷贝技术原理
原理:减少 内核空间 和 用户空间 之间拷贝次数
3,零拷贝技术 方法
通过 缓存或者映射
(可以简单粗暴理解为 内核把经常要找给nginx的文件缓存或者映射 减少nginx没有权利去调用磁盘上的内容,需要内核去调 这一步)
4,零拷贝技术在nginx 配置文件上的体现
在主配置文件有 体现 这一行和零拷贝技术有关
(四)I/O 模型相关概念
nginx 分析该报文, 将报文和自己的配置文件,一一比对,按照配置文件完成请求, 分析后发现 客户需要 index.html 由于 程序的权限问题, 没有资格直接调用磁盘上的文件, 程序会再将这个请求 再次转发给内核
在这个过程时,A (nginx)程序布置了一个任务给 B(内核)
任务是 找个某个文件,先复制内核,在复制给我
1,消息反馈机制(同步 异步)
同步
同步: 内核处理完了 不会主动 告诉 nginx你交代的任务我做完了,需要nginx 自己不停的去问内核 你做完没有
异步
内核处理完了 会主动 告诉 nginx,我准备好资源了你来复制吧
2,调用者在等待结果返回之前所处的状态(阻塞/非阻塞 )
1 2 3 4
nginx 进程 在 处理 1 请求的时候 是否可以继续处理2的请求?
非阻塞:
nginx在等待内核给文件的时候,这中间的等待时间,我可以去处理其他请求
阻塞:
只能处理完1客户所有的任务后再去接待2客户
(五)网络I/O模型
1,阻塞型 I/O 模型(blocking IO)
1.1 说明
阻塞IO模型是最简单的I/O模型,用户线程在内核进行IO操作时被阻塞用户线程通过系统调用read发起I/O读操作,由用户空间转到内核空间。内核等到数据包到达后,然后将接收的数据拷贝到用户空间,完成read操作用户需要等待read将数据读取到buffer后,才继续处理接收的数据。整个I/O请求的过程中,用户线程是被阻塞的,这导致用户在发起IO请求时,不能做任何事情,对CPU的资源利用率不够
1.2 优缺点
-
优点:程序简单,在阻塞等待数据期间进程/线程挂起,基本不会占用 CPU 资源
-
缺点:每个连接需要独立的进程/线程单独处理,当并发请求量大时为了维护程序,内存、线程切换开销较大,apache 的preforck使用的是这种模式。 慢 不能处理高并发
2,非阻塞型 I/O 模型 (nonblocking IO)
2.1 说明
用户线程发起IO请求时立即返回。但并未读取到任何数据,用户线程需要不断地发起IO请求,直到数据到达后,才真正读取到数据,继续执行。即 “轮询”机制存在两个问题:如果有大量文件描述符都要等,那么就得一个一个的read。这会带来大量的Context Switch(read是系统调用,每调用一次就得在用户态和核心态切换一次)。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长,程序响应延迟就过大;设的太短,就会造成过于频繁的重试,干耗CPU而已,是比较浪费CPU的方式,一般很少直接使用这种模型,而是在其他IO模型中使用非阻塞IO这一特性。
2.2 优缺点
实际使用很少 没有返回机制
3,多路复用 I/O 型 ( I/O multiplexing )
3.1 说明
I/O multiplexing 主要包括:select,poll,epoll三种系统调用,select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket,当某个socket有数据到达了,就通知用户进程。当用户进程调用了select,那么整个进程会被block,而同时,kernel会“监视”所有select负责的socket,当任何一个socket中的数据准备好了,select就会返回。这个时候用户进程再调用read操作,将数据从kernel拷贝到用户进程。Apache prefork是此模式的select,work是poll模式。linux里的nginx默认是epoll
3.2 优缺点
让select 或者poll 或者 epoll 进程
去看好没好 阻塞在select nginx照样接请求
4,信号驱动式 I/O 模型 (signal-driven IO)
4.1 说明
信号驱动I/O的意思就是我们现在不用傻等着了,也不用去轮询。而是让内核在数据就绪时,发送信号通知我们。
调用的步骤是,通过系统调用 sigaction ,并注册一个信号处理的回调函数,该调用会立即返回,然后主程序可以继续向下执行,当有I/O操作准备就绪,即内核数据就绪时,内核会为该进程产生一个SIGIO 信号,并回调注册的信号回调函数,这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进程所需要的数据从内核空间拷贝到用户空间
此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行,只要等待来自信号处理函数的通知。
在信号驱动式 I/O 模型中,应用程序使用套接口进行信号驱动 I/O,并安装一个信号处理函数,进程继续运行并不阻塞
当数据准备好时,进程会收到一个 SIGIO 信号,可以在信号处理函数中调用 I/O 操作函数处理数据。
4.2 优缺点
-
优点:线程并没有在等待数据时被阻塞,内核直接返回调用接收信号,不影响进程继续处理其他请求因此可以提高资源的利用率
-
缺点:信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
5,异步 I/O 模型 (asynchronous IO)
5.1 说明
异步I/O 与 信号驱动I/O最大区别在于,信号驱动是内核通知我们何时开始一个I/O操作,而异步I/O是由内核通知我们I/O操作何时完成,两者有本质区别,相当于不用去饭店场吃饭,直接点个外卖,把等待上菜的时间也给省了。所有事情都交给内核处理。
5.2 优缺点
阻塞最少 ,但是对内核的性能要求很高
6, 总结
这五种 I/O 模型中,越往后,阻塞越少,理论上效率也是最优
目前linux 里的nginx 使用多路复用i/o 模型
(六)select poll epoll
1,nginx 驱动模型介绍
Nginx支持在多种不同的操作系统实现不同的事件驱动模型,但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同,主要有以下实现方式:
1、select: select库是在linux和windows平台都基本支持的 事件驱动模型库,并且在接口的定义也基本相同,只是部 分参数的含义略有差异,最大并发限制1024,是最早期的事件驱动模型。 |
2、poll: 在Linux 的基本驱动模型,windows不支持此驱动模型,是select的升级版,取消了最大的并发限制,在编 译nginx的时候可以使用--with-poll_module和--without-poll_module这两个指定是否编译select 库。 |
3、epoll: epoll是库是Nginx服务器支持的最高性能的事件驱动库之一,是公认的非常优秀的事件驱动模型,它和 select和poll有很大的区别,epoll是poll的升级版,但是与poll有很大的区别. epoll的处理方式是创建一个待处理的事件列表,然后把这个列表发给内核,返回的时候在去轮训检查这个 表,以判断事件是否发生,epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大 数,同时epoll库的I/O效率不随描述符数目增加而线性下降,因为它只会对内核上报的“活跃”的描述符进行 操作。 |
4、rtsig: 不是一个常用事件驱动,最大队列1024,不是很常用 |
5、kqueue: 用于支持BSD系列平台的高校事件驱动模型,主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版 本,NetBSD级以上版本及Mac OS X 平台上,该模型也是poll库的变种,因此和epoll没有本质上的区别, 都是通过避免轮训操作提供效率。 |
6、/dev/poll: 用于支持unix衍生平台的高效事件驱动模型,主要在Solaris 平台、HP/UX,该模型是sun公司在开发 Solaris系列平台的时候提出的用于完成事件驱动机制的方案,它使用了虚拟的/dev/poll设备,开发人员 将要见识的文件描述符加入这个设备,然后通过ioctl()调用来获取事件通知,因此运行在以上系列平台的时 候请使用/dev/poll事件驱动机制。 |
7、eventport: 该方案也是sun公司在开发Solaris的时候提出的事件驱动库,只是Solaris 10以上的版本,该驱动库看防 止内核崩溃等情况的发生。 |
8、Iocp: Windows系统上的实现方式,对应第5种(异步I/O)模型 |
2,select poll epoll 具体区别
Select | Poll | Epoll | |
操作方式 | 遍历 | 遍历 | 回调 |
底层实现 | 数组 | 链表 | 哈希表 |
I/O效率 | 每次调用都进行线性遍历,时间复杂度为o(n) | 同左 | 事件通知方式,每当fd就绪,系统注册的回调函数就会被调用,将就绪的fd放到rdlllist里,时间复杂度为o(1) |
最大连接数 | 1024(x86) 2048(x64) | 无上限 | 无上限 |
fd拷贝 | 每次调用select都需要把fd集合从用户拷贝到内核态 | 每次调用poll,都需要把fd集合从用户态拷贝到内核态 | 调用epoll_ct时拷贝进内核并保存,之后每次epoll_wait不拷贝 |
3,总结
epoll
linux里的nginx默认是epoll
性能最好 epoll (epoll 是poll 升级版 )
只会遍历已准备好的事件(fd)集合,事件个数无限制
select
会轮询遍历所有的 事件集合,其次遍历的事件个数有限制
性能最差 select
4, 实验验证
select 不管内核有没有做好,只会遍历fd 里的请求 上限2048
epoll 会筛选出准备好的fd 里的请求 没有上限限制
三,Nginx概述
(一)Nginx 功能介绍
-
静态的web资源服务器html,图片,js,css,txt等静态资源
-
http/https协议的反向代理 ,7层 url
-
结合FastCGI /uWSGI/SCGI等协议反向代理动态资源请求
-
tcp/udp协议的请求转发(反向代理) 4层
(二) 基础特性
-
模块化设计,较好的扩展性
-
高可靠性
-
支持热部署:不停机更新配置文件,升级版本,更换日志文件
-
低内存消耗:10000个keep-alive连接模式下的非活动连接,仅需2.5M内存
-
event-driven, aio, mmap,sendfile
(三)Web 服务相关的功能
-
虚拟主机(server)
-
支持 keep-alive 和管道连接(利用一个连接做多次请求)
-
访问日志(支持基于日志缓冲提高其性能)
-
url rewirte
-
路径别名
-
基于IP及用户的访问控制
-
支持速率限制及并发数限制
-
重新配置和在线升级而无须中断客户的工作进程
(四)Nginx 进程结构
1,web请求处理机制
-
多进程方式:服务器每接收到一个客户端请求就有服务器的主进程生成一个子进程响应客户端,直到用户关闭连接,这样的优势是处理速度快,子进程之间相互独立,但是如果访问过大会导致服务器资源耗尽而无法提供请求。
-
多线程方式:与多进程方式类似,但是每收到一个客户端请求会有服务进程派生出一个线程来个客户方进行交互,一个线程的开销远远小于一个进程,因此多线程方式在很大程度减轻了web服务器对系统资源的要求,但是多线程也有自己的缺点,即当多个线程位于同一个进程内工作的时候,可以相互访问同样的内存地址空间,所以他们相互影响,一旦主进程挂掉则所有子线程都不能工作了,IIS服务器使用了多线程的方式,需要间隔一段时间就重启一次才能稳定
2,主进程(master process)的功能
master是主进程 不干活
对外接口:接收外部的操作(信号)
对内转发:根据外部的操作的不同,通过信号管理 Worker
监控:监控 worker 进程的运行状态,worker 进程异常终止后,自动重启 worker 进程
读取Nginx 配置文件并验证其有效性和正确性
建立、绑定和关闭socket连接
按照配置生成、管理和结束工作进程
接受外界指令,比如重启、升级及退出服务器等指令
不中断服务,实现平滑升级,重启服务并应用新的配置
开启日志文件,获取文件描述符
不中断服务,实现平滑升级,升级失败进行回滚处理
编译和处理perl脚本
3,工作进程(worker process)的功能
worker 是子进程 干活
所有 Worker 进程都是平等的
实际处理:网络请求,由 Worker 进程处理
Worker进程数量:一般设置为核心数,充分利用CPU资源,同时避免进程数量过多,导致进程竞争CPU资源,
增加上下文切换的损耗
接受处理客户的请求
将请求依次送入各个功能模块进行处理
I/O调用,获取响应数据
与后端服务器通信,接收后端服务器的处理结果
缓存数据,访问缓存索引,查询和调用缓存数据
发送请求结果,响应客户的请求
接收主程序指令,比如重启、升级和退出等
四,nginx 模块
-
核心模块:是 Nginx 服务器正常运行必不可少的模块,提供错误日志记录 、配置文件解析 、事件驱动机制 、进程管理等核心功能
-
标准HTTP模块:提供 HTTP 协议解析相关的功能,比如: 端口配置 、 网页编码设置 、 HTTP响应头设置 等等
-
可选HTTP模块:主要用于扩展标准的 HTTP 功能,让 Nginx 能处理一些特殊的服务,比如:Flash 多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
-
邮件服务模块:主要用于支持 Nginx 的 邮件服务 ,包括对 POP3 协议、 IMAP 协议和 SMTP协议的支持
-
Stream服务模块: 实现反向代理功能,包括TCP协议代理 反向
-
第三方模块:是为了扩展 Nginx 服务器应用,完成开发者自定义功能,比如: Json 支持、 Lua 支持等
nginx高度模块化,但其模块早期不支持DSO机制;1.9.11 版本支持动态装载和卸载
核心模块:core module
标准模块:
HTTP 模块: ngx_http_*
HTTP Core modules #默认功能
HTTP Optional modules #需编译时指定
Mail 模块: ngx_mail_*
Stream 模块 ngx_stream_*
第三方模块
五, 安装nginx 和准备工作
企业主流1.18 偶数为 稳定版
(一)编译安装nginx
为什么要编译安装? 可以安装更多的模块
1, 编译安装步骤
https://nginx.org/en/download.html
#官网
yum -y install gcc pcre-devel openssl-devel zlib-devel openssl openssl-devel
#安装依赖包
useradd -M -s /sbin/nologin nginx
#新建nginx用户便于管理
cd /opt/
wget http://nginx.org/download/nginx-1.18.0.tar.gz
#官网下载安装包
tar xf nginx-1.18.0.tar.gz
cd nginx-1.18.0/
#解压软件包
mkdir /apps/nginx -p
./configure --help
#查看帮助模块
./configure --prefix=/apps/nginx \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-pcre \
--with-stream \
--with-stream_ssl_module \
--with-stream_realip_module
make
make install
chown -R nginx.nginx /apps/nginx
#修改权限
ll /apps/nginx/
total 0
drwxr-xr-x 2 root root 333 Sep 22 12:49 conf
drwxr-xr-x 2 root root 40 Sep 22 12:49 html
drwxr-xr-x 2 root root 6 Sep 22 12:49 logs
drwxr-xr-x 2 root root 19 Sep 22 12:49 sbin
注意:有一个报错 yum 进程被占用
尝试用 kull -s9 强杀 也不行
解决办法: 移走该进程
2, 重要文件详细介绍
2.1 源码包
-
contrib:vim 格式文件,修改nginx配置文件的格式,高亮 cp -r /opt/nginx-1.18.0/contrib/vim/* /usr/share/vim/vimfiles/
-
conf:配置文件
-
man:man帮助 man man/nginx.8 不加路径看不了 nginx.8 文件
-
src:源码包 点c 点h 结尾的文件 find src -type f |xargs cat |wc -l 193678 (统计源代码多少行)
-
objs 后面生成的文件夹 放二进制
2.2 安装完成后的文件
-
conf:保存nginx所有的配置文件,其中nginx.conf是nginx服务器的最核心最主要的配置文件,其他的.conf则是用来配置nginx相关的功能的,例如fastcgi功能使用的是fastcgi.conf和fastcgi_params两个文件,配置文件一般都有个样板配置文件,是文件名.default结尾,使用的使用将其复制为并将default去掉即可。
-
html目录中保存了nginx服务器的web文件,但是可以更改为其他目录保存web文件,另外还有一个50x的web文件是默认的错误页面提示页面。
-
logs:用来保存nginx服务器的访问日志错误日志等日志,logs目录可以放在其他路径,比如/var/logs/nginx里面。
-
sbin:保存nginx二进制启动脚本,可以接受不同的参数以实现不同的功能。
3,在使用nginx 前的准备工作
3.1 启动停止nginx
做软连接 为了可以不写绝对路径
3.2 改属主数组
3.3 加不能登录的 nginx程序用户
useradd -M -s /sbin/nologin nginx
3.4 把 nginx 交给systemctl 管理
因为是编译安装,所以需要手搓Nginx 自启动文件
#复制同一版本的nginx的yum安装生成的service文件
vim /usr/lib/systemd/system/nginx.service
#建立文件
[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=forking
PIDFile=/apps/nginx/logs/nginx.pid
#注意文件位置,如果不对 启动不了
ExecStart=/apps/nginx/sbin/nginx -c /apps/nginx/conf/nginx.conf
#注意启动文件位置
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
LimitNOFILE=100000
[Install]
WantedBy=multi-user.target
(二)yum 安装 nginx
centos7 需要安装epel源
yum install -y epel-release
#安装epel源 额外 rpeo
yum install nginx -y
六, nginx命令
(一)nginx 命令常见选项
1,nginx -v 显示版本
2,nginx -V 显示编译详细情况 模块等信息
3, nginx -t nginx -T 测试配置文件是否有语法错误
4,nginx -h 帮助
5,nginx -c 使用指定的配置文件
6,nginx -g 指定配置指令
7, nginx -p 指定运行目录
8,nginx -s 发射信号
(二)nginx -s 发射信号 详细介绍
这两个是等同的 | 含义 | |
nginx -s stop | kill -s SIGTERM | 直接停止 |
nginx -s quit | kill -s SIGQUIT | 优雅的退出:有人在访问不会结束进程 |
nginx -s reopen | kill -s SIGUSR1 | 分割日志 |
nginx -s reload | kill -s SIGHUP | 重新加载配置文件 |
注意:kill -l 看信号大全
nginx -h 中可以看到的信号较少
可以使用man手册来查看详细的信号 如果没安装,去源码包里找到man文件
man 路径/nginx.8 不加路径打不开man帮助
(三)分割日志
找到日志 在安装路径下的 logs 文件夹里
access.log 为成功访问的日志
将日志备份 并新建一个access.log 文件
查看目前的 文件大小
客户机再次访问 发现日志并没有放到新增的文件中,还是在备份的文件中
输入 nginx -s reopen 或者kill -s USR1 子进程号
再次客户机访问 可以看到日志成功分割了
(四)nginx -g 指定配置 不已配置文件中的为准
nginx -g 指定配置 不已配置文件中的为准
1,nginx -g 'user zhangsan;' 已张三身份运行,默认是以nginx身份
2,nginx -g 'daemon off;' 前台运行命令
3,nginx -g 'worker_processes 1;' 只开一个工作进程
七, 热升级nginx1.18 到nginx1.20
(一)步骤
-
将旧Nginx文件换成新Nginx文件(注意备份)
-
向master进程发送USR2信号
-
master进程修改pid文件名,加后缀.oldbin
-
master进程用新Nginx文件启动新master进程,系统中将有新旧两个Nginx主进程共同提供Web服务
-
向旧的Nginx服务进程发送WINCH信号,使旧的Nginx worker进程平滑停止,并删除Nginx.pid.oldbin文件
-
向旧master进程发送QUIT信号,关闭老master
-
如果发现升级有问题,可以回滚向老master发送HUP,向新master发送QUIT
(二)实验操作
1,从官网下载1.20.2 的包
2, 找到压缩包
3,解压
4,进到源码包
5,./configure 安装模块 (可以nginx -V 直接复制)
注意: 这边出现了这个问题 是解压压缩包时出错 重新下压缩包再解压就好了
6,make 编译 不要make install !!!!!!!!!!
7, 去到 objs 文件夹 可以看到绿色的可执行文件
查看版本号 为1.20.2
8,将低版本的nginx主程序改名
9, 将新版本 拷入进去
10,查看 现在的版本号 发现已经改过来了
11, 但是内存里还是1.8 所以需要热升级
12, 查看主进程号 并 kill -USR2 主进程号 (在运行中升级)
13 就会生成一个新的master 和新的worker
框出来的是 新的
14,生成一个测试文件 让客户机来下载
15, 客户机下载 并限速1M 每秒
16, 优雅关闭老进程的 worker 进程
17 ,此时可以看到不会影响客户机下载 且客户机访问看到的版本号也变过来了
18 ,服务机 的进程 可以看到老的worker 已经关闭
(三)回滚
就是把1.20的nginx 移走
再把老的nginx移回来
八, 配置文件详细解释
(一)配置文件位置
主配置文件:nginx.conf
子配置文件: include conf.d/*.conf
主配置文件贴心的有备份
(二)主配置文件架构 及格式
1,主配置文件架构
2, 详细介绍 主配置文件部分
events 控制事件驱动
http web网页配置有关
location 和url 有关
main block 主配置段,即全局配置段,对http,mail都有效
mail 协议相关配置段
stream 服务器相关配置段(负载均衡)
3,配置文件格式
关键字 值 ; ;结尾
(三)全局配置
nginx 有多种模块
-
核心模块:是 Nginx 服务器正常运行必不可少的模块,提供错误日志记录 、配置文件解析 、事件驱动机制 、进程管理等核心功能
-
标准HTTP模块:提供 HTTP 协议解析相关的功能,比如: 端口配置 、 网页编码设置 、 HTTP响应头设置 等等
-
可选HTTP模块:主要用于扩展标准的 HTTP 功能,让 Nginx 能处理一些特殊的服务,比如:Flash 多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等
-
邮件服务模块:主要用于支持 Nginx 的 邮件服务 ,包括对 POP3 协议、 IMAP 协议和 SMTP协议的支持
-
Stream服务模块: 实现反向代理功能,包括TCP协议代理
-
第三方模块:是为了扩展 Nginx 服务器应用,完成开发者自定义功能,比如: Json 支持、 Lua 支持等
九 , 主配置文件调优
(一)关闭版本号
在配置文件中 加入 server_tokens off; 检查语法
重新加载配置文件
客户机 访问 验证
(二) 自定义版本号
1,修改注意事项
注意:去修改源码,在安装包里, 再重新编译安装
先吧服务关闭,不然编译不成功
2. 修改规则
注意:当主配置文件 server_tokens on; 版本显示的是源代码包src/core/nginx.h 里改的内容
当主配置文件 server_tokens off; 版本显示的源代码包 src/http/ngx_http_header_filter_module.c 里改的内容
3,实验
1,先去到 源码包 src/core/nginx.h 改第13 14行
2,再去 源码包src/http/ngx_http_header_filter_module.c 改49行
3,去到源码包所在目录 重新编译安装
4,重新加载配置文件
5, 当主配置文件 server_tokens on; 客户机显示heihei/9999
6, 当主配置文件 server_tokens off; 客户机显示 haha
(三)修改启动的进程数
如果设置为auto 就是你真实的cpu数量
设置为5 个 可以看到有5个worker
pid (进程号) cmd(程序名) psr(运行在那个cpu上 )
(四)cpu与work 进程 绑定
1,意义
将Nginx工作进程绑定到指定的CPU核心,默认Nginx是不进行进程绑定的,绑定并不是意味着当前nginx进程独占以一核心CPU,但是可以保证此进程不会运行在其他核心上,这就极大减少了nginx的工作进程在不同的cpu核心上的来回跳转,减少了CPU对进程的资源分配与回收以及内存管理等,因此可以有效的提升nginx服务器的性能。
2, 实验
cpu 序号:
CPU MASK: 00000001:0号CPU
00000010:1号CPU
................
10000000:7号CPU
1,因为服务机目前 就只有两个cpu 主配置文件只需要分配两个cpu亲缘性
2,服务机 记得刷新配置文件
3, 为了查看实验结果 客户机压力测试(ab 要先装httpd)
4, 不停查看 服务机的worker 发现绑定cpu
(五)PID 路径
一般不改
pid 进程号文件位置可以自定义 在主配置文件
(六)nginx进程的优先级(work进程的优先级)
NI 越小 优先级越大 可以看到目前ni 优先级都是0
主配置文件 加ni -20
重新加载配置文件 并查看
(七)调试work进程打开的文件的个数
1,在主配置文件 加上这一句
意思是所有的 worker 可以打开的文件数量为 65536
2, nginx 程序允许了 但是linux的文件系统最大只默认打开1024个
3,需要改内核文件 添加这一行 加到最后(注意数字不要特别大,会死机)
4,重启
5,验证
先到在站点目录下生成大文件big.img
dd if=/dev/zero of=big.img bs=100M count=1
可以在 客户机器上安装压力测试的工具写一个压力测试脚本
while : ;do ab -c 1000 -n 10000 http://192.168.217.66/big.img;sleep 1;done
服务机worker fd 会产生很多 请求文件
6, 注意!!!!
去worker 进程看一下
还是没改 ,因为nginx 交给systemctl 管理了 要告诉systemctl
在nginx 的systemct启动配置文件 加这一句话
(八)服务是否已后台方式运行
服务进程: 一般都是后台 一旦开启 一直开启 除非人为干预
在容器里 服务必须前台
加入这一行 前台运行
(九)只有 master进程没有 work进程
实际生产中使用较少
master_process off|on;
#是否开启Nginx的master-worker工作模式,仅用于开发调试场景,默认为on