전반적으로는 순조롭게 진행되었지만, 이후 Postgres 프로세스가 코어 100%를 사용하며 폭주하는 문제가 발생했습니다. 프로세스 수는 다양했습니다. 재구축부터 재시작까지 여러 가지 방법을 시도해 보았습니다. 현재는 rake db:validate_indexes를 실행 중인데, 이미 몇 시간째 아무 피드백도 없습니다. 이전에 이 작업을 수행한 적이 있는지, 그리고 더 빨리 완료되는 것이 정상인지 확실하지 않습니다.
포럼 사용 자체는 기본적으로 잘 되지만, 확실히 느려졌습니다. 활성도가 높은 사용자의 프로필을 불러오는 것과 같은 긴 실행 시간이 필요한 작업은 평소보다 눈에 띄게 더 오래 걸립니다.
데이터베이스에 문제가 있는 것 같지만, 어떤 문제인지 파악하기가 어렵습니다.
솔직히 말씀드리면, 저희 데이터베이스가 꽤 큽니다 - 복원 후 인덱스 생성까지 완료된 상태로는 약 150GB입니다. 복원 과정을 모니터링하면서 에러는 확인되지 않았고, 인덱스 생성도 제 눈에는 정상적으로 진행되었습니다.
이 문제를 해결하는 방법에 대한 아이디어가 있을까요? 현재는 Postgres 프로세스가 3개입니다 - 몇 시간 전에 재시작하기 전에는 6개였습니다 - 복원 후 16개 코어가 모두 사용되기도 했습니다.
수정: 방금 3개의 sidekiq 프로세스가 “indexing categories for search” 상태로 멈춰 있는 것을 발견했습니다. 이것이 모두 검색 인덱스 재구축 때문일까요? 그렇다면 다른 방법으로 해결할 수 있을까요? 라이브 시스템 복원을 수행할 때, 성능이 이렇게 수 시간 또는 심지어 며칠 동안 저하된다면 큰 문제가 될 것입니다.
이전에 ‘stuck’ 상태였던 7개의 Postgres 프로세스를 종료하기 위해 포럼을 읽기 전용으로 설정하고 VM을 재시작했습니다. 재시작 직후 해당 Postgres 프로세스 중 2개가 다시 나타났으며 상태는 변하지 않았습니다. 현재 sidekiq에서는 아무 작업도 실행되지 않고 있습니다.
여러분, 말씀드린 것처럼 이것은 테스트 서버입니다 — 트래픽이 전혀 없습니다. 이 서버는 확실히 프로덕션 환경에 사용하기엔 부족하지만, 그게 지금의 문제는 아닙니다. 문제는 왜 postgres 프로세스가 그렇게 멈춰버리는지 (CPU 사용률 100%) 그리고 시스템 성능을 극적으로 저하시키는지에 대한 것입니다. 며칠 전까지도 우리는 더 낮은 사양으로 테스트 서버를 운영했습니다 — 디스크 용량이 부족해서 복구를 위해 사양을 올린 것뿐이었죠.
프로덕션 머신은 동일한 Shared buffer 설정으로 128GB의 RAM을 사용하면서 아무 문제 없이 작동하고 있습니다 — 따라서 이 설정과 shared buffer 크기에 일반적인 문제가 있다고 생각하지는 않습니다. 특히 트래픽이 없는 개인 테스트 머신에서는 더더욱 그렇습니다.
하지만 어쨌든 — 저는 복구를 다시 실행해서 그 행동에 대한 좋은 설명이 없어 보이는 상황에서 뭔가 잘못되었는지를 확인해 보겠습니다.
Postgres는 내부 메모리의 40%를 초과하여 shared_buffers를 설정하지 말라고