J'ai beaucoup d'erreurs « Échec de la récupération du badge 'Reader' »

[jimmy0017]

Nous avons beaucoup de ces erreurs dans le journal. Y a-t-il quelque chose que nous puissions/devrions faire ?

Info :

Erreur de tâche : Échec du remplissage du badge ‘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)>}. Raison : ERREUR : annulation de l’instruction en raison du délai d’attente de l’instruction

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]

Cela pourrait-il être un problème avec un sujet particulièrement volumineux ? Avez-vous des méga-sujets qui pourraient lui peser ?

Si le travail d’attribution des badges est complètement bloqué à cause de cela, il pourrait être judicieux de désactiver temporairement le badge Lecteur et de voir si cela aide.

---

J’ai trouvé ceci sur ce qui semble être un problème similaire : (bien qu’assez ancien)

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

Il se pourrait donc que la requête soit trop importante pour vos spécifications ?

[jimmy0017]

Nous n’avons pas de méga-sujet. Du moins, je n’en suis pas au courant. S’il existe une commande SQL que je peux exécuter pour vérifier, ce serait génial.
Nous avons un CPU à 32 cœurs + 128 Go de RAM.. Je ne suis pas sûr si c’est une limitation. Si je dois changer quelque chose dans la base de données, veuillez me le faire savoir.

[JammyDodger]

@jimmy0017

Nous n’avons pas de méga-sujet. Du moins, je ne suis pas au courant. S’il existe une commande SQL que je peux exécuter et vérifier, ce serait formidable.

Je pense que si vous en aviez un, vous le sauriez probablement, mais vous pouvez transformer votre liste /latest en ordre d’activité pour vérifier à nouveau en utilisant le titre de la colonne ou en utilisant YourSite/latest?order=posts.

Mais quelque chose comme ceci dans l’explorateur de données devrait également vous montrer les 10 premiers :

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

Le SQL pour le badge Lecteur est ici :

lib/badge_queries.rb

Le badge Lecteur n’est pas nécessairement l’un des plus excitants, donc si vous pouvez vous en passer et que cela résout tout, ce pourrait être la solution la plus simple. Mais si vous souhaitez l’explorer davantage, je pense que vous voudrez peut-être examiner votre table post_timings pour voir sa taille.

[jimmy0017]

J’ai vu quelques méga sujets. Mais nous avons atteint la limite de 10 000 réponses et nous les avons réparties.

Je vais le désactiver pour l’instant. Mais voici 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]

Cela semble en effet être un gros problème.

Au cas où vous n’auriez pas fait cela à l’époque (selon l’âge de votre forum), voici un conseil donné dans PostgreSQL 13 update

@fitzy

Re-création des index

La principale caractéristique de cette mise à niveau est une grande économie d’espace dans notre plus grande table dans chaque instance, la table post_timings et ses index. Après une mise à jour réussie, vous devrez exécuter une commande pour reconstruire les index et en récolter les bénéfices.

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

Si vous pouvez vérifier la taille de post_timings avant et après le REINDEX, ce serait une statistique intéressante à partager ici !

Malheureusement, je n’ai aucune expérience directe à ce sujet, nous devrons donc peut-être attendre que quelqu’un d’intelligent se manifeste pour une analyse plus approfondie.

[jimmy0017]

Oui. Je l’ai fait lorsque j’ai mis à jour vers PostgreSQL 13. Je l’ai aussi exécuté hier. Mais la taille de la base de données n’a pas changé.

J’espère que quelqu’un d’autre pourra donner des conseils pour réduire la taille.

Merci quand même !