🤡 一个小丑表情引发的血案
- 内容介绍
- 文章标签
- 相关推荐
这个事情实在过于离奇,这里做一个简单的排查记录,给自己提个醒下次再仔细一点。
社区的 discourse 版本是每天滚动更新的,这让我们及时避免了很多 bug 用上了很多新特性,当然也出过几次意外。
昨天的版本滚动更新之后,社区开始间歇性地报错 Bad Gateway (502) 。上服务器一看,workers 全挂,日志里看到的都是 workers 超时。
我们分析了一下 status.linux.do 日志,发现 502 发生的非常规律,一般是1个小时一次(也有例外),无一例外都发生在整点之后的几分钟。
尝试回滚版本,发现还真能解决问题。于是将范围锁定在这两个提交版本之间:419827bd ... 802fa4c3,逐个查看 commits。
这些提交里,只对 category.rb 有一次较大的改动,但这个改动只有一个 job 用到,那个 job 是 24 小时运行一次,不应该是它。
剩下的提交几乎没有对 rb 文件做什么改动,都是些一眼可见不会对性能造成什么影响的修改。
去代码里打了一堆日志,终于在一次 502 之后的日志分析中发现了一个 502 时运行过异常的任务: Jobs::DiscourseReactions::ScheduledLikeSynchronizer。
其实之前的排查也感觉到它不寻常,运行时间高达 180+ 秒,但都没当回事。因为 sidekiq 里几十上百秒的任务多得很,它们都是后台运行,没把服务器弄挂过。
这个事情实在过于离奇,这里做一个简单的排查记录,给自己提个醒下次再仔细一点。
社区的 discourse 版本是每天滚动更新的,这让我们及时避免了很多 bug 用上了很多新特性,当然也出过几次意外。
昨天的版本滚动更新之后,社区开始间歇性地报错 Bad Gateway (502) 。上服务器一看,workers 全挂,日志里看到的都是 workers 超时。
我们分析了一下 status.linux.do 日志,发现 502 发生的非常规律,一般是1个小时一次(也有例外),无一例外都发生在整点之后的几分钟。
尝试回滚版本,发现还真能解决问题。于是将范围锁定在这两个提交版本之间:419827bd ... 802fa4c3,逐个查看 commits。
这些提交里,只对 category.rb 有一次较大的改动,但这个改动只有一个 job 用到,那个 job 是 24 小时运行一次,不应该是它。
剩下的提交几乎没有对 rb 文件做什么改动,都是些一眼可见不会对性能造成什么影响的修改。
去代码里打了一堆日志,终于在一次 502 之后的日志分析中发现了一个 502 时运行过异常的任务: Jobs::DiscourseReactions::ScheduledLikeSynchronizer。
其实之前的排查也感觉到它不寻常,运行时间高达 180+ 秒,但都没当回事。因为 sidekiq 里几十上百秒的任务多得很,它们都是后台运行,没把服务器弄挂过。

