안녕하세요.
여기에도 게시글을 올렸습니다: Moving posts returns 502 bad gateway - #63 by Canapin
하지만 에러가 다른 맥락에서도 발생하는 것 같습니다. 카테고리를 이름 변경할 수 없어요:
JS 콘솔:
안전 모드에서도 동일합니다(어쨌든 data-explorer를 제외하고 커스텀 테마나 플러그인은 사용하지 않습니다). 버전은 2.6.0.beta2입니다.
서버는 Ubuntu 18을 사용 중이며, vCPU 4개, RAM 8GB, 디스크 공간 160GB입니다.
에ラー가 나타나는 데 시간이 오래 걸리나요? 무거운 쿼리 때문에 타임아웃이 발생하는 것 같습니다.
20~30초 정도일까요? 또한 다른 카테고리를 이름 변경할 때는 이런 현상이 발생하지 않습니다. 
수정: 제 개발용 포럼(상당히 성능이 좋은 컴퓨터에 Ubuntu 서브시스템이 설치된 환경)에서도 같은 문제가 발생합니다.
다시 수정:
더 작은 배치로 나누어 처리하면 작동하는 것 같습니다. 즉, Discourse는 더 강력한 서버(16 vCPU / 32 GB로 업그레이드했습니다)를 사용하더라도 3000개 이상의 주제를 이동하는 것을 선호하지 않는 것으로 보입니다. 따라서 이 문제는 제 카테고리 이름 변경 문제와는 다른 것 같습니다. 여전히 카테고리를 이름 변경할 수 없습니다.
새로운 카테고리 B(이름을 마음대로 변경할 수 있는 카테고리)를 만들고, 카테고리 A(이름을 변경할 수 없는 카테고리)의 모든 주제를 카테고리 B로 이동했습니다. 그 후로는 카테고리 B의 이름을 변경할 수 없게 되었고, 대신 카테고리 A의 이름을 변경할 수 있게 되었습니다.
카테고리 이름 변경을 시도할 때마다 게시글 수가 더 많은 카테고리를 선택해 보았습니다. 콘텐츠가 더 많은 카테고리(게시글이 많고, 주제가 큰 경우)일수록 이름 변경에 더 오래 걸리는 것 같습니다.
이름을 변경할 수 없는 카테고리가 2개 있습니다(실제로 시간이 너무 오래 걸리는 것 같습니다…):
답글이 없는 주제만 포함된 ‘공개 프로필 메시지’ 카테고리의 이름은 변경할 수 있습니다.
30초는 nginx 타임아웃이라 그럴 만합니다. 다만 그보다 더 시간이 필요합니다.
제가 그 자리에 있다면 rails 콘솔에서 이걸 시도해 볼 거예요.
이렇게 하는 걸로 생각했지만, 안전할지 확신이 서지 않았습니다: Discourse에서 카테고리 제목을 변경하는 데 왜 그렇게 시간이 걸리는지 궁금하네요
내가 생각하지 못하는 것들을 확인해야 하는 건가요?
그런 것 같습니다 
일부 통계를 다시 계산하고 있는 것일 수 있습니다. Postgres에 연결하여 다음과 같은 쿼리를 실행해 보실 수 있습니다.
SELECT pid, age(query_start, clock_timestamp()), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
이렇게 하면 무엇이 이렇게 오래 걸리고 있는지 확인할 수 있습니다.
감사합니다!
다만, 이 부분은 잘 모르겠습니다. Discourse가 카테고리 이름을 변경하려는 동안 이 쿼리를 실행해야 하나요?
네, 현재 실행 중인 쿼리를 표시해 주므로 대기하면서 실행해 보세요. 30초 동안 가능합니다 
매우 자명한 쿼리(UPDATE categories...)가 이미 13초나 걸리는 것처럼 보입니다…
수동으로 실행하면 어떻게 되나요?
수정: 만약 이 포럼이 가져온(imported) 것이라면, 백업한 후 다시 복구하는 것이 도움이 될 수 있습니다.
개인 컴퓨터의 개발용 설치 환경에서도 동일한 문제가 발생하여, 개발용 포럼에서 테스트를 해보았습니다.
Discourse 인터페이스를 통해 카테고리 이름을 변경해 보았더니, 첫 번째 게시글에서 보여드린 오류가 발생하고 RAM이 가득 차버렸습니다:
쿼리 결과는 다음과 같습니다:
rails 콘솔을 통해 업데이트를 시도해 보았고, 다음 두 명령어를 실행했습니다:
ActiveRecord::Base.connection.execute("UPDATE categories SET name = 'General Discussion', topic_template = '', sort_order = '', default_view = '', read_only_banner = '', name_lower = 'general_discussion', updated_at = '2020-09-16 13:36:50.014192' WHERE categories.id = 21")
Category.where(id: 21).update(name: "General")
두 명령어 모두 완벽하게 작동했습니다.
그건… 재밌네…
업데이트: 다른 운영 중인 포럼(데이터/서버/OS 등이 다르지만 동일한 Discourse 버전 사용)에서 카테고리를 이름 변경을 시도해 보았습니다.
카테고리 이름 변경이 느립니다(약 10초 소요). 여러 번 시도해 보았으며, 한 번은 502 오류도 발생했습니다.
이것이 최근 업데이트와 관련된 Discourse의 문제인 것 같습니다.
두 포럼 모두 2.6.0.beta2 버전을 사용하고 있습니다.
동일한 Discourse 버전을 사용하는 자신의 포럼에서(수천 개 또는 수만 개의 주제를 가진 카테고리를 대상으로) 카테고리 이름 변경을 시도해 보시고, 느리거나 502 오류가 발생하는지 확인해 주실 수 있을까요?
이전 Discourse 버전에서 많은 수의 주제를 가진 카테고리를 빠르게 이름 변경할 수 있었나요?
이전에 사용하던 포럼(이것도 가져온 것)에서 502 오류가 발생했던 기억은 없지만, 3년 전 가져온 이후로 카테고리를 이름 변경한 적이 없습니다. 카테고리를 이름 변경하는 작업이 느렸는지는 기억이 나지 않습니다.
새로 만든, 규모가 더 큰 포럼은 제가 언급한 Discourse 버전으로 가져온 것이기 때문에 이전 버전과 비교할 수 없습니다.
이 부분에 대한 정정입니다. 이전에 제가 Category.where(id: 21).update(name: "General") 명령어를 사용했던 것은 아마도 주제들을 다른 곳으로 이동시킨 카테고리 때문이었던 것 같습니다. 현재 저는 여러 카테고리에 대해 이 명령어를 여러 번 사용해야 했으며, 명령어 실행 시간이 대상 카테고리의 게시글 수에 비례하는 것으로 보입니다.
즉, 인터페이스에서 카테고리를 업데이트할 때 발생하는 문제와 본질적으로 동일한 문제입니다. 다만 커맨드 라인에서는 타임아웃이 발생하지 않는다는 차이가 있습니다.
30,000개 이상의 주제를 가진 카테고리에서는 약 1분 이상 걸렸고, 15,000개 이상의 주제를 가진 카테고리에서는 30초 이상 걸렸으며, 주제가 적은 카테고리에서는 빠르게 처리되었습니다.
지난 6개월 동안 우리 포럼에서 오류가 점점 더 빈번해지고 있습니다. 서버 리소스를 2배로 늘린 상태(16 CPU, 64GB RAM)이며, 이전보다 훨씬 잘 돌아가고 있지만 재현 가능한 오류를 발견했습니다.
단일 카테고리 이름만 변경해도 매번 502 오류가 발생합니다.
app.yml 설정을 이에 맞게 조정하셨나요?
힌트를 얻을 수 있는지 로그를 확인해 보시기 바랍니다. 해당 카테고리에 특별한 점이 있나요? 아마 데이터베이스 인덱스 손상일 수도 있습니다.
네, 그렇게 했습니다!
그냥 forumwebsite.com/logs만 보는 건가요? 카테고리를 이름 변경하는 동작과 구체적으로 관련된 오류는 보이지 않습니다.
Info 로그에는 많은 항목이 보이긴 하지만, 역시 해당 동작과 구체적으로 관련된 내용은 없습니다.
어떤 오류든 해결해 보려고 해야 하나요?
웹 인터페이스에서 /admin/logs(또는 이와 유사한 경로)를 확인하거나, 다음과 같은 명령을 사용할 수 있습니다.
tail -f /var/discourse/shared/standalone/logs/rails/production.log
기억을 바탕으로 손으로 직접 입력한 것이므로, 탭 완성 기능을 사용하는 것을 권장합니다.