４（Four） @yn4hc@fedibird.com

Mastodonのような時系列・リアルタイムのタイムラインを持つマイクロブログは、様々な処理が同時に行われるよう期待されています。

しかし、通常時は問題無く処理できても、ピーク時には処理が難しいことがあります。

たとえば、みんなが浮上してくるゴールデンタイムや、明けましておめでとうのタイミング、地震発生直後、『バルス』などなど……

このとき、キャパシティを越えた処理を失敗させるのではなく、順番待ちの行列（キュー）の最後尾に追加することで、処理を遅らせて確実に処理しようとします。

言い換えると、失敗する代わりに遅延させるように設計されています。

なお、本当に限界を越えた場合は、キューの最後に追加する処理ですら不可能で、エラーになることもあります ＼(^o^)／

MastodonのWebUIは、自分の投稿をサーバに送信すると同時に、（手元の）ホームタイムラインに流し込みます。

これにより、投稿を行ったら遅延無く反映されている……ように思わせています。

実際には、サーバに送られた自分の投稿が、あとからストリーミングを通じてホームタイムラインに挿入するよう指示が流れてきます。これは無視します。

この時、ホームタイムラインの処理が遅延していると、実際に反映されるまで時間がかかります。

まだ反映されていないうちにリロードすると、サーバ上の状態にリセットされるので、さきほど投稿直後に差し込んだものが消えてしまいます。

しかし、これは見た目上のことで、あとでホームタイムラインの該当箇所が流れてくるタイミングでちゃんと流れてきます。

まとめると……

ホームが遅延しているときにリロードすると、自分の投稿が消えたように見えますが、追いついた時にちゃんと流れてきますので、ご承知おき下さい。

#fedibird

#fedibird #fedibird_info 一連の不調、メモリー使用量のコントロール問題だということがわかりました。

調整して何度か再起動してますが、安定する方向に向かってます。

経路変更の方も再度適用します。

#fedibird #fedibird_info さきほどから起きている現象と対応、書き留めておきます。

データベースが何度か落ちています。データベース自身が自動shutdownする挙動です。

過去の経験から、データベース接続数などのパラメータを大きくとった時に同様の現象が起きており、過負荷が疑われるため、少し数値をしぼって様子見しています。

ルート変更については、Mastodonプロセス側の効率が向上するため、データベースからみると負荷が高まるため、無関係ではないかもしれません。

データベースが落ち着いたら、再度、ルート変更を試してみます。