アップロードファイルはすべてNASストレージ(glusterfs)でホストしています。
最近、NASで大量の定常的なネットワークトラフィックが発生していることに気づき、原因を調査したところ、Discourseが最適化された画像を要求していることがわかりました。これらの画像を常に検索するジョブはありますか?それはなぜですか?そして、どうすれば無効にできますか?
アップロードファイルはすべてNASストレージ(glusterfs)でホストしています。
最近、NASで大量の定常的なネットワークトラフィックが発生していることに気づき、原因を調査したところ、Discourseが最適化された画像を要求していることがわかりました。これらの画像を常に検索するジョブはありますか?それはなぜですか?そして、どうすれば無効にできますか?
btw アップロードサイトの設定のクリーンアップは、私のフォーラムでは無効になっています。
David が追加したプライマリ画像の色の検索のためのバックフィルかもしれません。
最終的には完了し、安定した状態に戻ります。
バックフィルのためにすべての画像を処理する必要があります。すべての画像のデフォルトの色を白などに強制することで回避できるかもしれません。
私の見る限り、
これは15分あたり25枚の画像で動作しています。そうですよね?これは非常に無視できるはずです。私は毎分数千ものファイルが検索されているのを見ています。
また、6か月前の帯域幅を見ると、同じような動作が見られます。したがって、それは他の何かだと思います。
しかし、ディスコースのジョブかそれに類するものによって実行されていることはほぼ確実です。なぜなら、ディスコースアプリを停止すると、帯域幅は消えるからです。しかし、ディスコースのnginxアプリを停止しただけでは、帯域幅は残ります。
/sidekiqで実行中のジョブを確認してください。すべてのタブをクリックしてください。
ジョブは実行されていません。
。ここにリストされていない他のジョブはありますか?
それとも、コンテナ内にファイルをインデックス化しようとしているものがあるのでしょうか?
バックグラウンドロジックはすべてSidekiqジョブで実行されます。ジョブが実行されておらず、ディスクI/Oが高い場合は、ユーザーがウェブサイトを訪問していて、nginxが画像を配信している可能性がありますか?
静的アセットの前面にキャッシュCDNがありますか?
以前にテストしました。
![]()
したがって、ウェブサイトへのアクセスが原因ではありません。もしそうであれば、nginxを停止したときにトラフィックはなくなるはずです。
Linux の検査ツールを使用して、具体的にどの PID と syscall が実行されているかを確認する必要があります。
まず、ディスコースアプリを再起動して、継続的なトラフィックをなくしました。次に、管理パネルに移動し、一括レポートのセクションに移動しました。レポートがここで正しく表示されないのは長い間続いています。
レポートがタイムアウトした直後に、ネットワーク帯域幅の増加が見られます。そして、エラーログに次のエラーが表示されます。
'hijack admin/reports bulk ' is still running after 90 seconds on db default, this process may need to be restarted!
何が間違っているのでしょうか?
データベースは同じNASストレージにありますか?
いいえ、データベースは物理SSDディスク上にあります。
アップロードフォルダのみがNAS上にあります。
それらの間に関連性はないということですね。戻って
実際には、関連性があるのではないかと思います。私のテスト環境では、使用済みスペースを計算しています。
多数のファイルがあるNASフォルダの使用済みスペースの計算は、非常に時間がかかり、高帯域幅の根本原因になると考えています。
合っていますか? ![]()
ネットワーク共有で
df -Pk
df -P
du -s
を実行すると、かなりの時間がかかりますか?
なるほど。そのレポート結果はキャッシュされていますが、完了せず、ネットワーク共有が遅すぎるためにキャッシュできないのだと思います。
これを防ぐために何かできることはありますか?たとえば、ディスクサイズを計算しないS3アップロードのように扱いますか?