私にはメモリの問題には見えません。アプリケーションが使用しているのは約6GBだけです。読み取りが大量に行われています。これは、Sidekiqがビジーであることと相まって(推測ですが)、PostgreSQLが古いデータをディスクから大量に読み取っているのかもしれません。統計ジョブを実行するためかもしれません。データベースが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が各部分にどれだけの時間を費やしているかがわかります。