记一次pm2的踩坑

Posted 诗码者

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次pm2的踩坑相关的知识,希望对你有一定的参考价值。

1、问题:

公司采用了自动发布平台,最近突然发现一个问题,上线完成后服务是能正常访问的,但是有一个节点访问的时候每两次中总是有一次404,通过nginx的access日志分析发现第一次正常访问有一次get请求202,接下来访问第二次或出现一次get404,post202,get404,返回三个请求?很奇怪啊。

 

2、探索:

首先检查nginx是否有人修改,导致转发出问题。经检查发现没问题,然后去后端服务器排查是否启动了多个instanc,使用pm2  ls查看,只有一个instanc。然后再查看端口,netstat -tunlp | grep 10081,也只有一个。那就很奇怪了,从访问的结果来看明显是轮训了两个节点,于是查看代码的commit id,pm2  show  21 (21是pm2的id),发现代码是1个月前的;到项目的目录下,使用git  log查看发现代码就是最新的。问题已经发现了,就是一个instance有了两份代码,并且轮训访问。而只能看到有一个是启动的。猜想是之前的进程没有在代码发布的时候平滑重启,导致有两个进程都占用同一个端口,但是代码确实两份。所以访问的时候会出现轮训一个错一个对的情况。

于是将现有的instanc停掉,来验证之前的猜想,pm2  stop  21,发现服务还是可以访问的,只是一直返回的是报错的那个。netstat -tunlp | grep 10081,发现还是有输出。这就验证了,一个端口,两份代码,两个服务的猜想。

 

3、解决:

将instan删掉,pm2 delete 21,将剩下的那个netstat -tunlp | grep 10081,根据pid将进程kill掉。然后重新构建,问题就解决了。

 

4、FQA:

1、这个问题并不是必现的,因为向上的服务是可以正常访问的,又是集群环境,因此发生的时候,bug不容易排查。

2、在nginx的access日志里面,观察到总有某个节点请求会有失败和成功,并且很有规律,就可以考虑排查一下是否是这个错。

3、目前怀疑是pm2 的startOrReload的bug导致的,正在进一步研究。

 

以上是关于记一次pm2的踩坑的主要内容,如果未能解决你的问题,请参考以下文章

记一次datax hdfswriter的踩坑记(上传文件到hdfs的坑)

记一次log4j不打印日志的踩坑记

记一次VueCLi生成项目中引入全局Scss文件的踩坑记录

科目一考试一次必过的踩坑笔记 All In One

踩坑adb——我的一次使用adb命令的踩坑之旅

一次php foreach 变量作用域的踩坑记录