Abbiamo molti di questi errori nel log. C’è qualcosa che possiamo/dovremmo fare?
Info:
Job exception: Failed to backfill ‘Reader’ badge: {: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)>}. Reason: ERROR: canceling statement due to statement timeout
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'
Potrebbe essere un problema con un argomento particolarmente grande? Avete dei megatopic che potrebbero essergli di peso?
Se il processo di assegnazione dei badge viene bloccato interamente a causa di ciò, potrebbe essere un’idea disabilitare temporaneamente il badge Reader e vedere se questo aiuta.
Ho trovato questo su quello che sembra essere un problema simile: (anche se piuttosto vecchio)
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
Quindi potrebbe essere che la query sia eccessiva per le vostre specifiche?
Non abbiamo un megatema. Almeno non ne sono a conoscenza. Se c’è un comando SQL che posso eseguire per verificare, sarebbe ottimo.
Penso che se ne avessi uno lo sapresti, ma puoi trasformare la tua lista /latest in ordine di attività per ricontrollare usando il titolo della colonna o usando YourSite/latest?order=posts.
Ma qualcosa del genere nell’esploratore di dati dovrebbe anche mostrarti i primi 10:
SELECT id AS topic_id
FROM topics
ORDER BY posts_count DESC
LIMIT 10
L’SQL per il badge Reader è qui:
Reader = <<~SQL
SELECT id user_id, current_timestamp granted_at
FROM users
WHERE id IN
(
SELECT pt.user_id
FROM post_timings pt
JOIN badge_posts b ON b.post_number = pt.post_number AND
b.topic_id = pt.topic_id
JOIN topics t ON t.id = pt.topic_id
LEFT JOIN user_badges ub ON ub.badge_id = 17 AND ub.user_id = pt.user_id
WHERE ub.id IS NULL AND t.posts_count > 100
GROUP BY pt.user_id, pt.topic_id, t.posts_count
HAVING count(*) >= t.posts_count
)
SQL
Il badge Reader non è necessariamente uno dei più entusiasmanti, quindi se puoi convivere con la disabilitazione e questo risolve tutto, potrebbe essere la via più semplice. Ma se vuoi esplorarlo ulteriormente, penso che potresti voler guardare la tua tabella post_timings per vedere quanto è diventata grande.
Ho visto un paio di mega argomenti. Ma abbiamo limitato a 10.000 risposte e lo dividiamo.
Lo disattiverò per ora. Ma ecco il 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
Sembra proprio un bel problema.
Non si sa mai, nel caso non l’avessi fatto al momento (a seconda di quanto è vecchio il tuo forum), c’era questo consiglio dato qui: PostgreSQL 13 update
fitzy:
Ricreazione degli indici
La funzione principale di questo aggiornamento è un grande risparmio di spazio nelle nostre tabelle più grandi in ogni istanza, la tabella post_timings e i suoi indici. Dopo aver eseguito un aggiornamento con successo, dovrai eseguire un comando per ricostruire gli indici e raccoglierne i benefici.
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
REINDEX SCHEMA CONCURRENTLY public;
\q
exit
exit
Se riesci a controllare la dimensione di post_timings prima e dopo il REINDEX, sarebbe una statistica interessante da condividere qui!
Purtroppo non ho esperienza diretta in merito, quindi potremmo dover aspettare che arrivi qualcuno di più esperto per un’analisi più approfondita.
Sì. Ho fatto questo quando sono passato a PostgreSQL 13. L’ho eseguito anche ieri. Ma la dimensione del database non è cambiata.
Spero che qualcun altro possa intervenire su come ridurre la dimensione.
Grazie comunque!
