nginx工作进程分析
本篇内容介绍了"nginx工作进程分析"的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
前言
有天接收到业务同事反映，说有些业务超时比例过高。我尝试查询问题，最终定位到nginx将一些请求反向代理到错误的路径上，导致超时。
问题追踪
我准备从以下线索追踪问题：
反向代理到的错误路径，这个错误的路径之前是做什么业务。
反向代理的配置是否正确
nginx配置生效操作是否正确
1.错误的路径
这个路径指向的服务器是之前业务的负载，由于这个机器比较就，就将他下架了。此服务器上已经没有相关业务程序，如果有实时请求反向代理到这台机器上，由于该服务器没有部署相关业务程序，请求失败
2.反向代理的配置是否正确
我们观察了upstream相关配置，的确没有配置转发到这台旧机器的配置。
3.nginx配置生效操作是否正确
使用的命令是：
nginx -t
nginx -s reload
先检查配置是否正确，然后重载。
nginx的reload命令做的是什么样的操作。
参考官方文档
http://nginx.org/en/docs/beginners_guide.html
一旦master 进程接收到需要重载配置文件的信号时，它会检查新配置文件中语法是否正确，尝试着适用该配置。如果成功，master进程会启动新的工作进程，并且向旧的工作进程发送关闭信号，请求关闭旧工作线程。否则，master进程回滚到改动之前的配置状态，继续使用旧的配置文件。老的工作线程，接收到需要关闭的信号时，停止接收新的连接，并且继续服务当前的请求，直到这些请求全部被处理。最后，老的工作线程退出。
回想到错误现象：nginx将一些请求反向代理到错误的路径上，导致超时
存在一些请求反向代理到错误的路径，但是大多数请求的反向代理都是正确的。是不是有些工作进程使用的是当前的配置文件，而有一些工作进程使用的是旧的配置文件。那些走旧的配置文件的工作进程将请求反向代理到错误的路径上。
实际是检验真理的唯一道路，我们登陆服务器查询下该nginx下的工作进程:
nginxbug1.png
nginxbug3.png
发现果然有一个工作进程的创建时间是2018年，明显有问题。pid为 36766 的nginx master下有一个pid为30284 工作进程的创建时间是 2018年。
"nginx工作进程分析"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！
