フォロー

しぃちゃんの言うように、リソースの少ないサーバでは、CPUコア数にあわせて、スレッドを絞ってプロセス数でカバーが良いと思います。

Sidekiqのスレッドが効果を発揮するのは処理速度の異なるジョブを平行で実行する時で、例えば20のサーバにDeliveryWorkerが走る時に、pushキューのスレッドが20あると、5つのサーバが凄く遅くても、残りの15はすぐ終了して空きが確保されるので有利というのはあります。

フォローインポートの際は、50あっても塞がるので、どのみち詰まりますw

pullキューは、もともと優先順位を一番低く設定してあって、これを利用して、いくつかの優先順位の低いワーカーがpullを利用するようになっています。

たとえば、投稿を削除する時は、フォロワーへの削除依頼(Delete Activity)はpushキューで処理されますが、リプライやブーストされた相手先サーバへはあまり急ぐ必要がないのでpullキューを使って配送するという戦略をとっています。(DeliveryWorkerはpushですが、LowPriorityDeliveryWorkerはpullを使う)
QT: homoo.social/@204504bySE/10420

:nonke:​お金で買えない団地妻​:homoo:  
Mastodon鯖を速くしたいときに踏みがちな罠(SidekiqとWeb) - Qiita https://qiita.com/204504bySE/items/be580afa77155ecd95be 無限にマサカリが飛んできそうだけどとりあえず書いた。

で、プロセスとキューの振り分けには色々あるけど、ウチはdefault+mailers、push、pullが、VPSを2つ使ってトータル12プロセス。これだと優先順位が付かないので、defaultを優先するために3つめのVPSでdefaultのプロセスだけ立ち上げておこうかと思っている。

defaultが動いていればサーバ内での処理は全て安定して動くので、他が詰まっていても快適に使える。

best-friends.cahtはdefault+mailersを受け持つサーバ、push+pullを受け持つサーバ(extra)の2系統に分けて、必要に応じてそれぞれ増減させる手法だったかな。

pumaの方は、2台のVPS(先程のsidekiqと同居)にWEB_CONCURRENCY=4 がそれぞれ置かれていて、別の入口になるサーバから、HAProxyでラウンドロビンしている。(ロードバランサー)

最近、その外側にCloudflareが加わっている。これはあっても無くても良い。以前はCloudflareでロードバランシングしていたんだけど、そこそこ金が掛かるので切り替えた。

pumaとsidekiqは、ともにPostgreSQLに接続するので、pgbouncerで接続数を制御するのと、PostgreSQLを2台動かしてレプリケーションし、読み出しだけで良いアクセスについてはレプリカ側にアクセスさせている(リードレプリカという手法)。

(オーバースペックなのでこのへんは真似しなくて良いです)

最近気づいたのは『キューづまりを起こしてるからって安易に extra を増やすと、 fetch される web に負荷が一時的にスライドして問題を起こす』です。なんで、外部配送の増強時はその後にくる問い合わせに合わせて Rails も増やさないとダメなんだなーと思っています

@rosylilly おぉ……知見だ……。

一般に、ボトルネックは解消すると別の場所に移動するので、動かしながらどこでバランスするか見極めておかないといけませんね。

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。