'bundle exec rake db:migrate'가 캘린더 마이그레이션으로 인해 오래 걸림

지원 자체 호스팅
16 
ystemd+  7660  0.0  0.3 352060 28284 ?        S    22:31   0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
systemd+  7667  0.0  0.1 352588  9628 ?        Ss   22:31   0:00 postgres: 13/main: checkpointer 
systemd+  7668  0.3  0.9 352060 78796 ?        Ss   22:31   0:03 postgres: 13/main: background writer 
systemd+  7669  0.0  0.1 352060 13696 ?        Ss   22:31   0:00 postgres: 13/main: walwriter 
systemd+  7670  0.0  0.1 352728 11892 ?        Ss   22:31   0:00 postgres: 13/main: autovacuum launcher 
systemd+  7671  0.0  0.0  67996  5320 ?        Ss   22:31   0:00 postgres: 13/main: stats collector 
systemd+  7672  0.0  0.0 352612  6640 ?        Ss   22:31   0:00 postgres: 13/main: logical replication launcher 
systemd+ 10900 82.0  3.8 487164 317728 ?       Rs   22:33  10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901  0.0  0.1 353432 13804 ?        Ss   22:33   0:00 postgres: 13/main: discourse discourse [local] idle

htop에서 discourse [local] delete가 CPU 100%를 차지하고 있는 것으로 보입니다. 드롭렛에는 8GB의 RAM이 있으며, 현재 사용 중인 RAM은 1GB 미만입니다(버퍼 제외).

OS가 최신 버전이 아니지만, 제 생각에는 매우 이상한 상황입니다. RAM과 디스크 공간이 충분하고, 해당 postgres delete 작업이 12분 이상 실행되고 있기 때문입니다. 게시글은 60만 개 미만, 사용자는 4천 명 미만이라 데이터베이스가 크지 않습니다. 아, 잠깐. postgres_data 디렉토리가 28GB나 됩니다.

VACUUM VERBOSE ANALYZE;를 실행했습니다.

다음과 같이 실행했습니다:

discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; 
 checkpoints_timed | checkpoints_req 
-------------------+-----------------
                 6 |              20

현재 동시 재인덱싱(reindex concurrently)을 시도하고 있습니다. vacuum과 재인덱싱이 도움이 될지 지켜보겠습니다.