Misskeyのデフォルト (めいすきーは異なる) では、master, workerの2プロセスが上がる。 masterは最初に上がるやつで、主になにもしない。 workerはmasterからforkされるプロセスで、master以外のほぼ全ての仕事を行う。
workerの数はconfigのclusterLimitで調整できる (デフォルトは1)。
workerを増やすメリットは、Nodeは基本的に1プロセスあたり1論理CPU分しか使えない (外部プロセスとか一部のシステムコールとかファイルIOは別かも、もちろんDBも別) ので使えるようになる点。 とは言っても、たいていDBの方が負荷かかるので先にそっちを見たほうがいいかも。
workerを増やすデメリットは、総メモリ使用量は増える点。
workerを増やすデメリット (PG版Misskeyのみ) その1は、idにaidを使用している場合にプロセスを増やすと現実的な確率で衝突する点。
workerを増やすデメリット (PG版Misskeyのみ) その2は、DB接続数が増えるためDB側の接続数を考慮しないといけなくなってくる点。
workerを増やすメリット (PG版Misskeyのみ) その1は、デフォルトで10多重でしか流せない (最大接続数が10なので) DBクエリがいっぱい流せるようになる点。
ただ、問題になるのがここならconfigのdb.extra.maxあたりで増やしたほうがいいかも。
たぶんない。別に1プロセスでOK。
めいすきーではworkerのお仕事を分割出来るようにしている。
workerのお仕事はだいたい2つに分けることが出来る
- server (いわゆるフォアグラウンド処理) APIが呼び出された場合の処理、イベントが発生した場合にストリーミングに投げる処理 など
- queue (いわゆるバックグラウンド処理) リモート投稿処理、リモートへの配信処理 など
workerには上記2つの処理が混在しているので、バックグラウンド処理がフォアグラウンド処理に影響を与えてユーザー体験に悪影響を及ぼす。 workerを増やすことは出来るが、バックグラウンドがフォアグラウンドを邪魔する状況は変わらない。
そのため、めいすきーではserverとqueue専用のプロセスを作成出来るようにしている。
# 各Workerの設定
# workerWorkerCount: server+queue両方を処理するworkerの数
# serverWorkerCount: server処理のみをするworkerの数
# queueWorkerCount: queue処理のみをするworkerの数
# 稼働するのに必要な処理はserverとqueueの処理です
# デフォルト(0:0:0)では、1つのmaster processが上がりそれに全ての処理が含まれるようになります
# 0:1:1 にすると master(実処理は含まない), server(server処理を含む), queue(queueの処理を含む) の3つのプロセスが上がります
なお、デフォルトでは最小構成としてmasterを含めて1プロセスで処理するようになっている。 また、各プロセスの定期再起動を定義できるようになっている。 (queueがメモリが溜まりやすく再起動してもユーザー体験に影響が少ないので、queueだけ定期再起動するようにするなど)
存在するが最近ちゃんと動作しないENVオプション
MK_DISABLE_CLUSTERING クラスタ化をせず1プロセスで起動する
MK_ONLY_QUEUE queue処理のみ行う
MK_ONLY_SERVER server処理のみ行う
コンテナベースのクラスタ化のために、1プロセスで misskey-queue, misskey-server などを上げられるようにしたい。