午後9時9分ETにAWS CloudWatchアラートを受信しました。友人からも「Discourseはダウンしていますか？」というテキストメッセージが届きました。
AWS LightsailインスタンスにSSHで接続できず、すべてのメトリクスが停止/報告されていません。
最終的に諦めてLightsailインスタンスを停止/再起動しました。
サービスは復旧しました。
サービス復旧後にログを確認し、原因を特定しようとしました。
単一インスタンスでDiscourseを実行しているため、午後9時5分に発生したRedisネットワーク接続に関するエラーには困惑しています。
「何らかの理由で」「何かが」ハング/失敗したという以外に、何が起こったのかを特定できません。
説明できる方、または手がかりを残していただける方がいれば幸いです。
よろしくお願いします！
サーバーのスペックは何ですか？リソースが不足しているようですが？おそらくCPUでしょう。その時間帯に何らかの日次タスクが実行されているのでしょうか？
1 vCPU、1GB RAM、40 GB SSD の Lightsail インスタンスです。
ストレージは約 60% 消費されており、クリーンアップを行うとかなりの量が減少します。
AWS ではバースト可能 CPU クレジットが枯渇していると表示されますが、他のメトリクスがそれを裏付けていないため、これは奇妙です。
アクティブな参加者は 20〜30 人程度の小規模なコミュニティなので、CPU または RAM の制約があるとは考えにくいです。
Discourse がデフォルトでスケジュールする可能性のあるもの以外に、私が把握している定期的なタスクはありません。
1GBとスワップが、Discourseを実行するための絶対的な最小値です。
このインスタンスはどのくらい稼働していますか？データベースのサイズはどのくらいですか？
DBサイズを確認します。それほど大きくないはずです（バックアップはすべて約57MBです）。
インスタンスの稼働時間は、リカバリのために仮想サーバーの停止と再起動が必要だったため、現在10時間弱です。シェルやコンソール接続を取得できませんでした。
このインスタンスタイプでは、構築以来（推測ですが2021年2月）問題なく稼働しています。
これは、AWS が VM を別のホストに移動した際に、そのせいで奇妙な状態のままになるのと似ています。通常は再起動で解決します。
データベース全体のサイズは423MBです。
最大のテーブルは
Posts 66MB
Post_timings 60MB
2度目の同様の「高負荷」障害が発生しました。
リソース競合が原因だと推測します。
Lightsailのスナップショットを使用してインスタンスのスナップショットを作成し、より大きなインスタンスに復元してアップグレードする方法を試した人はいますか？
AWSインスタンスを再起動してみてください。多くの問題が解決する可能性があります。
Lightsail スナップショットを使用して、1 CPU、1GB RAM、40GB SSD から 2 CPU、4GB RAM、80GB SSD に移行しました。
パブリック IP のデタッチと再アタッチは問題なく完了しましたが、他に「何か見落としたことはないか」という点が懸念されます。
バックアップ、メール、S3 バケットの設定など、確認または実行すべきことはありますか？アップグレードされたリソースを活用するために、初期インストールパラメータを再実行する必要がありますか？
このリンクに基づいて、db_shared_buffer を少なくとも 1GB に引き上げることができると考えています。
現在の app.yml では 128MB となっており、ブートストラップ時に自動調整することも示されています。
1GBは4GBシステムで問題ありません。unicorn_workersも4に更新してください。
サーバー間を移動する場合の通常の推奨事項は、discourse-setupを再実行することです。これにより、上記が自動的に処理されます。
ありがとうございます。今からPrometheusの奥深くを掘り下げていきます。
良い内容です。
