이 가장 짜증나는 버그는 여전히 우리와 함께 있습니다.
문제를 해결하는 방법에 대한 지침을 제공해 주시겠습니까?
불행히도 여전히 이 문제를 가끔 겪고 있습니다. 최근 기존 주제(2013개의 게시물)로 27개의 게시물을 이동하는 작업이 실패한 문제에 대해 몇 가지 데이터를 수집했습니다:
Beginning move at 2021-05-25 20:54:57 +0000
create_temp_table
0.000134 0.000027 0.000161 ( 0.002810)
delete_invalid_post_timings
0.000317 0.000065 0.000382 ( 0.306869)
move_incoming_emails
0.000056 0.000006 0.000062 ( 0.000478)
move_notifications
0.000074 0.000008 0.000082 ( 0.005584)
update_reply_counts
0.000088 0.000010 0.000098 ( 0.001058)
update_quotes
0.000079 0.000008 0.000087 ( 0.002426)
move_first_post_replies
0.000071 0.000008 0.000079 ( 0.000695)
delete_post_replies
0.000062 0.000006 0.000068 ( 0.000834)
copy_first_post_timings
0.000064 0.000007 0.000071 ( 0.002660)
move_post_timings
0.000082 0.000009 0.000091 ( 0.008195)
copy_topic_users
0.000398 0.000043 0.000441 ( 0.043640)
move_each_post
4.345220 0.132652 4.477872 ( 3.447047)
create_moderator_post_in_original_topic
0.163962 0.000253 0.164215 ( 0.207101)
update_statistics
0.217266 0.051660 0.268926 ( 45.258070)
update_user_actions
0.000934 0.000101 0.001035 ( 0.178894)
update_last_post_stats
0.001589 0.000171 0.001760 ( 0.003156)
update_upload_security_status
0.000030 0.000003 0.000033 ( 0.000034)
update_bookmarks
0.000492 0.000054 0.000546 ( 0.003832)
Finished move at 2021-05-25 20:55:47 +0000
대부분의 메서드는 매우 빠르게 종료되지만, 이 경우 update_statistics는 45초가 넘는 시간이 걸렸습니다. 이 모든 시간은 다음 메서드 호출에 소요되었습니다:
update_statistics 작업을 sidekiq로 넘기는 건 어떨까요?
네, 그럴 가능성이 높습니다. 하지만 전체 프로세스를 Sidekiq 작업으로 이동시키고 UI가 완료될 때까지 대기하도록 하는 것이 얼마나 복잡한지 꼼꼼히 살펴볼 계획입니다. 우리는 계속 조각조각을 작업으로 옮기면서 지렁이 놀이를 하고 있는 셈이니까요.
수고하셨습니다!
토픽을 병합하려고 할 때 저도 502 오류가 발생합니다. 매번 그런 것은 아니지만, 꽤 자주 발생합니다.
이미 존재하는 주제에 대해 누군가 새로운 토픽을 만들었을 때 이 작업을 수행합니다. 따라서 보통은 매우 적은 수의 게시물(최대 5개)만 이동하려고 합니다.
이 토픽 전체를 읽지는 않았지만, 이것이 현재 작업 중인 알려진 문제이며, 제가 직접 해결할 수 있는 방법은 없다는 것으로 이해하고 있습니다.
게시글을 이동할 때 502 오류가 발생하고 있습니다.
이전에는 간헐적으로만 발생했고, 반복 시도하면 대부분 해결되었습니다. 하지만 지금은 특정 상황에서 2,000개 정도의 긴 토픽으로 단일 게시글을 이동할 때 약 30초 후 타임아웃이 발생하며 일관되게 실패하고 있습니다.
이 문제가 발생할 때 서버는 특별히 바쁘지 않고, 나머지 활동에는 정상적으로 대응하고 있습니다. 활동량이 적은 시간에 게시글 이동을 시도해도 결과는 동일합니다. 안전 모드에서도 차이가 없습니다.
인스턴스 스펙을 올리는 것(이것이 해결책 중 하나라고 가정할 경우)을 제외하고, 시도해 볼 수 있는 다른 방법이 있을까요? 도움이 된다면 추가 정보를 제공하겠습니다. 참고로 현재 최신 안정판(stable)을 사용 중이며, 이 문제에 대한 최근 변경 사항이 있다면 최신 베타판으로 전환하는 것도 고려해 보겠습니다.
주말(저희의 가장 느린 시기)에는 스토리지 최대 IOPS를 일시적으로 3배로 올리고, 최대 처리량도 3배로 늘렸지만, 기존 2,000개 게시글이 있는 주제로 단일 게시글을 이동시키지조차 못했습니다.
주제 자체에 새 답변을 남기는 것은 문제가 없어 보이므로, 게시글이 새로 생성되는 것이 아니라 어딘가에서 이동될 때 훨씬 더 많은 추가 작업이 필요할 것 같습니다. 30초 이내에 완료할 수 없다면, ‘502 오류’ 메시지와 함께 실패하는 것보다 백그라운드 작업으로 처리하는 것이 좋지 않을까요?
네, 3000개 이상의 게시글이 있는 오래되고 긴 주제에서도 저한테도 같은 일이 일어나요.
여전히 불편하네요.
안녕하세요
모든 답변을 포함하여 한 주제를 다른 주제에 병합할 수 없는 비슷한 문제를 겪고 있습니다. 병합하려는 대상 주제는 23개의 게시글이 있고, 이동하려는 주제는 게시글이 4개뿐입니다.
|
에러 로그
Message (4 copies reported)
Failed to process hijacked response correctly : PG::UniqueViolation : ERROR: duplicate key value violates unique constraint "post_timings_unique"
DETAIL: Key (topic_id, post_number, user_id)=(62975, 19, 538) already exists.
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/patches/db/pg.rb:110:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/patches/db/pg.rb:110:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:217:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `block in run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `block in with_lock'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in `with_lock'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in `run'
/var/www/discourse/lib/mini_sql_multisite_connection.rb:109:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:196:in `exec'
/var/www/discourse/app/models/post_mover.rb:517:in `move_post_timings'
/var/www/discourse/app/models/post_mover.rb:142:in `handle_moved_references'
/var/www/discourse/app/models/post_mover.rb:112:in `move_posts_to'
/var/www/discourse/app/models/post_mover.rb:35:in `block in to_topic'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:616:in `block in within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/transaction.rb:613:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/database_statements.rb:361:in `transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:234:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:415:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_handling.rb:296:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/transactions.rb:233:in `transaction'
/var/www/discourse/app/models/post_mover.rb:35:in `to_topic'
/var/www/discourse/app/models/topic.rb:1308:in `move_posts'
/var/www/discourse/app/controllers/topics_controller.rb:883:in `block in merge_topic'
/var/www/discourse/lib/hijack.rb:64:in `instance_eval'
/var/www/discourse/lib/hijack.rb:64:in `block in hijack'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:797:in `call_callback'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve_with'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.4/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve'
/var/www/discourse/lib/scheduler/defer.rb:125:in `block in do_work'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/lib/scheduler/defer.rb:119:in `do_work'
/var/www/discourse/lib/scheduler/defer.rb:105:in `block (2 levels) in start_thread'
참고: 에러 메시지에 already exists(이미 존재함)라고 나와 있지만 실제로는 별개의 주제입니다. 이것이 관련이 있는지 모르겠지만, 이 에러가 나타나기 전에 이 주제를 병합하려는 23개 게시글이 있는 주제에 여러 주제와 그 게시글들을 이동했습니다(다른 주제들도 같은 방식으로 처리했습니다).
감사합니다!
최근 며칠 동안 업데이트를 하셨나요? 게시글 이동과 관련된 최근 수정 사항이 있습니다.