19:03:46 @u1_liquid@misskey.io
icon

Evil Neuro-samaめちゃくちゃかわいいな・・・

16:30:47 @u1_liquid@misskey.io
2024-04-11 16:14:50 Ixy(いくしー)の投稿 ixy@misskey.io
icon

このアカウントは、notestockで公開設定になっていません。

14:35:59 @u1_liquid@misskey.io
2024-04-11 14:35:02 しゅうまい君(バカンス)の投稿 shuumai@misskey.io
icon

これはどれ演ってる { ");`array(0) " string(0)で先週ふと深夜に来てとおもう

02:15:09 @u1_liquid@misskey.io
icon

@kyrie@misskey.flowertea.uk inboxJobPerSecが単純に足りていないと思います

以下は昔別の方の質問で書いたものです

基本的にQueue関連の設定はこんな感じにするといいと思います
* xxxJobConcurrencyは少なめに
  - この値を増やすと上記の記事と同じ問題が頻繁するようになります。
  - 常に設定している数字分のジョブを抱え持つことになるため、内部処理が長引くとfetchしていたジョブのlockが外され、持っていたジョブを全てQueueに戻すという激重動作が走ってしまいます。
  - 推奨の設定値は`64`を超えないようにすること(小規模サーバーなら`8~16`, 大規模でも`64`)
* xxxJobPerSecはなるべく引っかからないように
  - BullMQのレートリミットの実装は、一度レートリミットになると解除されるまでSleepを挟むことになっています。
  - JobConcurrencyの仕様と悪い方向のシナジー効果が起き、現在持っている全てのジョブをQueueに戻す動作が起きる可能性があります。
  - 推奨の設定値はDBの処理能力に余裕がある場合は`3145728000`などにして無効化、DBの書き込み性能に問題がある場合Redisの負荷と調整しながらチューニングする必要があります