異常に高いCPU使用率

[supermathie (Michael Brown)]

@char

メモリ不足が原因だと推測します。クエリがスワップ領域に送られています。

（スワップではなく、ディスクから読み取っている）

これは私の以前の観測と一致します：

@supermathie

アプリケーションによって使用されているのは約6GBだけで、多くの読み取りが発生しています。これは、Sidekiqがビジーであることと相まって、Postgresが古いデータをディスクから大量に読み取っている可能性があり、何らかの統計ジョブを実行しているのかもしれません。データベースがRAMに収まらない場合、その古いデータにアクセスするときに多くの読み取りが発生する可能性があります。

@char

pg_total_relation_size

これはリレーションとインデックスのサイズであることに注意してください。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（これによりテーブルがフリーズされ、完全に書き直されます。実行中はいくつかの失敗が発生する可能性があります）
• postgresにより多くのメモリを割り当てる