В логе много подобных ошибок. Есть что-то, что мы можем или должны сделать?
Информация:
Исключение задачи: Не удалось выполнить обратное заполнение значка ‘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)>}. Причина: ОШИБКА: отмена оператора из-за тайм-аута оператора
Трассировка:
/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'
Может ли это быть связано с особенно большой темой? Есть ли у вас мега-темы, которые могут создавать нагрузку?
Если задача выдачи значков полностью блокируется из-за этого, возможно, стоит временно отключить значок Reader и посмотреть, поможет ли это.
Я нашел информацию о похожей проблеме (хотя она довольно старая):
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
Возможно, запрос слишком тяжелый для вашей конфигурации?
У нас нет мега-темы. По крайней мере, я не знаю о такой. Если есть SQL-команда, которую мне нужно выполнить и проверить, это было бы здорово.
У нас процессор с 32 ядрами и 128 ГБ оперативной памяти… Я не уверен, является ли это ограничением. Если нужно что-то изменить в базе данных, пожалуйста, дайте мне знать.
jimmy0017:
У нас нет мега-темы. По крайней мере, я не знаю о такой. Если бы существовала команда SQL, которую мне нужно было бы запустить и проверить, это было бы отлично.
Думаю, если бы у вас такая была, вы бы, скорее всего, знали об этом, но вы можете переключить свой список /latest в порядок активности, чтобы перепроверить это, используя заголовок столбца или адрес YourSite/latest?order=posts.
Однако что-то вроде этого в Data Explorer также покажет вам топ-10:
SELECT id AS topic_id
FROM topics
ORDER BY posts_count DESC
LIMIT 10
SQL-запрос для значка «Читатель» находится здесь:
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
Значок «Читатель» не обязательно является самым захватывающим, поэтому, если вы можете мириться с его отключением и это решит все проблемы, это может стать простым выходом. Но если вы хотите изучить его подробнее, рекомендую посмотреть таблицу post_timings, чтобы оценить, насколько она разрослась.
Я заметил пару мега-тем. Но мы ограничили количество ответов до 10 тысяч и разделили их.
На время я отключу это. Вот вывод команды 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
Это действительно выглядит как мощный вариант.
На всякий случай, если вы этого не сделали в свое время (в зависимости от возраста вашего форума), вот рекомендация, которая была дана здесь: PostgreSQL 13 update
fitzy:
Пересоздание индексов
Главная особенность этого обновления — значительная экономия места на диске в самой большой таблице на каждом экземпляре, а именно в таблице post_timings и её индексах. После успешного обновления необходимо выполнить команду для перестройки индексов и получения преимуществ.
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
REINDEX SCHEMA CONCURRENTLY public;
\q
exit
exit
Если вы сможете проверить размер post_timings до и после REINDEX, это была бы отличная статистика для публикации здесь!
К сожалению, у меня нет прямого опыта в этом вопросе, поэтому, возможно, придётся подождать, пока кто-то более компетентный заглянет и проведёт глубокий анализ.
Да. Я делал это, когда обновлялся до PostgreSQL 13. Запускал и вчера, но размер базы данных не изменился.
Надеюсь, кто-нибудь ещё подскажет, как уменьшить размер.
Спасибо всё же!