🤡 一个小丑表情引发的血案

2026-04-11 12:280阅读0评论SEO基础
  • 内容介绍
  • 文章标签
  • 相关推荐
问题描述:

这个事情实在过于离奇,这里做一个简单的排查记录,给自己提个醒下次再仔细一点。

社区的 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 里几十上百秒的任务多得很,它们都是后台运行,没把服务器弄挂过。

阅读全文