Recebi muitos erros de "Falha ao preencher a badge 'Reader'"

[jimmy0017]

Temos muitos desses erros no log. Há algo que possamos/devamos fazer?

Info:

Job exception: Falha ao preencher o distintivo ‘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)>}. Razão: ERROR: cancelando instrução devido a tempo limite de instrução

Trace:

/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' 

[JammyDodger]

Isso pode ser um problema com um tópico particularmente grande? Vocês têm algum megatópico que possa estar sobrecarregando ele?

Se o trabalho de concessão de selos estiver sendo bloqueado inteiramente por causa disso, pode ser uma ideia desativar temporariamente o selo de Leitor e ver se isso ajuda.

---

Eu encontrei isso sobre o que parece ser um problema semelhante: (embora bem antigo)

PostgreSQL runaway IO

It is inherently extremely expensive to figure out if a user read EVERY single post on a topic across all topics across all users. If you don’t have the hardware to handle that I would recommend just disabling the reader badge. I am on the fence big time on the value of “calculateavgtime” I am not convinced we even need this long term

Então, pode ser que a consulta seja demais para a sua especificação?

[jimmy0017]

Nós não temos um megatópico. Pelo menos eu não estou ciente. Se houver um comando SQL para eu executar e verificar, seria ótimo.
Temos uma CPU de 32 núcleos + 128 GB de RAM.. Não tenho certeza se isso é uma limitação. Se houver algo que eu precise alterar no banco de dados, por favor, me avise.

[JammyDodger]

@jimmy0017

Nós não temos um megatópico. Pelo menos eu não estou ciente. Se houver um comando SQL para eu executar e verificar, seria ótimo.

Acho que se você tivesse um, provavelmente saberia, mas pode transformar sua lista /latest em ordem de atividade para verificar usando o título da coluna ou usando SeuSite/latest?order=posts.

Mas algo como isto no explorador de dados também deve mostrar os 10 primeiros:

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

O SQL para o distintivo Reader está aqui:

lib/badge_queries.rb

O distintivo Reader não é necessariamente um dos mais empolgantes, então se você puder conviver com desativá-lo e isso resolver tudo, essa pode ser a saída mais fácil. Mas se você quiser explorar mais, acho que pode querer olhar sua tabela post_timings para ver o quão grande ela ficou.

[jimmy0017]

Eu vi alguns mega tópicos. Mas atingimos o limite de 10 mil respostas e as dividimos.

Vou desativá-lo por enquanto. Mas aqui estão os 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

[JammyDodger]

Isso parece realmente robusto.

Por via das dúvidas, caso você não tenha feito isso na época (dependendo da idade do seu fórum), houve este conselho dado em PostgreSQL 13 update

@fitzy

Recriando os índices

O principal recurso desta atualização são as ótimas economias de espaço em nossa maior tabela em todas as instâncias, a tabela post_timings e seus índices. Após uma atualização bem-sucedida, você precisará executar um comando para reconstruir os índices e colher os benefícios.

cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
REINDEX SCHEMA CONCURRENTLY public;
\q
exit
exit

Se você puder verificar o tamanho de post_timings antes e depois do REINDEX, seria uma estatística interessante para compartilhar aqui!

Infelizmente, não tenho experiência direta com isso, então podemos ter que esperar que alguém inteligente apareça para uma análise mais aprofundada.

[jimmy0017]

Sim. Eu fiz isso quando atualizei para o PostgreSQL 13. Eu também o executei ontem. Mas o tamanho do banco de dados não mudou.

Espero que outra pessoa possa dar uma sugestão de como reduzir o tamanho.

Obrigado!