「"Failed to backfill 'Reader' badge"」エラー多数発生。

サポート
1

ログにこれらのエラーがたくさんあります。何かできること、またはすべきことはありますか？

情報：

ジョブ例外：「Reader」バッジのバックフィルに失敗しました：{:revoked_callback=>#<Proc:0x00007867ef8d9620 /var/www/discourse/app/jobs/regular/backfill_badge.rb:20 (lambda)>, :granted_callback=>#<Proc:0x00007867ef8d95f8 /var/www/discourse/app/jobs/regular/backfill_badge.rb:21 (lambda)>}。理由：ERROR: statement timeoutによりステートメントがキャンセルされました

トレース：

/var/www/discourse/app/services/badge_granter.rb:505:in `rescue in backfill'
/var/www/discourse/app/services/badge_granter.rb:385:in `backfill'
/var/www/discourse/app/jobs/regular/backfill_badge.rb:18:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job'
sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/lib/sidekiq/discourse_event.rb:6:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
/var/www/discourse/lib/sidekiq/pausable.rb:131:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse'
sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track'
sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse'
sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke'
sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local'
sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in <class:Config>'
sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats'
sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call'
sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global'
sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch'
sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare'
sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch'
sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt'
sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt'
sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process'
sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one'
sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run'
sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog'
sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread'
「いいね！」 1
3

これは特に大きなトピックの問題でしょうか？それに負担をかける可能性のあるメガトピックはありますか？

バッジ付与ジョブが完全にブロックされている場合、一時的にリーダーバッジを無効にして、それが役立つかどうかを確認することを検討してください。

類似と思われる問題について、これを見つけました（ただし、かなり古いものです）：

したがって、クエリが仕様に対して大きすぎる可能性がありますか？

「いいね！」 1
4

私たちにはメガトピックがありません。少なくとも私は知りません。もし私が実行して確認できるSQLコマンドがあれば、それは良いことです。
私たちは32コアのCPUと128GBのRAMを持っています。これが制限であるかどうかはわかりません。もしデータベース内で何か変更すべきことがあれば、教えてください。

「いいね！」 2
5

もしあれば、おそらくご存知でしょうが、/latest リストを列タイトルを使用するか、YourSite/latest?order=posts を使用してアクティビティ順に並べ替えることで、再確認できます。

しかし、データエクスプローラーで次のようなものを使用すると、トップ10が表示されるはずです。

SELECT id AS topic_id
FROM topics
ORDER BY posts_count DESC
LIMIT 10

Reader バッジの SQL はこちらです。

Reader バッジは必ずしも最もエキサイティングなバッジではありません。もし無効にしても問題ないようであれば、それが一番簡単な解決策かもしれません。しかし、さらに詳しく調べたい場合は、post_timings テーブルを見て、そのサイズを確認する必要があるかもしれません。

「いいね！」 2
6

巨大なトピックがいくつかありましたが、10,000件の返信で上限に達し、分割されました。

今回は無効にします。しかし、rake db:statsの結果は以下の通りです。

table_name                                       | row_estimate | table_size | index_size | total_size
-----------------------------------------------------------------------------------------------
post_timings                                     | 1707169280   | 70 GB      | 61 GB      | 132 GB
topic_views                                      | 243936880    | 11 GB      | 15 GB      | 26 GB
user_auth_token_logs                             | 98783264     | 23 GB      | 2775 MB    | 25 GB
「いいね！」 2
7

それは確かに大きな問題のようですね。 :slight_smile:

念のため（フォーラムの古さにもよりますが）、PostgreSQL 13 update で提供されていたこのアドバイスを試していない場合のために記載します。

残念ながら、これに関する直接の経験はありませんので、より深い分析のために賢い誰かが現れるのを待つ必要があるかもしれません。 :nerd_face:

「いいね！」 1
8

うん。これは私がPostgreSQL 13にアップグレードしたときにやったことです。昨日も実行しました。でも、データベースのサイズは変わりませんでした。

誰か他の人がサイズを減らす方法について意見を述べてくれることを願っています。

ありがとう！

「いいね！」 2