Tengo muchos errores de "No se pudo rellenar la insignia 'Reader'"

[jimmy0017]

Tenemos muchos de estos errores en el registro. ¿Hay algo que podamos/debamos hacer?

Información:

Excepción de trabajo: No se pudo rellenar la insignia ‘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ón: ERROR: se canceló la instrucción debido al tiempo de espera de la instrucción.

Rastreo:

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

¿Podría ser un problema con un tema particularmente grande? ¿Tienen algún megatema que pueda ser una carga para él?

Si el trabajo de concesión de insignias está siendo bloqueado por completo debido a esto, podría ser una idea deshabilitar temporalmente la insignia de Lector y ver si eso ayuda.

---

Encontré esto sobre lo que parece ser un problema similar: (aunque bastante antiguo)

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

Entonces, ¿podría ser que la consulta sea demasiado para su especificación?

[jimmy0017]

No tenemos un megatema. Al menos no estoy al tanto de ello. Si hay un comando SQL que pueda ejecutar y verificar, sería genial.
Tenemos una CPU de 32 núcleos + 128 GB de RAM.. No estoy seguro de si esto es una limitación. Si hay algo que deba cambiar en la base de datos, por favor hágamelo saber.

[JammyDodger]

@jimmy0017

No tenemos un megatema. Al menos no que yo sepa. Si hay un comando SQL que pueda ejecutar y comprobar, sería genial.

Creo que si tuvieras uno, probablemente lo sabrías, pero puedes cambiar tu lista /latest al orden de actividad para comprobarlo usando el título de la columna o usando TuSitio/latest?order=posts.

Pero algo como esto en el explorador de datos también debería mostrarte los 10 principales:

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

El SQL para la insignia de Lector está aquí:

lib/badge_queries.rb

La insignia de Lector no es necesariamente una de las más emocionantes, así que si puedes vivir con deshabilitarla y eso soluciona todo, esa podría ser la salida fácil. Pero si quieres explorarla más a fondo, creo que querrás mirar tu tabla post_timings para ver lo grande que se ha vuelto.

[jimmy0017]

Vi un par de temas gigantes. Pero hemos limitado a 10k respuestas y lo hemos dividido.

Lo deshabilitaré por ahora. Pero aquí están las 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]

Eso parece bastante importante.

En el caso de que no lo hayas hecho en ese momento (dependiendo de la antigüedad de tu foro), se dio este consejo en PostgreSQL 13 update

@fitzy

Recreación de los índices

La característica principal de esta actualización es un gran ahorro de archivos en nuestra tabla más grande en cada instancia, la tabla post_timings y sus índices. Después de realizar una actualización exitosa, deberá ejecutar un comando para reconstruir los índices y obtener los beneficios.

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

Si puedes comprobar el tamaño de post_timings antes y después de REINDEX, ¡sería una estadística interesante para compartir aquí!

Desafortunadamente, no tengo experiencia directa con esto, así que es posible que tengamos que esperar a que aparezca alguien inteligente para un análisis más profundo.

[jimmy0017]

Sí. Hice esto cuando actualicé a PostgreSQL 13. También lo ejecuté ayer. Pero el tamaño de la base de datos no cambió.

Esperemos que alguien más pueda comentar cómo reducir el tamaño.

¡Gracias de todos modos!