misskey-dev
BullMQにしてからCPU使用率が高くなる、Deliver等のキューのWaitingが増えた
Summary
~~bullmqになってからjobConcurrencyの挙動が変わったらしく、deliverJobConcurrencyは128がデフォルトだとサーバーがハングしてしまうかもしれない~~
~~deliverJobConcurrencyを8とか16あたりにするべき~~
単純にキューの実行をする際にCPUリソースを食いまくるらしい
単純に、ジョブ終了から次のジョブを呼び出すまでの時間が短縮されてジョブの実行数が増えたんだと思ってた
（キューメトリクスウィジェットでジョブが実行できた数は増えているように見える）
queueのratelimitの仕様も変わってこっちは結構上方修正してあげないと処理が止まっちゃうかも
（deliverJobPerSec と inboxJobPerSec などの設定、このlimitの適用範囲が完全にグローバルになってるので）
deliverJobConcurrency減らすと捌ききれなくてどんどん溜まっていく 逆に増やすとCPU使用率がめっちゃ上がってサーバー台数がとんでも無いことになる （通常5/24、現在24/24）
https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/daemons/QueueStatsService.ts が重い可能性ないかな
Workerのパフォーマンスプロファイリング@13.13.2（一つだけの連合先にdeliverするテスト）
この条件ではあまりオーバーヘッドがあるようには見えない
謎
同時性の問題なのでジョブが一つの場合は起きないかも ratelimitを10とかにして、ジョブを200個くらい用意した状態でconcurrency 5のワーカーを3台位起動させるとたぶんおそらく何が起きてるかは見えるかも…？（未検証）
配送元と配送先が同一物理サーバーに乗っている場合での実験ですが
ratelimitを10とかにして、ジョブを200個くらい用意した状態でconcurrency 5のワーカーを3台位起動させるとたぶんおそらく何が起きてるかは見えるかも…？
単純にジョブがゆっくり実行されるという想定された動作になるだけで特にオーバーヘッドが増えたりしている様子はなかった
queueのratelimitの仕様も変わってこっちは結構上方修正してあげないと処理が止まっちゃうかも （deliverJobPerSec と inboxJobPerSec などの設定、このlimitの適用範囲が完全にグローバルになってるので）
その通りで、deliverJobPerSecとinboxJobPerSecをclusterLimit倍すればよさそう
deliverJobConcurrencyはHTTPリクエストの待ち時間やDBの待ち時間に（シングルスレッドのワーカーが）ジョブを最大どれだけ並行して回すかという数なので、極端に減らさなければ特に関係なさそう。(https://docs.bullmq.io/guide/workers/concurrency)
deliverJobPerSecを上げれば500 deliver/コアくらいは捌ける模様（Workerの台数を増やして分散させても、一台あたりの効率はそれほど落ちない）
Concurrencyの上げ過ぎ→ジョブごとの毎秒のCPU時間が減る→stalledタイマーの更新が間に合わなくなる→ジョブがstalled状態に→ほかのワーカーにより強制的にwaitingリストに入れられる→リスタート の流れが起きてるのではないかとの予想ですが、小規模では再現性がよくないので何とも言えませんね…
https://docs.bullmq.io/guide/workers/concurrency
https://docs.bullmq.io/guide/workers/sandboxed-processors
こんなことが書いてあったけど…
動画エンコードとかそういう重い処理は同じプロセスでやると他の全てが止まるからそういう場合はプロセス分離してやってね(=sandbox processor)ってことだと思うからMisskeyおよびこのIssueとは関係なさそう