记一次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导致的,正在进一步研究。

原文地址:https://www.cnblogs.com/cuishuai/p/8479629.html