皆様、こんにちは。
CentOS 7 サーバーを 2.2.2 から 2.7.0.beta4 にアップグレードしたところ、以降ページの読み込みに遅延が発生しています。特にデータベースや画像コンテンツが含まれるページで顕著で、利用できない状態にまで至っています。
この件に関するご助言をいただけますと幸いです。
過去数年間にいくつかの出来事がありました。すべての画像を処理する必要があるバグ修正が行われました。あなたのサーバーはその処理で過負荷になっていると推測されます。キューを確認するには /sidekiq をご覧ください。
データベースの規模はどのくらいですか？画像は何枚ありますか？Sidekiq は何を表示していますか？SSD を使用していますよね？
「いいね！」 6
VMベースのサーバーですので、SSDかどうかはわかりません。
Sidekiqへのアクセスも確認できません。このデプロイは私が行ったものではないため、アクセス方法が不明です。
インストール方法をご存知ですか？標準的なインストールではないようです（そうでなければ、管理者であれば /sidekiq にアクセスできたはずです）。
「いいね！」 2
進行状況の低下の原因を調査することが、最善の次のステップです。長年かけて追加された多くのバックグラウンドジョブ（画像の最適化、リベイクなど）が現在実行中で、サーバーリソースを消費している可能性があります。これらのジョブが完了すれば、パフォーマンスは改善するはずです。
どのジョブが実行中かを確認するために、/sidekiq（管理者アカウントで！）にアクセスするのが最初の良いステップです。
「いいね！」 2
サーバーで観察される挙動として、投稿を開いてリスト表示を試みても空のキューが表示され続けます。また、投稿が読み込まれている間、Sidekiq ポータルもフリーズし、投稿が完全に読み込まれるまで更新されません。
さらに、読み込まれた直後にも空のキューが表示されてしまいます。ご助言やサポートをいただけますと幸いです。
キューが空であれば、多数のバックグラウンドジョブが実行されているという問題はありません。したがって、別の要因が原因です。
プラグインは導入されていますか？API 呼び出しを大量に行うテーマコンポーネントはありますか？
上記で他の質問もしています。
データベースのサイズはどれくらいですか？
画像は何枚ありますか？
多くの API 呼び出しを行っているテーマコンポーネントはありますか？
Docker ベースのセットアップから上記の情報をどうやって確認すればよいか教えていただけますか？最後のバックアップは 135 MB です。
プラグインについては、はい、以下のプラグインがリストされています：
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
Mermaid プラグインの削除をお勧めします。
投稿数とユーザー数はどれくらいですか？トラフィックは？
RAM はどのくらいありますか？
2GB の Digital Ocean ドロップレットで問題ないと思われます。一度作成して動作を確認してみてください。
サーバーに他の問題がある可能性はありませんか？最新の状態になっていますか？最近再起動しましたか？
わかりました、それを削除します。
現在、投稿数は約4,000件、ユーザー数は約350人です。
同時ログインユーザー数はそれほど多くなく、平均で最大でも5〜10人程度です。
このサーバーは最近起動され、共有環境で8GBのRAMと10GBのスワップ領域を有しています。現時点での稼働時間は13日ですが、パフォーマンスの問題は再起動や稼働時間とは無関係に発生しています。
「いいね！」 3
インストールに明らかな問題があります。このハードウェアであれば、はるかに良いパフォーマンスが得られるはずです。
Postgres で明示的な VACUUM を実行してみてください。All-in-One コンテナインストールを使用している場合は、以下を実行します。
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Type "help" for help.
discourse=# VACUUM ANALYZE;
VACUUM
app.yml で unicorn ワーカーをいくつ設定していますか？
env セクションに以下を追加することで、Discourse にレスポンスに追加のパフォーマンスヘッダーを設定させることができます。
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
ついでに、以下の投稿に従って miniprofiler を有効にすることもできます。この投稿。
「いいね！」 5
それであれば、かなり十分でしょう。
Discourse のメモリ使用量を調整するために discourse-setup を再実行するよう提案されたかどうか、あるいはサーバー上の他のプロセスを考慮した際にそのデフォルト値が妥当かどうかは覚えていません。
PG13 アップグレード後にデータベースの再インデックスを実行していない場合は、PostgreSQL 13 アップデートを参照して、それに関する情報を確認してみてください。
「いいね！」 2
はい、テーブル統計情報の欠如（VACUUM ANALYZEの実行不足）が、ここで最も疑わしい原因です。
「いいね！」 2
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
これらのコマンドを実行し、環境変数にもヘッダーを設定しましたが、ページの読み込み時間にほとんど変化が見られません。
8 個の Unicorn を実行しています。
そのコマンドは PostgreSQL で実行しましたか？
「いいね！」 1
はい、上記のコマンドを実行する前に、docker exec -it -u postgres app psql discourse を実行しました。
「いいね！」 1
ええと、それは非常に奇妙ですね。他の誰もそのような問題を抱えていません。あなたのハードウェアは十分に見えるのですが。私の唯一の推測は、リバースプロキシに関連する問題（そのマシンには他にも何かしら入っているのでしょう？）です。
はい、もう一つ Docker ベースのサービスです。
ただし、パフォーマンスに大きな負荷がかかるようなものではなく、そうでなければマシンのパフォーマンス指標に現れていたはずです。
「いいね！」 2