調整されたすべての値をデフォルトに戻し、2.6.0 beta4 に更新しました。木曜日と金曜日にゲームが予定されているため、今週後半には十分なテストカバレッジが得られるでしょう。
残念ながら、この修正では問題が解決しませんでした。600件のメッセージがあった中程度のアクティブなゲームで、私自身のテストでもメンバーの報告でも、複数のフリーズが観測されました。これらはゲームイベント、つまり活動の急増と相関しています。
- CPU使用率は許容範囲内で、ピーク時でも約60%、平均負荷は約30%でした
- 明らかにクライアント側の問題です。チャットトピックがフリーズした場合、インデックスページに移動すると未読投稿数が表示されます。トピックに戻ると投稿が表示されるようになります
私がまだ困惑している点、つまりこのトピックでカバーされていない点は、この問題がなかったv2.3から何が変更されたのかということです。
メジャーアップデートの2.4と2.5は、私たちがCOVIDの影響で延長されたオフシーズン中に実施されたため、誰も気づきませんでしたが、フリーズはプレシーズンエキシビションゲームの最初の試合で即座に明らかになりました。
明日のために試せるパラメータのハックはありますか？熱いダービーでアウェーゲームとなるため、コミュニティが熱狂すること間違いありません。
私たちの場合、Who’s Online プラグインを無効にし、レート制限ファイルを非アクティブ化することで（最近のベータ版ではいくつかの改善があったと聞いています）、問題が解決したようです。
また、サッカーの試合があるたびに、300 人前後のユーザーが同じトピックで同時にクリックしたり書き込んだりすることもありますが、最後の試合でははるかにスムーズに動作していました。
最新のバージョン（最近の修正を含む）をお使いですか？
テスト通過に更新してください。ベータ版以降、かなり改良しました。
はい、最新ベータ版（過去 48 時間以内にリリースされたもの）です。
更新しました。レポートは後ほどお送りします。
残念ながら、まだダメですね。確かに、950 件のメッセージが飛び交い、ゲームは熱狂的な盛り上がりを見せました。GAnalytics を見ていましたが、約 250 人が視聴しており、そのうち 119 人が投稿しました。以前と同様に、いくつかのフリーズが観察されました。メッセージバスからは、429 エラーがいくつか返され、「このアクションを頻繁に実行しすぎました。X 分お待ちください」というメッセージが表示されました。
CPU の負荷は約 70% にピークしましたが、待機時間（wa）はほぼゼロでした。つまり、活動は活発だったものの、ハードウェアが本来発揮できるパフォーマンスをまだ提供できていないのです。
私を悩ませている唯一の質問にお答えいただけますでしょうか。2.3 の後に実装されたもので、これが原因となっているのは何でしょうか。そして、それは何をもたらすことを意図しているのでしょうか。
実装はこれまでとほぼ同じですが、設定可能なグローバルなアプリのレート制限が追加されました。必要であれば引き上げることができますが、そうするとシステム全体が停止する可能性もあります。確かなことはわかりません。
「フリーズ」というのは何を指しているのか理解できません。現在、負荷が高すぎると更新が停止する点は変わりませんが、以前との違いは、ページを修復するためにブラウザの再読み込みが不要になったことです。サーバーに余裕ができれば自動的に復旧します。
ここは少し不明確ですが、私の変更後、ユーザーの皆様には全く改善が見られないということでしょうか？
サーバーに空きメモリが十分にありますか？もしそうなら、Unicorn ワーカーを追加してください。
db_shared_buffers パラメータにはどのような値を設定されていますか？当初は、推奨されている全 RAM の 25% だけでは「不安定」な動作が多数発生していました（特に活発に議論されているトピックが大量のメモリを消費する現象など）。これを 32GB 中 16GB に増設したところ、その不安定さは完全に解消されました。さらに最近では、最新の変更により状況がより改善しています。
はい、この現象は本番環境（ゲームチャットなど）では監視が難しい問題です。ゲームごとに状況が異なるためです。重要なイベントの数も、対戦相手も、感情的な高揚感も、すべてが異なります。
私たちの観点から言えば、バージョン 2.3 以降、対応可能な最大容量が低下していることが核心です。すべてのサーバーには限界がありますが、現在は 2.3 を実行していた 3 月と比較して、同じサーバーから得られるパフォーマンスが低下しています。バックエンドの概算モニタリングによると、サーバーは 100% の負荷や容量に達することができません。
エンドユーザーが経験するのは、チャットの流暢さが何の説明もなしに突然停止することです。これが混乱を招きます。
テストをパスした変更により状況が改善したことはほぼ確実ですが、パフォーマンスや最大出力は依然として 2.3 と比較して大幅に低い状態です。
私たちは 6 個の高速コアと 16GB の RAM を備えた VPS を運用しています。Unicorn プロセス数は 12、RAM バッファ関連の設定はデフォルトのままです。
ここでの最善の次のステップは、システムの履歴モニタリングを設定することです。これでボトルネックの特定が可能になります。すでにCPU時間の問題ではないことが確認されているためです。ネットワーク接続の限界に達している可能性も常にあります！
さらに、node-exporter などの従来のサーバーメトリクスも活用してください。
もしその状況であれば、さらに負荷をかけたい場合は以下の対応が可能です。
-
レート制限を緩和してください。これにより、ユーザーが Discourse とより積極的にやり取りできるようになります。具体的には、
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEとDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDSの値を 2 倍に設定できます。 -
Unicorn ワーカーをさらに追加することも試してみてください。
これは過負荷状態の間に一時的に発生する予想される現象ですが、負荷が軽減されれば自動的に回復します。
私の推測では、これはすべてレート制限に関連していると思われます。レート制限は新しく導入されたもので、サーバーを保護するために存在します。どうやらあなたのサーバーは設計通りに保護されているようです。
あるゲームで以下を試しました…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…その結果、3 期目に感情が高まり始めると状況が悪化しました。サーバーの限界に達し、ユーザーは常に「ログアウト」状態に追い込まれ、ゲームチャットもフリーズしてしまいました。
4 年間にわたる大成功の物語でしたが、現在は非常に厳しい状況に立たされています。VPS の容量を次のレベルに引き上げると、月額約 160 ユーロの価格帯になってしまい、趣味のサイトにとっては大きな負担です。しかも、ユーザー数は膨大ではありません。116 人がゲーム中に 800 件以上の投稿を行いました。
「チャットは禁止」という思想も適切ではありません。もしチャットがなければ、感情的な反応の投稿がより「真剣な」トピックに散らばってしまいます。チャットは、ライブ状況の感情的な盛り上がりを一箇所に集約し、分析的なトピックをクリーンに保つための重要な手段なのです。
私のフォーラムはサッカー専門のもので、同様の課題を経験しました。
私が気づいたのは、これはスケーラビリティの問題だったということです。
私の場合、問題は異なる段階で発生しました。
Digital Ocean の場合：
- 1 CPU / 1 GB：チャットのような状況で 30〜40 ユーザー
- 2 CPU / 2 GB：チャットのような状況で 70〜80 ユーザー
- 4 CPU / 8 GB：2 時間で 120 ユーザーと 1000 件の投稿でも問題なし。限界には達しませんでした。
現在はより安価な Hetzner（ミラーサイト）で段階的にアップグレードを試みていますが、期待ほどスムーズには進んでいません。
これまでの私の経験は以下の通りです：
- 3 CPU（CPX 21 AMD チップ）/ 4 GB：20 ユーザーで苦労中
- 2 CPU（Intel）/ 8 GB：20 ユーザーでは問題なし
今週末には、試合中の条件で 80〜100 人の同時接続ユーザーでのテストを予定しています。
Digital Ocean の CPU 使用率を確認したところ、負荷が高くなっても全階層で常に 50% 未満と fairly 低く抑えられていました。
一方、Hetzner の AMD チップでは、中央値で 60% 程度の CPU 使用率でしたが、1 分おきに CPU 使用率が 300% まで短時間スパイクする現象が見られました。この現象は Intel チップでは発生しませんでした。
これが何を意味するのかはわかりません。Hetzner の方が CPU モニタリングが優れていて、短時間のスパイクを捉えている可能性を疑っています。しかし、全体的な CPU 使用率はバランスが取れているように見えます。表面的には Digital Ocean の方がスパイクへの対応が優れているように思えますが、今週末以降は Hetzner についてもさらに詳しい情報が得られるはずです。
Hetzner のテストでは、Who’s Online プラグインは何の影響も与えませんでした。
しかし、Discourse の Quick Messages プラグインはむしろ悪影響を及ぼしたようです。
次のゲームは明日の開始予定です。当社の独自のカスタマイズ（ハック）は削除し、上記の設定で試行しています。
また、非常に期待は薄いのですが、db_shared_buffers を 4GB（25%）から 6GB（37.5%）に増設しました。さらに、app.yml から db_work_mem 40MB の行のコメントアウトを解除しました（これは非常に曖昧にしかドキュメント化されていないオプションですが、管理者にとっては改善の機会として提示されています）。
もはや問題の根本解決は期待していません。最終ユーザーへの UX への悪影響を最小限に抑えるパラメータ設定による、より効果的な被害軽減策を見つけることだけを目指しています。その間、ホスティングリソースをさらに増強する可能性についても検討を進めます。
@sam さんや他の開発者への質問です。
データベースのサイズが永遠に増大することが、数時間にわたって単一のトピックにユーザーが集中するこのユースケースにどのような影響を与えるのでしょうか？
過去のゲームチャットのアクティビティを確認したところ、2017 年にはサーバーのリソースが現在のごく一部しかなかったにもかかわらず、膨大な統計データを記録したゲームが存在しました。あるゲームでは、165 人のユーザーによって 1600 件の投稿がなされましたが、パフォーマンスに関する不満は一切ありませんでした。しかし現在、はるかに高性能なサーバーであっても、その半分程度の負荷すら処理できない状況です。
80MB に増やしてみるのも一案です。もしかしたら、他の変更の代わりに試してみてください。
これは私たちが常に積極的に取り組んでいる課題の一つです。
Discourse が登場した当初は、ほぼすべてのサイトでデータベースが新規に作成されていたため、データベース全体をメモリに収めることができました。しかし、数年が経過した現在、一部のサイトではデータベースの容量が 100GB を超え、RAM の容量はその 10 分の 1 にも満たないものもあります。
今後数週間以内にリリース予定のアップデートとして、PostgreSQL 13 へのアップグレードが控えており、これにより最大のオブジェクトサイズが半分になります。
それ以外には、パフォーマンスの問題をデバッグする最初のステップとして、Discourse 用の Prometheus エクスポートプラグイン を用いてデータを収集することが挙げられます。これにより、私たちは目隠しをして進めるような状況にはなりません。