昨日、3.3.0.beta3-dev にアップグレードし、AI プラグインもインストールしました。プラグインは現在、スタッフメンバー (5人) にのみ有効になっています。
しかし、サイト全体が非常に遅くなり、極端なロードエラーが発生しています。サーバーの負荷は問題ないように見えるのですが、何が原因なのか特定できません。
原因を特定するために確認できる場所はありますか?
昨日、3.3.0.beta3-dev にアップグレードし、AI プラグインもインストールしました。プラグインは現在、スタッフメンバー (5人) にのみ有効になっています。
しかし、サイト全体が非常に遅くなり、極端なロードエラーが発生しています。サーバーの負荷は問題ないように見えるのですが、何が原因なのか特定できません。
原因を特定するために確認できる場所はありますか?
最後にアップグレードしてからしばらく経ちましたか?画像処理や再ベイクなどの処理を行っているのかもしれません。
何をしているか確認するには /sidekiq を確認してください。
すべてを再起動したら元に戻りましたが、また負荷が極端に高くなっています。問題の原因がどこにあるのか特定できません。Discourse内で役立つツールはありますか?
ユニコーンのワーカー3名が稼働中ですが、トラフィックは通常より高くなっているわけではなく、以前とほぼ同じです。変更点は3.3.0へのアップグレードと、スタッフのみが利用可能なAIプラグインの追加のみです。
問題は昨日6/3から発生しています。
クローラーが少し増えているようです。
こちらは1ヶ月以上のクローラーのデータですが、これもそれほど高くはなさそうです。サイトがほとんど使用不能な状態です。
何かお手伝いいただけると幸いです!
これは推測ですが、Sidekiqログで際立っているのは、表示されているジョブがNotifyMailingListSubscribersであるということです。このジョブは大量のリクエストを生成する可能性があります。
また、管理画面 / ログ / エラーログページにエラーは表示されていますか?
Facebookクローラーにブロックを追加しました。なぜなら、そのクローラーがやりたい放題だったからです。

しかし、slow / crawlers を追加しても robots.txt が更新されないことに気づきました。
robots.txt には、ブロックエントリしか表示されず、slow エントリは表示されません。
かなりの数のエラーが表示されています。
3つのエラーが表示されていますが、関連性はなさそうです…(判断は難しいですが)
Job exception: PG::DatetimeFieldOverflow: ERROR: timestamp out of range: \"271768-09-23 06:24:11.793040 BC\"
LINE 1: ...sers\".\"moderator\" = FALSE AND (users.created_at < '271768-09...
^
ActionDispatch::RemoteIp::IpSpoofAttackError (IP spoofing attack?! HTTP_CLIENT_IP=\"10.10.121.119\" HTTP_X_FORWARDED_FOR=\"14.140.10.244, 14.140.10.244\")
app/controllers/topics_controller.rb:1298:in `track_visit_to_topic'
app/controllers/topics_controller.rb:169:in `show'
app/controllers/application_controller.rb:422:in `block in with_resolved_locale'
app/controllers/application_controller.rb:422:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:291:in `call'
その他、SMTPに関するジョブ例外も発生しています。
Discourse は独自のレート制限を行っており、robots.txt には依存していません。
マイケルさん、ありがとうございます。
他に何か考えられることはありますか?ユニコーンをもっと回転させると役立ちますか?
それは app.yml から行いますか?
はい、おそらく役立つでしょう。
env:
UNICORN_WORKERS: 8
を app.yml に追加すると、それが実現します。
prometheus plugin を使用してパフォーマンスの数値をプルすることをお勧めします(設定されている場合)。または、performance headers を使用することもできます。
ウェブログを分析すると、サーバーがこれほどビジーな理由を特定するのに役立ちます。クローラーから始めるのが良いでしょう。
新しいDOインスタンスにアップグレードし、RAMとCPUを倍増させました。ユニコーンを8頭(3頭から増量)追加し、Dbの再インデックスとバキュームを実行しました。これでビジネスに戻れるはずです!
ご協力ありがとうございました。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.