关于Nginx进程管理和重载原理浅谈
本文主要给大家介绍了关于Nginx进程管理和重载原理的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
进程结构图
Nginx是多进程结构,多进程结构设计是为了保证Nginx的高可用高可靠,包含:
- master进程:父进程,负责worker进程的管理
- worker进程:子进程,worker进程一般配置与服务器CPU核数相同,worker进程用来处理具体请求。
- cache进程:也是子进程,包括cache manager和cache loader进程,主要是反向代理做缓存使用。
注:多进程相对于多线程之所以能够保证高可用与高可靠是因为进程间地址空间是独立的,进程间的任务不会相互影响,相对多线程更加耗费CPU资源。而多线程共享一个进程的地址空间,其中一个线程任务失败会影响到其它线程任务。
图3-1 Nginx进程结构图
假设我们的Nginx服务的用户是nginx,我们可以使用如下命令查看当前运行的Nginx服务的master进程和worker进程,而且可以看到4个worker进程的父进程ID都是master的进程ID(1325)。
1 2 3 4 5 6 |
|
图3-2 一个master进程与四个worker子进程
我们可以通过 lsof -i:nginx端口号
来查看我们的master和worker进程。
1 2 3 4 5 6 7 |
|
信号量管理
Linux的信号量管理机制
信号是进程间通信方式之一,典型用法是:终端用户输入中断命令,通过信号机制停止一个程序的运行。
我们可以通过给进程发送信号来管理我们的进程,kill -l
命令可以查看linux支持的信号量
linux信号量
一共有64号信号量,主要需要弄清如下几个:
kill -1 $PID:(SIGHUP)重新加载进程,对于与终端脱离关系的守护进程,这个信号用于通知它重新读取配置文件;
kill -2 $PID:(SIGINT)中断(通Ctrl+C);
kill -3 $PID:(SIGQUIT)从键盘输入的退出(ctrl-\);
kill -9 $PID:(SIGKILL)立即杀死进程,无论当前程序处于什么状态;
kill -10 $PID:(SIGUSR1)$USR1和$USR2都是留给用户自定义的信号量;
kill -12 $PID:($IGUSR2)
kill -15 $PID:(SIGTERM)正常停止一个进程;
kill -17 $PID:(SIGCHLD)父子进程通信的信号量,父进程可以fork()出很多子进程,子进程挂掉会给父进程发送信号;
kill 可将指定的信息送至程序。预设的信息为 SIGTERM(15),可将指定程序终止。若仍无法终止该程序,可使用 SIGKILL(9) 信息尝试强制删除程序。程序或工作的编号可利用 ps 指令或 jobs 指令查看。
1 2 3 4 5 6 7 8 |
|
注:Ctrl+C:停止终端中正在运行的进程,Ctrl+C可以比较有好地中止终端中正在运行的程序(进程)
利用信号量管理Nginx进程
管理Nginx进程可以这些方式:master进程
、worker进程
、命令行
使用信号量管理master和worker(不推荐使用发送信号量的方式来管理worker进程,worker进程应该交给master进程来管理和维护)。
Master进程
监控worker进程
- CHLD
管理worker进程
接收信号
- TERM、INT
- QUIT
- HUP
- USR1
- USR2
- WINCH
示例:
通过kill命令杀死master进程
1 |
|
通过kill命令让Nginx重新读取文件,这样会关闭就得worker进程,生成新的worker进程,master进程(ID)依旧保持不变
1 |
|
Worker进程
接收信号
- TERM、INT
- QUIT
- USR1
- WINCH
虽然可以,但是不推荐使用信号量方式直接管理worker进程,worker进程应该交给master进程来管理和维护
示例:
使用kill命令杀死一个worker进程,这样会杀死一个worker进程,linux会杀掉的worker进程的父进程(master进程)发送SIGCHLD信号量,所以master进程监测到我们某一个子进程可能出了问题,会启动一个新的worker进程,维护worker进程的数量。
1 |
|
命令行
- reload:HUP
- reopen:USR2
- stop:TERM
- quit:QUIT
可以使用nginx -h
查看帮助命令
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
参数说明:
- -?,-h:查看帮助
- -v:查看Nginx版本
- -V:查看Nginx版本和编译选项
- -t:检查配置文件语法是否正确
- -T:检查配置文件语法是否正确,并打印
- -q:在检查配置文件时不显示非错误消息
- -s:给master进程发送信号,可以发送:stop、quit、reopen、reload
- -c:指定配置文件
- -g:设置配置文件之外的全局指令
配置文件重载原理
我们知道了可以通过给nginx的master进程发送SIGHUP信号,或者使用nginx -s reload
命令来达到重新载入配置文件,从而使nginx平滑升级。那我们执行这样一个命令之后,对nginx本身来说背后发生了什么事情呢,它是如何保证新老请求如何平滑过渡的?
reload重载配置文件的流程
- 向master进程发送HUP信号(reload命令)
- master进程检查配置语法是否正确
- master进程打开监听端口(在修改配置文件的端口情况下,可能)
- master进程使用新的配置文件启动新的worker子进程
- master进程向老的worker子进程发送QUIT信号
- 旧的worker进程关闭监听句柄,处理完当前连接后关闭进程
如果用图示来描述的话大概如下图所示
nginx -s reload
图示解析:
1.左边绿色的状态是执行nginx -s reload
命令之前的状态,按照我个人主机的配置时一个master进程和4个worker子进程。
2.为了模拟执行nginx -s reload
命令后原来的worker进程会处理完请求后再被杀掉,我模拟一个需要很久才能处理完任务并响应的接口,是的,我在代码里sleep 15秒,也就是说这个接口响应需要15秒,时间弄长点方便我们来观察中间态,注意,在执行reload命令前请求该接口
1 2 3 |
|
3.我们已经知道了master进程会把任务交给worker子进程处理,目前只有一个任务,所以当前只需要一个worker进程需要处理任务。
4.执行reload命令,master进程会创建4个(与你配置有关)新的worker进程(我上图中的黄色worker进程),关闭掉旧的空闲worker进程(绿色worker进程),而正在处理请求的旧worker进程不会立即关闭,而是会等请求处理完毕就关闭。
5.剩下的最后一个旧worker进程任务处理完毕也被关掉,最后剩下的都是使用新nginx.conf配置产生的新worker进程,可以看下面的这张图,那个处于is shutting down的旧worker进程就是因为处理上面sleep 15秒的任务接口还没处理完毕,所以依然能够被看到。
总结
到此这篇关于Nginx进程管理和重载原理的文章就介绍到这了,希望可以帮到你
转自:微点阅读 https://www.weidianyuedu.com
还没有评论,来说两句吧...