再インストール/復元後のPostgresプロセスの無限実行とパフォーマンス低下

フォーラムを更新するために、週末に新しいVPSをインストールし、復元を行いました。

これにより、以下の複数の問題を解決できるはずでした。

  • 古いUbuntuを更新する
  • Discourseを更新する
  • Postgres 15にアップグレードする

全体的に問題なく進みましたが、その後、Postgresプロセスがコアの100%を消費するという問題が発生しました。ただし、プロセスの数は変動していました。再構築から再起動まで、いくつか試しましたが、現在は数時間経ってもフィードバックのない rake db:validate_indexes を試しています。以前にこれを実行したことがあるか、もっと早く終わるはずなのかはわかりません。

フォーラムの使用は基本的に問題ありませんが、明らかに遅くなっています。アクティブなユーザーのプロフィールを表示するような、実行に時間のかかるタスクは、通常よりも顕著に時間がかかっています。

データベースに何らかの問題があることは確実ですが、特定するのが困難です。

データベースは非常に大きいことを認めなければなりません。復元後、インデックス作成後で約150GBです。復元プロセスの監視ではエラーは見られず、インデックス作成も問題なく完了したように見えました。

これを解決する方法について、何かアイデアはありますか?現在3つのPostgresプロセスが稼働していますが、数時間前に再起動する前は6つでした。復元後、16コアすべてが使用されているのも確認しました。

編集:今気づいたのですが、3つのSidekiqプロセスが「検索用のカテゴリのインデックス作成中」でビジー状態です。これらすべてが検索インデックスの再構築である可能性はありますか?もしそうなら、他に解決策はありますか?ライブシステムの復元を行う場合、パフォーマンスが数時間または数日も低下するようでは、これは大きな問題となります。

現在、「Jobs::BackfillBadge」を実行しているSidekiqタスクは1つだけですが、7つのPostgreSQLプロセスが常にCPUを100%占有しているように見えます。何が起こっているのか本当に興味があります。

このような移行の後には、データベース統計のためにvacuumを実行するのが良いでしょう。

「いいね!」 1

RAMとCPUはいくつありますか?

Postgresにはどのくらいのメモリを割り当てますか?

テストサーバーは32GB、16コアで、設定は64MBのワークメモリになっています。

編集:共有バッファは8GBです。

現在、スタックしているように見えるバキュームを実行中です。

何かしているのか分かりませんが、すでに30分以上この状態です。

フォーラムを読み取り専用にし、VMを再起動して、以前「スタック」していた7つのPostgresプロセスを終了させました。再起動直後に、これらのPostgresプロセスのうち2つが戻ってきて、変化がありませんでした。現在、Sidekiqでは何も実行されていません。

本番サイトで VACUUM FULL を実行することは絶対に避けるべきです。パフォーマンスを回復させるために必要なのは VACUUM VERBOSE ANALYZE です。稼働中のサイトで FULL を実行することはできません。

「いいね!」 1

私は巨大なデータベースの専門家ではありませんが、バッファを2、3倍にするでしょう。

インデックスが8GBあることは確かです。

:thinking: Postgres は、内部メモリの40%を超える shared_buffers を設定しないことを推奨していますか?

とはいえ、

サーバーが過小評価されている可能性があります。

「いいね!」 2

なるほど!専門家からの賢明なアドバイスですね!では、8GB/25%では十分ではないという私の考えは正しかったのかもしれません。そして、16GBは40%以上ですが、それでも良い提案かもしれません。なぜなら…

「いいね!」 1

皆さん。言ったように、これはテストサーバーであり、トラフィックはありません。このサーバーは本番環境での使用には絶対に十分ではありませんが、問題はそこではありません。問題は、PostgreSQLプロセスがそのように(CPU使用率100%で)固着し、物事を大幅に遅くしている理由です。数日前までテストサーバーはより低い容量で実行されていました。ディスク容量不足でリストアできなかったため、アップサイズされただけです。

本番マシンは、同じ共有バッファ設定で128GBのRAMで稼働していますが、問題はありません。したがって、これらの設定や共有バッファサイズに一般的な問題があるとは思いません。特にトラフィックのないプライベートテストマシンではなおさらです。

しかし、いずれにしても、リストアをやり直して、何か間違ったことがあったかどうかを確認します。この動作には良い説明がないようです。