우선 정말 감사합니다! 컨테이너 내부에서 수동으로 서비스를 중지한 것이 효과를 봤는지, 업그레이드를 위해 컨테이너를 두 번 다시 빌드하는 데 성공했습니다(위에서 논의된 대로 로케일 변수를 조정했습니다. 참고로: 설치 문서를 확인해 봤는데 로케일에 대한 언급이 없는 것 같습니다. 이 부분을 추가하면 좋겠다는 생각이 드네요).
불행히도 문제 있는 프로세스에 대한 분석은 결론을 내리지 못했습니다. 제가 볼 수 있는 것은 WalWriter, AutoVacuum 같은 Postgres 관련 항목뿐입니다. 제가 가진 유일한 단서는 시스템을 재부팅하거나 업데이트 시 인덱스를 변경한 후 약 30분 동안 Postgres의 CPU 부하가 높게 나타난다는 점입니다.
그리고 오늘 재부팅 후 pg_stat_activity를 확인해 보니 두 개의 장시간 실행 중인 쿼리를 발견했습니다(제 열 해석이 맞다면요):
SELECT "posts"."id" FROM "posts" INNER JOIN "topics" ON "topics"."deleted_at" IS NULL AND "topics"."id" = "posts"."topic_id" LEFT JOIN post_search_data ON post_id = posts.id WHERE "posts"."deleted_at" IS NULL AND (posts.raw != '') AND (topics.deleted_at IS NULL) AND (post_search_data.locale IS NULL OR post_search_data.locale != 'de' OR post_search_data.version != 5) ORDER BY posts.id DESC LIMIT 20000
그리고
SELECT "optimized_images".* FROM "optimized_images" WHERE "optimized_images"."upload_id" = 13 AND "optimized_images"."height" = 32 AND "optimized_images"."width" = 32 LIMIT 1
aforementioned 30분 후, 첫 번째 쿼리는 완료된 것으로 보이며 Postgres의 CPU 부하는 이제 정상 수준입니다.
이 두 쿼리가 왜这么久 걸리는지, 그리고 두 번째 쿼리가 1시간 이상 지난 후에도 pg_stat_activity에 여전히 표시되는 이유는 더 잘 모르겠습니다. 하지만 어쩌면 이러한 장시간 실행 중인 쿼리가 이전에 재빌드 시도를 할 때 Postgres 서비스가 올바르게 종료되는 것을 막았을 수도 있습니다.
이 부분에 대해 단서가 있으시다면 정말 감사하겠습니다. 하지만 이 문제는 별도의 스레드로 이관해야 할 수도 있습니다(그렇다면 알려 주세요. 이 게시글을 수정하겠습니다).
관련 스크린샷:
