それは良い仕様ですね！特に忙しいサイトをお持ちなのでしょうか？
リベイクが発生していなかったか確認しましたか？
1分あたり何枚の写真が投稿されていますか？
サムネイルの準備は主にコアコードであり、追加の画像処理が必須となります。
これは、この種のプラグインまたはテーマコンポーネントに当てはまることです。
「いいね！」 3
プラグインを約24時間オフにし、その後24時間オンにしました。
以下に、他の管理者からのメモを貼り付けます。
プラグインが原因で、スケジュールされたジョブの実行が遅くなっています。
キュー内のジョブが増えるほど、CPUは追いつくのに苦労します。
そのため、サーバーは多くのトラフィックを処理しますが、ジョブがバックログになるまでしばらくは正常に見えます。
最終的にCPUは追いつくのに苦労し、バックログジョブを完了するにつれて使用率が上下します。
だからこそ、以前は3000以上のバックログジョブが見られたのです。
通常の状況では5つ以上のジョブはありません。しかし、ジョブはすぐに処理されるべきなので、バックログになるべきではありません。
添付の画像は、現在のジョブがバックログになっている様子を示しています。現在、30〜35個のバックログジョブの間で推移しています。
すべてのジョブは、サイドカーの最後の投稿からの新しいものです。
まだ理由はわかりませんが、プラグインがオンの場合にのみ発生します。
CPUのリソースの最後の1時間の状況
過去24時間。プラグインが有効になったおおよその箇所を示しています（スパイク後の上昇トレンドを参照）。
パターンは24時間よりも長いように見えますが、プラグインはほとんどの場合、80〜90％以上の一般的なリソース使用率を引き起こします。
オフにすると、今後24時間でサーバーの平均使用率が60〜75％になり、ジョブがバックログにならないことに気づき始めるでしょう。
また、必要に応じて、app.ymlを16個のユニコーンワーカーを持つように変更しました。再構築したい場合は、プラグインを無効にして、16個のユニコーンワーカーを持つべきだと思います。その期間のサーバーのパフォーマンスを監視し、ワーカー値を最適なものに調整します。
過去7日間
赤 = 有効
青 = 無効
プラグインを再度オンにした後、CPUがスパイクしています。ジョブの部分が大きな問題であるという確信は薄れています。ユニコーンワーカーが増えるとジョブ数が上がることに気づきました。数は無関係だと思います。
まだ問題の全容は把握できていませんが、プラグインが問題であると強く確信しています。
プラグイン+16ワーカー：サーバーが固定される
プラグインなし+16ワーカー - 正常に動作
プラグイン+8ワーカー - 低速だが動作する
プラグインをオフにした後のグラフ
「いいね！」 1
こんにちは。
私が以前メモを作成したもう一人の管理者です。
ジョブはもう問題の一部ではないようです。
残念ながら、原因が何であるかを知るほど、ディスコースの内部構造については詳しくありません。現在見えていることしかわかりません。
要約すると、サイトは一般的に8つのワーカーで有効にすると遅く、16のワーカーではほぼダウンします。
プラグインをオフにすると、サイトは完全に正常に動作し、十分なワーカーがあれば非常に高速になります。
これにより、プラグインがリソース、またはIOや非同期操作で何かを保持していることによってサイトを遅くしている可能性があると考えられます。
「いいね！」 1
sidekiq キューを確認していただけますか？ジョブが多数キューに入っていて、ジョブ名は何でしょうか？
これはサムネイル生成のバックログにすぎず、すべての画像が処理されれば落ち着くはずです。
これはコアプロセスです。
sidecar プラグインを追加機能が不要であれば安全に削除し、Theme Component のみを使用できます。
Theme Component が有効で sidecar プラグインが無効な状態でも問題が継続するか確認していただけますか？
sidecar プラグインを一度もインストールしたことがない場合、問題はコアにあるはずです。
分析のヘルプが必要な場合は、Pavilion を雇うことができます。
この問題に関する独立したレポートを歓迎します。
「いいね！」 4
確認ですが、トピックリストのサムネイル表示テーマコンポーネントを有効にすると、高CPU使用率の画像リサイズジョブが増加することが予想されます 
。コアは、トピックリストで特定のトピックを最初に表示するユーザーのために、サムネイルを「オンデマンド」で生成します。
@merefield が言及したように、頻繁にリストされるトピックのサムネイルがすべて生成されれば、落ち着くはずです。
ワーカーの数を増やすのはおそらく良い考えではありません。CPUが制約されているマシンでより多くの作業を並列に実行しようとすると、症状が悪化します。ワーカーの数を通常どおりにして、マシンに過負荷をかけずにジョブをキューに入れて処理できるようにするのが良いでしょう。
Sidekiq UIでは、「Busy」タブと「Queued」タブを確認するのがおそらく良いでしょう。「Scheduled」ジョブは、将来の特定の時間にスケジュールされたジョブであり、パフォーマンスの問題を引き起こす可能性は非常に低いです。
「いいね！」 4
「いいね！」 1
多くの「トータルコンバージョン」テーマはサポートされていません。FKB Proには、このコンポーネントと競合する独自のオーバーライドがあると思われます。このシナリオはサポートできないと思われます。
このテーマコンポーネントは、すべての要素を網羅しようとしないテーマのビルディングブロックとして使用することを目的としています。
トピックリストプレビュー付きの右サイドバーが必要な場合は、Right Side Blocks を組み合わせて試してみてください。
「いいね！」 3
実験的な機能を追加しました。
「いいね！」 1
これは現在かなりうまく機能していますが、まだ設定が必要です。
これは幅に応じて応答するため、リスト領域が十分に広い場合にのみタイル（メーソンリー）モードで表示されます。
デモはこちら：https://www.starzen.space/
注：右下にある余分なパディングは、パフォーマンス上の理由（高速！）から、要素を最も近いグリッド行にレンダリングするメーソンリーレンダラーによる既知の必要な問題です。CSSグリッドでネイティブメーソンリーが実装されたら（！）これをリファクタリングして見栄えを良くします。
注＃2：スクリーンショットには、Discourse Barsテーマコンポーネントのいくつかのコントロールも含まれています（サイドバーは非表示になっています）。トピックリストプレビューは、Discourse Barsと非常によく連携します。
「いいね！」 1
YouTubeの画像がホームページに表示されます。
Twitter用にもできますか？
「いいね！」 2
それは決してYouTubeに限定されるものではありません。
サムネイルが何であれ、それを表示します。Twitterの埋め込みがサムネイルを作成した場合、はい、そうです。
「いいね！」 3
この設定からルートを削除してください。
そうしないと、「タイル」として表示されます。ルートをゼロにしたい場合は、これらの行をすべて削除してください。ただし、モバイルではタイル表示を検討するかもしれません（その場合は、*-mobile を持つものを保持してください）。
「いいね！」 2
これで完璧です。ありがとうございます 
「いいね！」 2
「いいね！」 1
サイドカープラグインをインストールし、その設定を使用してください。
「いいね！」 2
トピックの要約をやり直すために、投稿の再ベイクを実行する必要があるのではないでしょうか。
「いいね！」 1