Mastodonのdefaultキューの処理が追いつかないと、ストリーミングで古い投稿が流れてくるようになります。

LTLが2時間遅れている場合、FTLは4時間、HTLは6時間程度の遅れになる傾向があります。

これは、defaultキューで順番に処理されるWorkerを、それぞれ1回、2回、3回通過しなければいけないからです。

連合は、リモートから受け取った投稿などをActivityPub::ProcessingWorkerというWorkerが処理したあとで、DistributionWorkerというWorkerが配送します。

ローカルは、所属サーバのユーザーの投稿があると、ActivityPub::ProcessingWorkerを経由せずに直接データベースに内容を反映した後、DistributionWorkerによってサーバ内の各タイムラインに配送処理が行われます。

ホームは、DistributionWorkerの中からさらにユーザー毎にFeedInsertWorkerが走ります。

連合の中のローカルの投稿は、ローカルと同じ遅延になります。

フォロー

なお、初回ロード、リロードした場合、データベースから直接タイムラインの情報を取得します。

そのため、ストリーミングを経由せずに内容が構築されます。

LTLは、ユーザーが投稿を行って受理された直後にデータベースに反映されるため、ここでは遅延が発生しません。

連合は、ローカルユーザーは遅延なし、リモートユーザーはWorker1回分の遅延となります。

ホームは、FeedInsertWorkerによって内容が構築されるため、ストリーミングと同様にWorker3回分の遅延となります。

ちなみに、ストリーミングの処理自体は、redisというオンメモリのデータベースを経由して、node.jsによるストリーミング専用のプロセスが行っています。

このプロセスが止まったり異常が発生した場合は、タイムライン上部に「‥‥‥‥‥‥」というマーカーが出て、新しいストリーミング(リアルタイムのタイムライン更新情報)を受け取れていないことが明示されます。

このマーカーをクリックすると再接続を試みますので、一時的な問題の場合は解決します。サーバ側が落ちているときはダメです。

便宜上、ストリーミングが遅延していると表現してしまいますが、ストリーミングサーバが原因であるのではなく、単に配送しろという指令がredisに届いてないだけだったりします。

『sidekiqのdefaultキューの遅延が原因でストリーミングが遅延している』ということになります。

最後にひとつ付け加えておきますが、この仕組み上、リロードしまくればローカルの遅延を回避できるということになりますが、サーバに多大な負荷が掛かるため、全体としては症状が悪化します。

遅延している場合は、管理者に不具合状況の連絡を行った上で、回復まで、あまり負荷をかけないように見守ってあげてください。

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

LTLのないFediverse志向の汎用Mastodonサーバです。Fediverseの活動拠点としてご利用ください。