@kamisuke おはよう、王
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
@sakasame ジョブのグループとしてキューがあって、一つのsidekiqプロセスで、受け持つキューと走らせるスレッド数を指定できるのね。標準では全部のキューを受け持つ25スレッドのsidekiqプロセスを一個だけ立ち上げる。
これを、ローカルのユーザーにとって重要な処理をするdefaultと、外部への配送を受け持つpushや、外部から取得する処理と優先度の低い処理を行うpull
のキューを処理するsidekiqプロセスに分けたりする。defaultを手厚く、ほかはそこそこにすると良いのです。メール送信のmailersキューは、まぁどこかにくっつけとけばOK。
プロセスを分けると、それぞれがCPUを使ってくれるので、マルチコアプロセッサの恩恵が受けやすくなるというのがあります。
また、複数のマシンで実行することで、より沢山のパワーを投入できます。
redisとPostgreSQLがネックになるので無限に強化できるわけじゃないんだけど、そのあたりのバランスをとりながら構成を考えるのが楽しいのです。
@sakasame mstdn.jpでは、defaultキューがつまっていることが多く、pushキューに余裕があることが多くって、サーバ内で各種タイムラインが遅延しているのに、Fedibirdから見るとリアルタイムで届いているっていうようなことが起きています。
best-friends.chatはdefault重視(ローカルの体験がもっとも重要)で、pushとpullがおかしくてもしばらく気が付かないことがあったりします(最近はたぶん安定してる)。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@sakasame hostdonなどのホスティングの場合は、こちらでそこをいじることはできません。逆に言うと、そこの差がスペックに直結してくるので、コース(料金設定)の差に現れてきます。
Hostdonの場合、ライト、スタンダード、プレミアムが、25、50、100スレッドの設定になっています。内訳はSidekiqの実行中タブをみてください。
Masto.hostはもっと細かく、同時処理数のようなカタチになっていますね。
ちなみに、WebUIやAPIを担うメインのプロセスにもワーカー数があります。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@sakasame なんか参考にしてくれている人がいるから、補足資料貼っとくね。
プロセスが1つ、default, push, mailers, pullキューを処理、25スレッドというのが標準セットアップ。
プロセスを2つにわけて、defaultとmailers、pushとpullを別にした構成例(DTP鯖)
プロセスが17個、サーバは3台に分散、default, mailersが8プロセス、pushが4プロセス、pullが4プロセス、backup(非標準)が1プロセスの構成例(Fedibird)
すこし大きめのMastodonサーバを運営されている方に、v3.3.0rc2以降の変更点についてお知らせです。
このような変更をプルリクしました。
Fix to isolate the sidekiq process that runs the scheduler job
https://github.com/tootsuite/mastodon/pull/15314
要約:
・Sidekiqキューにschedulerを増やしました
・schedulerを処理する専用のSidekiqプロセスをひとつだけ起動してください
ユニットファイルの指定例:
bundle exec sidekiq -c 5 -q scheduler
解説:
Sidekiqプロセス毎にスケジュール実行が予約され、条件によって複数回実行されてしまう不具合がありました。
https://github.com/tootsuite/mastodon/issues/14764
これを、schedulerキューを処理するプロセスに限定する変更を行いました。
なお、構築手順に沿って単一のsidekiqプロセスを起動している場合は変更の必要はありません。sidekiqをキュー指定で複数起動している場合に、対応が必要です。
普通に構築手順に従ってアレンジせずにMastodon動かしている人には関係ないけど、
sidekiqプロセスを複数立ち上げるように変更している人は、新しいキュー種別を増やしたから対応してね、というお知らせです。
masterの変更で、v3.3.0rc2以降で適用になります。
QT: https://fedibird.com/@noellabo/105381910887477692
@sakasame ジョブのグループとしてキューがあって、一つのsidekiqプロセスで、受け持つキューと走らせるスレッド数を指定できるのね。標準では全部のキューを受け持つ25スレッドのsidekiqプロセスを一個だけ立ち上げる。
これを、ローカルのユーザーにとって重要な処理をするdefaultと、外部への配送を受け持つpushや、外部から取得する処理と優先度の低い処理を行うpull
のキューを処理するsidekiqプロセスに分けたりする。defaultを手厚く、ほかはそこそこにすると良いのです。メール送信のmailersキューは、まぁどこかにくっつけとけばOK。
プロセスを分けると、それぞれがCPUを使ってくれるので、マルチコアプロセッサの恩恵が受けやすくなるというのがあります。
また、複数のマシンで実行することで、より沢山のパワーを投入できます。
redisとPostgreSQLがネックになるので無限に強化できるわけじゃないんだけど、そのあたりのバランスをとりながら構成を考えるのが楽しいのです。
@sakasame mstdn.jpでは、defaultキューがつまっていることが多く、pushキューに余裕があることが多くって、サーバ内で各種タイムラインが遅延しているのに、Fedibirdから見るとリアルタイムで届いているっていうようなことが起きています。
best-friends.chatはdefault重視(ローカルの体験がもっとも重要)で、pushとpullがおかしくてもしばらく気が付かないことがあったりします(最近はたぶん安定してる)。
@sakasame なんか参考にしてくれている人がいるから、補足資料貼っとくね。
プロセスが1つ、default, push, mailers, pullキューを処理、25スレッドというのが標準セットアップ。
プロセスを2つにわけて、defaultとmailers、pushとpullを別にした構成例(DTP鯖)
プロセスが17個、サーバは3台に分散、default, mailersが8プロセス、pushが4プロセス、pullが4プロセス、backup(非標準)が1プロセスの構成例(Fedibird)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Sidekiqを単一プロセスで実行している場合、優先順位(重み)が設定されていて、それが機能しています。
defaultが6、pushが4、mailersが2、pullが1で、defaultが最優先されます。これが本来意図しているところです。
複数に分割(default, mailersとpush, pullなど)した場合、pushやpullがパンクしている負荷でdefaultが詰まるような、優先順位が十分に機能しなくなることもあります。
CPUのコア数やHTを踏まえて、同時実行している他のサービス(RedisやPostgreSQLも一緒に動いているなど)の負荷など考慮に入れて構成が必要で、よくわからないなら無理に複数sidekiqの構成をとらない方が良いです。
なんかmastodon.onlineがこのへんしばらくデフォのままで動かしちゃってて、いい加減重くなってから対策したみたいな話があるぐらいでw、そのままでもちゃんと動きます。
Nightly Fedibirdはデフォルトのシンプルな、単一プロセスのsidekiq構成です。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Fediverse (4) Advent Calendarの空いている2日目と3日目、なんか記事書いた人は突っ込んで即公開って感じでいいからね!
このアカウントは、notestockで公開設定になっていません。
@sakasame Mastodonだと50時間ぐらい排出しようと戦いますからね(ActivityPub::DeliveryWorker)
デッドになっても仕方が無いので、最後には消えるようになっています。
一方人体は……
@sakasame pushが詰まっている時って、相手からの応答がすぐにかえってこなくてタイムアウト待ちになっているとかなので、sidekiq増やしてもたぶん効果はありません。
むしろ詰まっている方の腎臓の活動を停止させた方が……
@sakasame そこで、エラーを繰り返しているサーバへの配送を止めるための仕組みが用意されています。これをセットすると、詰まっていた待機中・再試行がすーっと消えていき、腫れが治まるという寸法です!
通常は7日間失敗し続けるまで頑張るんですが、UnavailableDomainにドメイン名を登録するといつでも発動させられます。配送を強制的に正常終了させてくれるようになり、一件落着です。ステントやバイパスみたいなものですね。
@sakasame 手動で削除できるものはそうする、あと一旦サーバブロック・解除でいいかと思います。ホスティングじゃなければ別の方法もあったんですが、たぶんそれしかない。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@Methylenedi_oxy どのアカウントも、1日経過してから参照されると、再取得が自動でかかります。だいたいそのときに直るんじゃないかな。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
SatisのFedi入り(狐の嫁入り的な)の時は、6Kぐらいフォロワーを引っ越し機能で引き連れてきたので、すごい耐久試験になったよね! 壮大な実験だったw
QT: https://fedibird.com/@Satis/105383056164969490
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。