BullMQにしてからCPU使用率が高くなる、Deliver等のキューのWaitingが増えた

[tamaina]

Summary

bullmqになってからjobConcurrencyの挙動が変わったらしく、deliverJobConcurrencyは128がデフォルトだとサーバーがハングしてしまうかもしれない

deliverJobConcurrencyを8とか16あたりにするべき

単純にキューの実行をする際にCPUリソースを食いまくるらしい

[syuilo]

謎

[tamaina]

（bullの実装が微妙だったのが治ったとかだと思ってた

[syuilo]

明らかになんかおかしそう

[tamaina]

個人的な感覚ではdeliverJobConcurrencyが128だったのがおかしいと思ってる

[syuilo]

同じジョブでもBullMQにしてから負荷が高くなっていそうな雰囲気がある

[tamaina]

単純に、ジョブ終了から次のジョブを呼び出すまでの時間が短縮されてジョブの実行数が増えたんだと思ってた

（キューメトリクスウィジェットでジョブが実行できた数は増えているように見える）

[tamaina]

misskey.io死んだ？

[u1-liquid]

queueのratelimitの仕様も変わってこっちは結構上方修正してあげないと処理が止まっちゃうかも
（deliverJobPerSec と inboxJobPerSec などの設定、このlimitの適用範囲が完全にグローバルになってるので）

[SanMurakami]

サーバー台数5倍ぐらいに増やしてやっとギリギリ捌けるって感じ
正直このままだと破産するのでなんとかして欲しい

[tamaina]

deliverJobConcurrencyを減らしてdeliverJobPerSecを増やすとかしてもダメな感じ？

[SanMurakami]

deliverJobConcurrency減らすと捌ききれなくてどんどん溜まっていく
逆に増やすとCPU使用率がめっちゃ上がってサーバー台数がとんでも無いことになる
（通常5/24、現在24/24）

[tamaina]

（私はbullに戻す以外の選択肢を考えられない

[syuilo]

BullMQのバグ？

[tamaina]

bullmqにした以外にキュー実行周りに手を加えていないならbullmqのせいなのでは

[syuilo]

何か使い方間違ってるとかかも

[tamaina]

まあまずは使い方から疑うべき

[syuilo]

https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/daemons/QueueStatsService.ts
が重い可能性ないかな

[tamaina]

そんなに重たい処理には見えないというか、キュー実行に直接関係あるかしら（tickごとにCPU使用率が増えているわけではなさそうだし）

[tamaina]

まさかこれが重たいとか？

[u1-liquid]

これ結局nodeのシングルプロセス性能の問題と直結してるのでOut-Of-ProcessのWorkerにしたいかも

[tamaina]

bullの方がなんとかなってるのはどうしてなんだろう

[yuriha-chan]

Workerのパフォーマンスプロファイリング@13.13.2（一つだけの連合先にdeliverするテスト）

この条件ではあまりオーバーヘッドがあるようには見えない
謎

[tamaina]

https://docs.bullmq.io/guide/workers/concurrency

https://docs.bullmq.io/guide/workers/sandboxed-processors

こんなことが書いてあったけど…

[syuilo]

アクティビティの受信や配送自体はCPU intensiveではなさそう

[tamaina]

しかし現にCPUがめっちゃ使われている

[syuilo]

動画エンコードとかそういう重い処理は同じプロセスでやると他の全てが止まるからそういう場合はプロセス分離してやってね(=sandbox processor)ってことだと思うからMisskeyおよびこのIssueとは関係なさそう

[syuilo]

しかし現にCPUがめっちゃ使われている

sanbox化したところで軽くなるわけではないからなあ

[syuilo]

むしろ大量にプロセス生成されてより重くなりそう

[tamaina]

なんか無駄に抵抗してるけどとりあえず改造してみようと思ったが、Nestから剥がすのが面倒だったので断念した

（そして他のモジュールを芋蔓式に引っ張ってくる必要があるため分離したプロセスはとてもデカくなりそう）

[tamaina]

確かに動画エンコードとかそういうワークでしか使えない

[u1-liquid]

https://docs.bullmq.io/guide/nestjs
これもダメそう？

[tamaina]

https://docs.nestjs.com/techniques/queues

解説としてはこっちの方がわかりやすそう

[yuriha-chan]

署名処理がCPU intensiveっぽいけど、すでにClusterで並行処理化できているからそれ以上の対策をする意味はなさそう（Workerの代わりにネイティブスレッドを使うようにすればメモリ使用量は削減できる可能性があるが、CPUの負荷軽減は微妙）

[syuilo]

解決した方に報奨金を進呈

[yuriha-chan]

BullMQがどう影響しているかはよく分からないが、プロファイラ上では署名処理が重い。
Misskeyの鍵長がRSA4096bitと、MastodonのRSA2048bitとくらべセキュリティの高い設定になっているため、この影響でCPUをバカ食いしていると思われる。
RSA2048bitで妥協するか、ECDSAやEdDSAなどの効率の良い署名アルゴリズムを使うことで、パフォーマンスを改善できる可能性がある。ECDSAやEdDSAを使うことにする場合、ユーザーの鍵を複数保存しておいて、連合先サーバーとのネゴシエーションで渡す公開鍵を決める必要がありそうである。

参考までに各アルゴリズムのOpenSSLによる速度測定例を置いておきます。
(AMD EPYC 7B12: 1CPU当たりの性能)

• RSA 2048bit
  • 署名:1517.4/s
  • 検証:52966.6/s
• RSA 4096bit:
  • 署名: 220.6/s
  • 検証:14481.2/s
• ECDSA 256bit (nistp256):
  • 署名: 45247.8/s
  • 検証:14689.2/s
• EdDSA 253bit:
  • 署名: 23028.8/s
  • 検証:8359.5/s

[yuriha-chan]

Deliverが大量に発生するとここ

misskey/packages/backend/src/core/FetchInstanceMetadataService.ts

Line 53 in 92d9946

const unlock = await this.appLockService.getFetchInstanceMetadataLock(instance.host);

のロックが非常に混雑して、ロックを管理しているRedisとの通信処理でNodeのCPUを大量に消費するらしい。

getFetchInstanceMetadataはcron的に実行する方がよさそう

[tamaina]

getFetchInstanceMetadataLockとは関係ないけど、Redisとの通信と聞くとthis.deliverQueue.addBulkで一斉にDeliver Queueを突っ込めないかなと思った

[yuriha-chan]

ジョブキューの独自改造はわりとありだと思う
やらなければいけないというほどでもないとは思うが。

[yuriha-chan]

鍵の変更は別Issueにしますね。

[mendakon]

再起動時と比べinboxのProcessどんどん少なくなっていく気がするのだがうちだけか

[tamaina]

Active (concurrency)を増やすと逆にダメらしい

MisskeyIO#313 (comment)

[tamaina]

bullmqになってからjobConcurrencyの挙動が変わったらしく、deliverJobConcurrencyは128がデフォルトだとサーバーがハングしてしまうかもしれない

deliverJobConcurrencyを8とか16あたりにするべき

最初に書いた↑の挙動はBullMQの時間計算量増加が原因かしらね