CPU 사용량이 비정상적으로 높음

[supermathie (Michael Brown)]

@char

메모리가 부족해서 쿼리가 스왑으로 넘어가는 것 같다고 추정해 봅니다.

(스왑이 아니라 디스크에서 읽는 것입니다)

이것은 저의 이전 관찰과 일치합니다:

@supermathie

애플리케이션이 차지하는 공간은 약 6GB뿐입니다. 상당한 양의 읽기 작업이 일어나고 있는데, 추측컨대 (sidekiq이 바쁜 것과 함께) postgres가 디스크에서 오래된 데이터를 많이 읽고 있을 수 있으며, 이는 통계 작업을 수행하기 위한 것일 수 있습니다. 데이터베이스가 RAM에 맞지 않으면, 해당 오래된 데이터에 액세스할 때 상당한 양의 읽기 작업이 발생할 수 있습니다.

@char

pg_total_relation_size

이것은 관계(relation) 및 인덱스의 크기입니다. pg_relation_size와 비교해 보세요.

@char

  2501 | 2026-02-07 11:25:01.028892+00 | active | IO              | DataFileRead | UPDATE posts                                                                                        +
       |                               |        |                 |              | SET percent_rank = X.percent_rank                                                                   +
       |                               |        |                 |              | FROM (                                                                                              +
       |                               |        |                 |              |   SELECT posts.id, Y.percent_rank                                                                   +
       |                               |        |                 |              |   FROM posts

이것은 PeriodicalUpdates의 일부인 ScoreCalculator에서 나온 것입니다.

@char

많은 통계 재계산 작업이 리소스를 과하게 점유하고 있습니다 (예: Jobs::DestroyOldDeletionStubs - 419초; Jobs::AboutStats - 472초; Jobs::EnsureDbConsistency 2083초; Jobs::TopRefreshOlder - 2727초)

해결해야 할 이 발견 사항입니다. 비교하자면, 여기 메타(meta)에서는 Jobs::EnsureDbConsistency가 2분 미만, Jobs::TopRefreshOlder가 10초 미만입니다:

Postgres에는 더 많은 메모리가 필요합니다. 가능한 한 많이 할당해 주세요.

VACUUM ANALYZE 또는 VACUUM ANALYZE FULL 실행에서도 이점을 볼 수 있습니다. 전자는 실행해도 해가 되지 않습니다.

아래 순서대로 진행하는 것이 좋습니다:

• vacuum analyze
• sidekiq를 일시 정지한 후 vacuum analyze full 실행 (이 작업은 테이블을 완전히 다시 작성하기 위해 테이블을 잠금(lock)하므로, 실행 중 일부 실패가 발생할 수 있음)
• postgres에 더 많은 메모리 할당