Sidekiq 有很多错误和排队的任务

hendersj · 2024 年2 月 26 日 19:05

我们在管理员控制台中收到了关于 Sidekiq 队列作业的一些建议 - 我们有近 200,000 个作业已入队，并且不确定如何解决此问题。我们正在运行 3.2.0 版本。

这些作业都在 ultra_low 队列中，看起来是 Jobs::ProcessPost 作业。它们看起来都与此类似：

	[{"bypass_bump"=true, "cooking_options"=nil, "new_post"=false, "post_id"=729508, "skip_pull_hotli... 
{"bypass_bump"=true, "cooking_options"=nil, "new_post"=false, "post_id"=729508, "skip_pull_hotlinked_images"=false, "current_site_id"="default"}

我们如何才能让这些作业得到处理，以及如何以一种确保它们不会显著影响性能（或者这是不可避免的）的方式来完成？

hendersj · 2024 年2 月 28 日 19:19

两天前，大约是 195K；现在已经上升到 211K。我真的很需要一些建议，看看应该关注什么以及如何解决这个问题。

我们注意到有 5 个死亡作业，看起来像这样（IP 地址已混淆）：

Jobs::HandledExceptionWrapper: Wrapped Errno::ENETUNREACH: Failed to open TCP connection to x.x.x.x:443 (Network is unreachable - connect(2) for "x.x.x.x" port 443)

该地址指向的是基础设施中的一个服务器，但论坛没有使用它（它是一个源代码存储库服务器）。我在配置中没有看到任何地方引用了该主机，所以不确定为什么它会认为需要连接到该主机。但我想知道这是否与 ultra_low 队列中不断增加的排队作业数量有关。

hendersj · 2024 年2 月 29 日 17:59

在过去的约 23 小时内，又增加了 7,000 个作业到队列中。

这也导致一些实现更改被推迟——自动关闭和添加 solutions 插件（只是不想进行可能受此影响或可能因更改如此重要的系统设置而加剧此问题所带来的更改）。

新增的 7K 个作业与我们昨天新增的帖子数量不符，所以我不太清楚是什么导致了这种情况。

还有哪些信息有助于解决此问题？

Ed_S · 2024 年2 月 29 日 18:19

我帮不上忙，只能建议多回复和点赞此帖中的帖子可能会引起它应有的关注！

编辑：我还将在关于默认按“热度”排序的帖子中提到这个问题，我认为这非常有效地隐藏了这个帖子，而且非常无益。

Falco · 2024 年2 月 29 日 20:47

您能分享完整的堆栈跟踪吗？我假设这是来自我们 onebox 代码，但想确认一下。

hendersj · 2024 年2 月 29 日 21:28

我猜我们必须从控制台执行此操作 - 我需要找有权限的人来做；你能告诉我从哪里提取它，以便我可以将其转达给有权限的人吗？

谢谢！

Falco · 2024 年2 月 29 日 22:01

不，不，回溯显示在您选择错误时 /logs 页面的一个选项卡中。

hendersj · 2024 年2 月 29 日 22:30

啊，谢谢你的提示。这是它显示的内容（IP 地址已混淆）：

消息（报告了 10 条）

作业异常：无法打开到 x.x.x.x:443 的 TCP 连接（网络无法访问 - 连接（2）到“x.x.x.x”端口 443）


回溯

/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `initialize'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `open'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `block in connect'
/usr/lib64/ruby/gems/3.2.0/gems/timeout-0.4.1/lib/timeout.rb:186:in `block in timeout'
/usr/lib64/ruby/gems/3.2.0/gems/timeout-0.4.1/lib/timeout.rb:193:in `timeout'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1601:in `connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:27:in `block in connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each_with_index'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `connect'

我注意到这与“回溯”选项卡中的输出不同，但那里的输出看起来不像回溯，而这里复制（使用复制按钮）的内容是。如果需要此信息，请告知。

我也会看看是否能通过这种方式获取有关 220K+ 排队任务的更多信息——我之前不知道 /logs 端点。

Falco · 2024 年2 月 29 日 22:31

回溯的底部没有额外的行？

hendersj · 2024 年2 月 29 日 22:37

复制按钮只抓取了这些内容——这是从 backtrace 选项卡中获取的完整输出：

net-http-0.4.1/lib/net/http.rb:1603:in `initialize' 
net-http-0.4.1/lib/net/http.rb:1603:in `open' 
net-http-0.4.1/lib/net/http.rb:1603:in `block in connect' 
timeout-0.4.1/lib/timeout.rb:186:in `block in timeout' 
timeout-0.4.1/lib/timeout.rb:193:in `timeout' 
net-http-0.4.1/lib/net/http.rb:1601:in `connect' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:27:in `block in connect' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each_with_index' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `connect' 
net-http-0.4.1/lib/net/http.rb:1580:in `do_start' 
net-http-0.4.1/lib/net/http.rb:1569:in `start' 
net-http-0.4.1/lib/net/http.rb:1029:in `start' 
/srv/www/vhosts/discourse/lib/final_destination.rb:551:in `safe_session' 
/srv/www/vhosts/discourse/lib/final_destination.rb:486:in `safe_get' 
/srv/www/vhosts/discourse/lib/final_destination.rb:170:in `get' 
/srv/www/vhosts/discourse/lib/retrieve_title.rb:90:in `fetch_title' 
/srv/www/vhosts/discourse/lib/retrieve_title.rb:12:in `crawl' 
/srv/www/vhosts/discourse/lib/inline_oneboxer.rb:76:in `lookup' 
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:310:in `process_inline_onebox' 
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:39:in `block in post_process_oneboxes' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:214:in `block in apply' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:162:in `block in each_onebox_link' 
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:235:in `block in each' 
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:234:in `upto' 
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:234:in `each' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:162:in `each_onebox_link' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:213:in `apply' 
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:9:in `post_process_oneboxes' 
/srv/www/vhosts/discourse/lib/cooked_post_processor.rb:42:in `block in post_process' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:53:in `block in synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:34:in `synchronize' 
/srv/www/vhosts/discourse/lib/cooked_post_processor.rb:38:in `post_process' 
/srv/www/vhosts/discourse/app/jobs/regular/process_post.rb:28:in `block in execute' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:53:in `block in synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:34:in `synchronize' 
/srv/www/vhosts/discourse/app/jobs/regular/process_post.rb:8:in `execute' 
/srv/www/vhosts/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform' 
rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/srv/www/vhosts/discourse/app/jobs/base.rb:284:in `block in perform' 
/srv/www/vhosts/discourse/app/jobs/base.rb:280:in `each' 
/srv/www/vhosts/discourse/app/jobs/base.rb:280:in `perform' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process' 
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke' 
/srv/www/vhosts/discourse/lib/sidekiq/pausable.rb:132:in `call' 
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke' 
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/rails.rb:14:in `block in call' 
activesupport-7.0.8/lib/active_support/execution_wrapper.rb:92:in `wrap' 
activesupport-7.0.8/lib/active_support/reloader.rb:72:in `block in wrap' 
activesupport-7.0.8/lib/active_support/execution_wrapper.rb:92:in `wrap' 
activesupport-7.0.8/lib/active_support/reloader.rb:71:in `wrap' 
sidekiq-6.5.12/lib/sidekiq/rails.rb:13:in `call' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run' 
sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog' 
sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'

抱歉没有抓取完整的输出。我认为复制按钮没有抓取更多内容很奇怪，但我错误地认为它抓取了所需的内容。

Falco · 2024 年2 月 29 日 22:42

太好了！

这意味着有一个或多个内联链接的 URL 解析到您服务器的 IP 地址。如果无法访问该服务器，我们会记录错误，但 markdown 编译过程应该会继续进行，而不会执行内联 onebox 会触发的“链接美化”。

另外，您是如何安装 Discourse 的？这看起来不像遵循了我们官方安装指南的安装。

hendersj · 2024 年2 月 29 日 22:51

我实际上并没有执行安装——我相信我们的基础设施团队已经使用 CI/CD 管道进行了部署，但我不知道具体细节。

听起来失败的消息不是问题——ultra_low 队列中大量排队的任务似乎是这里更大的问题。在日志中找不到任何内容（实际上对我来说是合理的，因为作业还没有真正运行）。

Firepup650 · 2024 年2 月 29 日 22:54

如果手动强制运行几个，会发生什么？

hendersj · 2024 年2 月 29 日 22:56

我在 Web UI 中看不到强制它们运行的选项 - 我有一个“显示所有”参数的选项，或者单独删除任务。

Firepup650 · 2024 年2 月 29 日 23:05

嗯。我们论坛上没有排队的，所以我为尝试建议一个不存在的按钮而道歉。

参考重试页面，关于我认为在排队页面上的内容

hendersj · 2024 年2 月 29 日 23:09

没关系——是的，这些会显示在“Enqueued”（已排队）页面（位于 /sidekiq/queues/ultra_low）。

查看队列页面本身，我看到 ultra_low 队列的延迟大约是一年。所以这显然已经持续了一段时间了，我们最近才在仪表板上收到关于它的警报。

hendersj · 2024 年2 月 29 日 23:27

深入研究我看到的 Jobs::ProcessPost 作业，发现 post_id 值正在倒数——我从队列中的第一个和最后一个作业中提取了 post ID，日期对应于 2012 年的帖子（在迁移到 Discourse 之前——但 ‘updated_at’ 时间戳来自 2022 年，这可能是我们的迁移日期——我需要检查一下），最近的一个帖子来自 2023 年 1 月。

我确实看到偶尔有生成主题缩略图的作业，但这些作业非常罕见。队列中有超过 8800 页的内容，我无法全部检查，但看起来大部分添加进来的是 Jobs::ProcessPost 的内容，并且它正在按时间倒序处理看起来像是每一个回复和主题的初始帖子（最早的一个是在帖子中间，最新的一个是在主题的根帖子）。

hendersj · 2024 年3 月 1 日 20:50

我从生产系统拉取了一个备份并将其加载到本地设置的测试环境中。队列似乎根本没有积压——事实上，我在监视队列时根本没有看到 Job::ProcessPost 出现在该队列中（我将设置它让系统自行运行，同时记录队列屏幕，看看我是否只是错过了它）。

这引出了两个问题：

是什么触发了 ProcessPost 作业？
是什么导致 ultra_low 队列未被处理？

我不是 Discourse 使用的任何技术（redis、sidekiq 或 rails）的专家，但我非常乐意在我的沙盒环境中学习和尝试事物，以便了解我需要让某人查看生产环境中的哪些内容。

好消息是，这个问题似乎还没有给我们的用户造成任何问题。第三个问题是，仅仅清除该队列是否有帮助，或者不允许这些作业运行是否会以某种方式损害系统？

更新：我在测试环境中看到了一批作业，并且它们正在那里处理。所以这似乎只是队列在生产服务器上因某种原因未被处理。

hendersj · 2024 年3 月 1 日 21:26

看起来我们已经达成了解决方案。我们正在使用的安装是为 openSUSE 构建的软件包（我们一直在讨论的实例是 openSUSE 论坛的实例）——所以它基本上使用的是“从源代码构建”的安装过程。

我们有一个开发和生产环境，而 ultra_low 队列被错误地排除在了生产环境的 sidekiq 配置之外。这已经得到纠正，队列似乎正在清空，延迟已从 1 年降至 4 周。

我认为现在可以认为问题已解决。感谢提供意见的各位——这帮助我找到了找出问题所在的方向。

system · 2024 年3 月 31 日 21:26

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

话题		回复	浏览量
Could sidekiq queue be reason for 500 errors? Installation server-resources	31	3857	2018 年7 月 13 日
Very slow Sidekiq issue with large queue due to massive numbers of unread user notifications Installation	69	7318	2020 年5 月 11 日
Errors on a forum I volunteer with Support	2	668	2023 年12 月 22 日
Sidekiq not running Installation	22	5270	2024 年6 月 8 日
"Ensure sidekiq is running." when it is definitely running Installation	19	7755	2015 年10 月 24 日

Sidekiq 有很多错误和排队的任务

相关话题