#fedibird 最新masterに適用されたある修正で、インデックス無しの全ステータス検索が実行される問題があって、お知らせにURLを含むケースでメチャ重いという問題が発生していました。
昨晩はそれを再現実験したり、インデックスを作成してみたり、ちょっと無茶をやっておりました。
現在、作成したインデックスによって負荷をかけることなく動作するようになりましたが、そのインデックスだけで1GBを超えるのでちょっとツライ感じです。
また、Mastodon本家サイドでどういう解決を考えるかはこれからというところです。
#fedibird ちょっとデバッグで無茶してるので、サーバ重くなってます。解消まで少々お待ちを。
もろもろ調整がきいて、サーバが安定した気配。 #fedibird
#fedibird のハッシュタグタイムラインの取得を高速化しました。 #rssfeed とか #news 、 #frfr #abyss_fun などの激重タグが、他のタグと同様の速度で表示されます。
……まぁ、普通に見えるだけなので、困っていなかった人は、特に嬉しくないかもしれません……。
(ブロックしまくっている人は、取得するハッシュタグ件数を絞り込んだ副作用で、ブロックしている人の投稿を取り除くことで取得データが空になってしまうことがあり、正しく表示できない場合があります)
#fedibird WebUIで、単独で絵文字を投稿すると拡大される奴(はんどんから拝借)を適用してあります。クライアントアプリでは、 tootoiseでも同様になります。
#fedibird 昨日行っていたメディア削除は無事に完了し、700GB超だった容量が230GBほどになりました。たぶん月額$12〜$13ぐらいの節約になるかな。
そして今朝から、データベースのリードレプリカを有効にしました。
Fedibirdのデータベースは、独立した2つのVPS上にあって、それぞれ、マスターと、それの複製(レプリカ)になっています。
これまでは、マスターだけを更新・参照していて、レプリカは非常時に備えて待機しているだけでした。
これを、更新をマスターに、参照をレプリカに対して行うように設定しました。
この運用方法は、2台のサーバで手分けして対応するようになるので、1台あたりの負担が軽くなるメリットがあります。
同期レプリケーションが必須になった分、更新の完了に少し時間がかかるようになっていますが、体感できるほどではないと思います。
#fedibird 引用した投稿のidを保持するフィールドにインデックスが設定されていなかったことが高負荷の原因と思われるため、対処しました。
処理の98%を占めるスロークエリ……。
#fedibird 待機キューの詰まり方がなんかおかしいな? 引用関係のコードに問題があるかもしれん。要確認。
内容によってはかなり重いなー。待機キューが積み上がってきたので中止。 #fedibird
うーん、データベースサーバのCPUパワー不足だな、これは……。 #fedibird
#fedibird ひとまず中断。ちょっと別の方法を試してみます。
#fedibird 第二弾。メディア削除のタスクを走らせ始めました。concurrency=1で実行しているのもあり、CPU使用率は12%前後ですね。
挙動がおかしいとか、重い!など気がついたことがありましたら教えてください。
#fedibird お知らせ入れようと思ったら終わってしまった……。
ここ2時間ばかり、少々重めのタスクを走らせて負荷試験的なことをしておりました。私自身はあまり確認できなかったのですが、やはり相応に重かったようですね……。
データベースサーバの、おそらくメモリ不足から動作不安定になることがあったようなので、swapを増強しつつ、一定の負荷をかけつつ様子をみておりました。効果があって安定したようです。先程は待機が6,000ぐらい積まれるところまで詰まりましたが、エラーにならず捌ききってくれました。
あとは、私が余計なことをしなければ安定するでしょうw
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。