Habe viele Fehler "Failed to backfill 'Reader'-Abzeichen"

[jimmy0017]

Wir haben viele dieser Fehler im Log. Gibt es etwas, das wir tun können/sollten?

Info:

Job-Ausnahme: Fehler beim Auffüllen des ‘Reader’-Abzeichens: {: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)>}. Grund: FEHLER: Anweisung wird wegen Anweisungszeitüberschreitung abgebrochen

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]

Könnte dies ein Problem mit einem besonders großen Thema sein? Haben Sie Megathemen, die es belasten könnten?

Wenn der Job zur Vergabe von Abzeichen dadurch vollständig blockiert wird, könnte es eine Idee sein, das Leser-Abzeichen vorübergehend zu deaktivieren und zu sehen, ob das hilft.

---

Ich habe Folgendes zu einem scheinbar ähnlichen Problem gefunden: (obwohl ziemlich alt)

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

Es könnte also sein, dass die Abfrage zu viel für Ihre Spezifikationen ist?

[jimmy0017]

Wir haben kein Megathema. Zumindest ist mir keins bekannt. Wenn es einen SQL-Befehl gibt, den ich ausführen und überprüfen kann, wäre das großartig.
Wir haben einen 32-Kern-CPU + 128 GB RAM.. Ich bin mir nicht sicher, ob das eine Einschränkung ist. Falls ich etwas in der Datenbank ändern muss, lassen Sie es mich bitte wissen.

[JammyDodger]

@jimmy0017

Wir haben kein Megatopic. Zumindest bin ich mir dessen nicht bewusst. Wenn es einen SQL-Befehl gibt, den ich ausführen und überprüfen kann, wäre das großartig.

Ich denke, wenn Sie eines hätten, würden Sie es wahrscheinlich wissen, aber Sie können Ihre /latest-Liste umordnen, um sie anhand des Spaltentitels oder mit YourSite/latest?order=posts zu überprüfen.

Aber etwas wie dieses im Daten-Explorer sollte Ihnen auch die Top 10 anzeigen:

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

Die SQL für das Reader-Abzeichen finden Sie hier:

lib/badge_queries.rb

Das Reader-Abzeichen ist nicht unbedingt eines der aufregendsten. Wenn Sie also damit leben können, es zu deaktivieren, und das alles behebt, könnte das der einfache Ausweg sein. Aber wenn Sie es weiter untersuchen möchten, sollten Sie sich wahrscheinlich Ihre post_timings-Tabelle ansehen, um zu sehen, wie groß sie geworden ist.

[jimmy0017]

Ich habe ein paar Megothemen gesehen. Aber wir haben bei 10.000 Antworten das Limit gesetzt und teilen es auf.

Ich werde es vorerst deaktivieren. Hier ist rake db:stats

Tabellenname                                    | Geschätzte Zeilen | Tabellengröße | Indexgröße | Gesamgröße
---------------------------------------------------------------------------------------------
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]

Das scheint in der Tat ein ordentliches Ding zu sein.

Nur für den Fall, dass Sie dies zu diesem Zeitpunkt nicht getan haben (abhängig davon, wie alt Ihr Forum ist), gab es diesen Rat in PostgreSQL 13 update

@fitzy

Re-creating the indexes

This upgrade main feature is great file savings in our largest table in every instance, the post_timings table and it’s indexes. After doing a successful update you will need to run a command to re-build the indexes and reap the benefits.

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

If you can check the post_timings size before and after the REINDEX that would be a cool stat to share here!

Leider habe ich keine direkte Erfahrung damit, daher müssen wir möglicherweise warten, bis jemand Schlaues auftaucht, um tiefer einzutauchen.

[jimmy0017]

Ja. Ich habe das gemacht, als ich auf PostgreSQL 13 aktualisiert habe. Ich habe es auch gestern ausgeführt. Aber die Datenbankgröße hat sich nicht verändert.

Hoffentlich kann jemand anders sagen, wie man die Größe reduzieren kann.

Danke trotzdem!