Conversation

Notices

1. のえる (noellabo@fedibird.com)'s status on Wednesday, 13-Jan-2021 07:37:47 JST のえる

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

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

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

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

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

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

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

   • ゆらのふ and かき＠ひろしま丼 :sabakan: :verify: repeated this.
   • のえる (noellabo@fedibird.com)'s status on Wednesday, 13-Jan-2021 07:41:58 JST のえる

     in reply to

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

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

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

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

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

     かき＠ひろしま丼 :sabakan: :verify: repeated this.
   • のえる (noellabo@fedibird.com)'s status on Wednesday, 13-Jan-2021 08:00:34 JST のえる

     in reply to

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

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

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

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

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

     かき＠ひろしま丼 :sabakan: :verify: repeated this.
   • のえる (noellabo@fedibird.com)'s status on Wednesday, 13-Jan-2021 08:04:51 JST のえる

     in reply to

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

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