제 생각에는 이건 메모리 문제가 아닌 것 같습니다 - 애플리케이션이 차지하고 있는 메모리는 약 6GB 정도입니다. 읽기 작업이 많이 발생하고 있는데, 제 추측으로는 (sidekiq이 바쁜 상태인 것과 함께) postgres가 디스크에서 오래된 데이터를 많이 읽는 중일 수 있습니다. 아마도 통계 작업 등을 수행하기 위해서일 것입니다. 데이터베이스가 RAM에 완전히 담기지 않는 경우, 그 오래된 데이터에 접근할 때 상당한 양의 읽기 작업이 발생할 수 있습니다. 이 상황은 그런 문제로 보입니다.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
admin 2510013 15.8 1.6 7383364 514764 ? SNl 12:55 56:45 sidekiq 7.3.9 discourse [3 of 5 busy]
systemd+ 2848301 26.9 25.3 8058104 7806820 ? Rs 17:45 18:18 postgres: 13/main: discourse discourse [local] SELECT
systemd+ 2870880 4.3 22.9 8058516 7072000 ? Ds 18:03 2:09 postgres: 13/main: discourse discourse [local] SELECT
systemd+ 2875058 21.0 25.4 8101952 7848140 ? Rs 18:07 9:46 postgres: 13/main: discourse discourse [local] UPDATE
systemd+ 2924006 30.2 25.3 8112844 7824292 ? Rs 18:44 2:44 postgres: 13/main: discourse discourse [local] UPDATE
jystemd+ 2929546 12.8 24.9 8049520 7694404 ? Ss 18:48 0:39 postgres: 13/main: discourse discourse [local] SELECT
systemd+ 2931802 17.7 24.5 8045744 7559492 ? Ss 18:50 0:36 postgres: 13/main: parallel worker for PID 946796
systemd+ 2931803 17.7 24.5 8045744 7557568 ? Ds 18:50 0:36 postgres: 13/main: parallel worker for PID 946796
먼저 sidekiq를 살펴보는 것이 좋겠습니다 - 업데이트를 실행하느라 바쁠 가능성이 높습니다. 관리자 계정으로 로그인한 상태에서 /sidekiq URL을 확인하여 어떤 작업을 수행 중인지 살펴보세요. 아마도 긴 실행 시간의 업데이트 작업들이 표시될 것입니다.
또한 SQL 서버에서 다음을 실행할 수 있습니다:
SELECT pid, application_name, query
FROM pg_stat_activity
WHERE state IS NOT NULL
AND state != 'idle';
실행 중인 쿼리가 무엇이고 누가 그들을 호출하고 있는지 확인하기 위해서입니다. 이는 부하의 원인에 대한 힌트를 줄 것입니다.
성능 헤더를 활성화하고 있나요? 이를 활성화하고 로그에 캡처하면 Discourse가 각 부분에 얼마나 많은 시간을 보내고 있는지 알 수 있습니다.