“Failed to backfill 'Reader' badge” 오류가 많이 발생했습니다

지원
1

로그에 이러한 오류가 많이 발생하고 있습니다. 우리가 하거나 해야 할 조치가 있을까요?

정보:

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'
3

특히 큰 토픽으로 인한 문제일 수 있습니다. 부하를 줄 수 있는 메가토픽이 있나요?

이 문제로 인해 배지 부여 작업이 완전히 차단되고 있다면, 리더 배지를 일시적으로 비활성화해 보도록 하는 것이 도움이 될 수 있습니다.

유사한 문제로 보이는 것을 찾았습니다: (다만 꽤 오래된 것입니다)

따라서 쿼리가 서버 사양에 비해 과부하를 주고 있는 것일 수 있습니다.

4

메가토픽이 있는지 모르겠습니다. 만약 실행하여 확인할 수 있는 SQL 명령어가 있다면 알려주시면 좋겠습니다.
CPU 32코어와 RAM 128GB를 보유하고 있습니다. 이것이 제한 사항인지 확실하지 않습니다. 데이터베이스에서 변경해야 할 사항이 있다면 알려주세요.

5

있다면 아마도 아실 것 같지만, /latest 목록을 활동 순서로 정렬하여 확인해 볼 수 있습니다. 컬럼 제목을 사용하거나 YourSite/latest?order=posts를 사용하면 됩니다.

하지만 데이터 탐색기(data explorer)에서 다음과 같은 쿼리를 실행하면 상위 10개 항목도 확인할 수 있습니다:

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

리더(Reader) 배지의 SQL은 여기에 있습니다:

리더 배지는 가장 흥미로운 배지 중 하나가 아니므로, 이를 비활성화하는 것이 문제를 해결할 수 있다면 그것이 가장 쉬운 방법일 수 있습니다. 하지만 더 깊이 살펴보고 싶다면 post_timings 테이블을 확인하여 얼마나 커졌는지 보는 것이 좋습니다.

6

메가 토픽을 몇 개 발견했습니다. 하지만 현재 10k(1만 개) 응답으로 제한을 걸고 나누어 처리하고 있습니다.

일단 비활성화하겠습니다. 여기 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
7

꽤나 묵직한 것 같네요. :slight_smile:

혹시 그 당시 이 작업을 수행하지 않으셨다면 (포럼의 연식에 따라 다릅니다), 다음 링크에서 이러한 조언이 제시되었습니다: PostgreSQL 13 update

불행히도 저는 이 부분에 대해 직접적인 경험이 없어서, 더 깊이 파고들려면 현명한 누군가의 출현을 기다려야 할 수도 있습니다. :nerd_face:

8

네. PostgreSQL 13으로 업그레이드했을 때 이 작업을 수행했습니다. 어제에도 다시 실행해 보았지만, DB 크기는 변하지 않았어요.

크기를 줄이는 방법에 대해 다른 분들이 의견을 주시면 좋겠습니다.

그럼에도 감사합니다!