deliverJobConcurrencyの再検討 / Better job concurrency configuration?

[tamaina]

128は多すぎると思われる

p1.a9z.dev (OCI A1 x 4 OCPU)では次の設定で安定している

clusterLimit: 4

deliverJobConcurrency: 16
inboxJobConcurrency: 16
deliverJobPerSec: 2048

# Sign to ActivityPub GET request (default: true)
signToActivityPubGet: true

Related to #11000

BullMQが重い理由引用

deliverJobConcurrencyを増やすと次で説明されるような副作用が発生する

ジョブキューの時間計算量が実行中（待機中ではない）のジョブの数に比例するという性能特性があり、かつ時間計算量がタイムアウトの閾値を超えるとジョブの完了処理がコケるようになり、原理的に2度と状況が改善方向に向かうことはないという性能劣化の正帰還ができあがっていた（ので、全部一度引っこ抜いて待機列に詰め直した） https://misskey.io/notes/9o4bl4yw9bpv0djx

具体的にはこの一行の時間計算量が active リスト（実行中のジョブリスト）の要素数に比例してます。完了したジョブをリストから取り除く処理なんだけれど、増えた待機ジョブに対応してワーカーを増やしまくるなどして実行中のジョブがひとたび急増すると、ここの処理が激重になり、タイムアウトするようになり、つまりジョブは2度と完了せず、不幸が訪れる。ジョブに増加に対応しようとして逆に首が締まる最悪のループに入るわけです。 https://misskey.io/notes/9o4c09uu3gov0eia

結論としては詰め直せばええ https://misskey.io/notes/9o4bn9k6vhcm0ddf

[tamaina]

一応の説明: deliverJobConcurrency, deliverJobPerSecは（グローバルな実行数ではなく）ワーカーごとの実行数として解釈される（グローバルの設定はBullMQには存在しない）

misskey/packages/backend/src/queue/QueueProcessorService.ts

Lines 203 to 214 in 2c6f25b

	this.deliverQueueWorker = new Bull.Worker(QUEUE.DELIVER, (job) => this.deliverProcessorService.process(job), {
	...baseQueueOptions(this.config, QUEUE.DELIVER),
	autorun: false,
	concurrency: this.config.deliverJobConcurrency ?? 128,
	limiter: {
	max: this.config.deliverJobPerSec ?? 128,
	duration: 1000,
	},
	settings: {
	backoffStrategy: httpRelatedBackoff,
	},
	});

[mei23]

経験上これだわ
https://github.com/mei23/misskey/blob/36db6dcaea951c5f1f76ed7ffb00e3a998c0e01b/src/queue/index.ts#L29-L30

export const deliverJobConcurrency = config.deliverJobConcurrency || ((cpus().length || 4) * 8);
export const inboxJobConcurrency = config.inboxJobConcurrency || ((cpus().length || 4) * 1);

*JobPerSec は -1 にして制限しない