@noellabo キューが優先度別になってても、低優先のjobを中断してまで高優先のjobを処理してくれる訳ではないです。プロセス内の並行数がいちど低優先のjobで溢れると、同プロセス内の高優先キューの処理が著しく遅くなります。この問題はキューごとにプロセスを分ける事でしか解決策できません。defaultは死守しないとWebUIの応答性が悪くなるので専用のプロセスを立てる。pullはフォローリクエストで溢れるので専用のプロセスを立てる。mailとpushは残りの1プロセスにする。という3プロセス構成が負荷対策の基本だと思います。
@tateisu 助かります！
FedibirdはSidekiqを2台で受け持ち、キュー毎にプロセス分離（mailersは同居）で6プロセスという構成を基本にやってきました。
現状でも、アカウント削除とbest-friends.chatが詰まったヤツを放出する時に待機が積み上がるぐらいなんですが、応答性が低下するほどではない感じです。
パワーで押し切って回ってしまうのですが、もっとタイトにいけると思うので、落とし所を探っています。
そういえば、最近フォローインポートで重くなるって観測できてないな……。
@noellabo キューごとにプロセスを分けるのは割と必須ですね。何度かまとめようとはしましたが、すると何かのタイミングで事故が起きて元に戻す…を繰り返すだけでした。ここからは削りようがないのだと思います。
@tateisu いままでスレッド数が多めだったので、モニターしていると実行中の数字が増えがちだったんですが、スレッドを絞って、待機中に数字があがってくるようになりました。
実行中に数字があがる状態は、各プロセスが多数のジョブを抱えたままになっているので、同じキューを処理するプロセスが手空きでも手伝えないため、待機中（これこそキューですね）に積んでおいて手空きのプロセスに拾ってもらう方が健全かなと。
この時間になって、少し流量が増えて観測しやすくなってきました！w
@noellabo sidekiqのメモリが増える要因はActiveRecordのキャッシュが大きいと思ってるのでプロセスを小分けにするとそれぞれキャッシュを持つ分だけ損かと思ってたんですが、メモリ多めのマシンだと分けた方が有利なのかもですねー。
@tateisu メモリは厳しいですよね……。ウチは16Gと8GのVPSなので、ここも力任せにまわしてます……。
pullキューが溢れるような状況になったときに、defaultキューだけは守らねばならない。pushもできれば守りたい。
この構成は全部バラバラにプロセスを割り当てているので、おそらく、優先順位がついていない。
defaultキューだけを捌くサーバを割り当てるか。pullだけを引き受けるサーバを割り当てるか。