#fedibird 深夜にごそごそメンテしてましたが、ElasticSearchというMastodonの全文検索のエンジンになっているサービスが落ちており、大量の未処理ジョブを抱えていたのを解消させておりました。

あわせて、sidekiqのスレッド数の調整など細かな調整を行いました。

もうサーバ動作の方は落ち着いているかと思います。

@squid999 おはよー。

@mirai

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

めっちゃ美味しそう

このアカウントは、notestockで公開設定になっていません。

@magnesite こういうの好き。活動的な子。

@mamemomonga 🎉🎉🎉

結局SlowQueryのことを考えている。最適化楽しすぎる。

このアカウントは、notestockで公開設定になっていません。

@NPC 現在認識されている、同一メッセージでパターン化されたスパムアカウントは処置しました。

通報機能を使って、理由を記載の上、報告いただけると助かります。 #fedibird

@frfr 遅い理由はわかったので、ちょっと強引にスピードアップしてみたよ。
https://github.com/fedibird/mastodon/commit/54a602d548cb93b9f54ccb254f87663ede089454

やり方がめっちゃ汚いのと、ブロックしてる人が多かったりするとちゃんと表示されない弱点があって、何か対処考えようと思ってるけど、とりあえず実用上はほぼ問題なさそう。

ハッシュタグタイムラインの取得クエリが遅いのは、該当のハッシュタグが使われている件数が一定以上多い場合にwork_memを超えてしまい、Bitmap Index Scanした後にexactではなくlossyで処理されて、Bitmap Heap Scan のRecheckが走ってしまうため。

何を言っているかわからないと思うのでw、詳しい人が説明してくれてる記事をみて……。
https://taityo-diary.hatenablog.jp/entry/2018/07/07/071928

work_memはそうそう大きくできないので、frfrとかabyss_fun、theboss_techのような件数の多いタグに対応するのは難しい。

んで、私が今回とったアプローチは、通常は最後に行うページング用のパラメータを、事前にハッシュタグを抽出する際に適用して処理対象件数を減らすというもの。とりあえず200件だけ取得してあとは無視するようにしたので、取得した200件がロック対象だった場合にタイムラインそれ以上遡れないという問題がある。

まぁ何にしても快適にはなった。

ただ、ちょっとこれを公式にぶち込むのはあんまりなので、もっと洗練させたい。

@p_q こっちもやっていかないとねー。Default settingは、set :quiet とか set :json ってしておくと、毎回オプションつけなくても既定値になる奴。set :json:off って感じで解除。:quietにしとくと、実行結果をリプライしてこなくなる。

Qiita丼からまとめて来てた。sidekiq詰まってた感じだねぇ。

めっちゃ遅いハッシュタグ #frfr は代表格だけど、ウチで一番多いのは rssfeed

ビターキャラメルのセット、お得以外の何物でも無いぞ。 #ncr

@nelsoncoffeeroaster あいあいさ