このアカウントは、notestockで公開設定になっていません。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@Cutls Pawooで自動通報されないウケるけど悲しい……。
まぁ、自動サイレンスされる仕様は回避したので、各サーバの管理者が無視してくれれば大丈夫。サスペンドされたらアウトw
https://mstdn.jp/@Sujiyan/104450982986747278
たまに見たアラビア語トゥートにガチなやつが混ざってたのが原因らしい
@blank71 アカウント削除も他鯖に反映されないようで、これがわりとヤバイ。連合先に負荷はかからないけど、消したかった全てが他鯖のキャッシュに残るという。
mstdn.jpの遅延、defaultキュー捌いてるsidekiqのサーバをまるごと再起動すると、わりとあっさり治るかもしれない。メモリ不足でスワップしまくって処理能力が落ちてることも考えられる。
遅延しているだけで、動作自体は安定している様子なので……。
このアカウントは、notestockで公開設定になっていません。
@watanobecreate 今回は、各サーバからmstdn.jpへの配送は受理されているし、mstdn.jpからリモートへの配送は遅延してないので、連合しているサーバへの影響はないと思います。
mstdn.jpの遅延が解消するどころか拡大している件、これだけ流量が少ない深夜でこの状況が続いているというのは、正常系の過負荷ではなく、なんらかの異常があると考えざるを得ない。
Fedibirdでは、古いアカウント削除ジョブが何度も再試行されて削除処理がストームを起こしたことがある。
またその影響で、メモリが枯渇してスワップをギリギリまで使った状態となり、処理速度がもの凄く低下した。ちゃんと動くけとメッチャ遅い。これは再起動で解消した。
現在のmstdn.jpは、遅延して届くストリーミングの状況からみても、動作速度にムラがなく、単純に遅い。何か異常なジョブがキューを埋めているか、単純にものすごく速度低下している。
サーバの状態の確認・監視と、Mastodonの内部動作の理解があれば、解決の糸口は見つけられると思う。
まぁ、鯖缶 というほかない。
mstdn.jpから外部のサーバへの配送は遅延無く行われています。Fedibirdから観察している限り、LTLの遅延はまったくありません。停止前までも、復帰後も、いずれも遅延無く常にスムースに流れてきています。
--
Mastodonは、一つ一つのアクションに対してジョブが作成され、それを順番に処理していくのですが、ジョブの種類によって、違う順番待ちの列(キュー)があり、メチャクチャ遅延している列と、普通に捌けている列がある状態です。
主にサーバ内(ローカル)の処理を担っている、一番重要なキューがdefaultです。HTLへの配送が激しく遅延していると思いますが、defaultキューが捌き切れていないことが原因です。もの凄い数のジョブが順番待ちになっていることでしょう。
主に外部のサーバへ配送を行う2番目に重要なキューがpushです。外部からみるかぎり、このキューは遅延無く処理されています。何か書き込んだ時点で、すぐにリモートのサーバに届いているのでご注意ください。
他に、外部からの配送を受け取るpullキュー、メール送信のmailersキューがあります。
投稿は、投稿が完了した時点でデータベースに書き込まれています。
LTLは、データベースから直接投稿を取得した場合、最新の内容が取得できます。
一方、ストリーミング(新着投稿を順次受け取って、タイムラインをリアルタイム更新する機能)は、defaultキューに生成されるDistributionWorkerによって処理されるため、defaultキューで順番待ちとなり、逆にリアルタイムに更新されない有様となっています。
ついては、ちょっとサーバへの負荷は増えますが、LTLをストリーミングを使わずに再取得することで、最新のLTLを見ることができます。方法は、 @qk_k あすとらさんの説明がわかりやすいです。
https://mstdn.jp/@qk_k/104450986751164747
ただし、この方法は、メディアオンリーのLTLを取得して、また通常のLTLを取得するため、ちょっと余計な負荷がかかりますね。
別の方法として、スタートタブを開いて、ローカルタイムラインを選択するやり方もありあります。既存のピン留めしたLTLも同時に更新されます。
戻るで戻って、また選択すれば更新されます。
TIPSです。
リプライ通知は遅延します(相手が気付かない)
お気に入りとブーストは通知が遅延しないので、いずれかの方法で通知すると良いでしょう。
【解説】
現在、mstdn.jpの中でリプライやメンションした場合、defaultキューにLocalNotificationWorkerが積まれるので、順番待ちとなり、通知が遅延します。
他方、お気に入りやブーストはキューを経由せずに通知を行うので、すぐに届きます。
ストリーミングがおかしくなっていると考えている人が多いと思いますが(外形的には間違いではありませんが)、ストリーミングサーバ自体は正常です。
defalutキューが遅延していて、そこを経由する動作が遅延していることが真の原因です。
ブーストが遅延する原因も、通知がLocalNotificationWorkerで行われる(defaultキューに積まれる)ことが原因です。
ちなみにブーストは投稿(status)の一種として扱われています。皆さんの投稿数にもカウントされていますよね(Mastodon固有の仕様です)。
ActivityPubでは、投稿はCreate Activityとして、ブーストはAnnounce Activityとして表現される、別の概念です。
mstdn.jpの遅延、defaultキュー捌いてるsidekiqのサーバをまるごと再起動すると、わりとあっさり治るかもしれない。メモリ不足でスワップしまくって処理能力が落ちてることも考えられる。
遅延しているだけで、動作自体は安定している様子なので……。
mstdn.jpの遅延が解消するどころか拡大している件、これだけ流量が少ない深夜でこの状況が続いているというのは、正常系の過負荷ではなく、なんらかの異常があると考えざるを得ない。
Fedibirdでは、古いアカウント削除ジョブが何度も再試行されて削除処理がストームを起こしたことがある。
またその影響で、メモリが枯渇してスワップをギリギリまで使った状態となり、処理速度がもの凄く低下した。ちゃんと動くけとメッチャ遅い。これは再起動で解消した。
現在のmstdn.jpは、遅延して届くストリーミングの状況からみても、動作速度にムラがなく、単純に遅い。何か異常なジョブがキューを埋めているか、単純にものすごく速度低下している。
サーバの状態の確認・監視と、Mastodonの内部動作の理解があれば、解決の糸口は見つけられると思う。
まぁ、鯖缶 というほかない。
#Fediverse技術部 のみなさま!Mastodonが利用している暗号技術とかAcrivityPubの他のプログラムについて書いてみませんか?MastodonについてE2EEも含めてわからないなりに書き始めたものが下記にあります
- Preview: https://deploy-preview-38--mitomein.netlify.app/sns/mastodon.html
- PR: https://github.com/zunda/mitome.in/pull/38
KeybaseとかMatrixとかについての記事も大歓迎
もうすぐ援軍が来るぞ!
もとい
Suji Yanさんが色々頑張ってくれている
ということにしておきたいところだけど、正直何もしてないような気がするw
@ARTi 玉子丼ダメですか……。
玉子丼、なんか特定の処理が異様に重いことがあって、たぶんタイムアウトしてます。ちょっと対策入れてみるので、あとでもう一度フォローインポートお試し下さい。
mstdn.jpのサーバは、たぶんドイツのHetzner Online GmbHにある。mastodon.socialと一緒。
前管理者のDSNOの考え方からすると、Dedicatedのコアとメモリの多いサーバをドンと借りて、そこでメモリの許す限りプロセスを走らせてるんじゃないかな。
ぬるかるさんちも、その後のさくらインターネットも、そういう高火力の強いサーバでドカンと動かすアプローチだったと思う。
ちなみに、mastodon.socialの構成については、3ヶ月ぐらい前にEugenさんからこんな回答があった。
>
On mastodon.social, I have 8 machines roughly equivalent (not all are the exact same model) to:
- Intel® Core™ i7-4770 Quad-Core
- 32 GB DDR3
3 machines have Puma running on them,
2 machines have Sidekiq running on them,
1 machine has Nginx,
2 machines have PostgreSQL (primary and replica),
2 machines have Redis (persistent and cache),
and 1 machine has ElasticSearch
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@ARTi だめかー。では、もう一段階緩くしてみましょう。少々お待ちを。
それでもダメなら、明日のメンテで玉子丼がパワーアップするのを待った方がいいかもしれません。
mstdn.jpのLTL、取得した瞬間はDBからとってくるから遅延してないんだよなー。あとから、ストリーミングが4〜5時間前のを送りつけてくる。
defaultキューに大量の未処理ジョブが積み上がってるじゃん?
mstdn.jpのユーザーが投稿すると、defaultキューにDistributionWorkerが積まれる。DistributionWorkerというのは、投稿をローカルのFTLやLTL、HTLやリストに分配するワーカー。
これが4時間45分ほど経って実行される。実行されると、LTLにストリーミングで投稿が流れる。また、defaultキューにFeedInsertWorkerが積まれる。FeedInsertWorkerというのは、HTLやLTLに投稿を流し込むワーカー。
これが4時間45分以上(たぶんどんどん延びてる)経って実行される。実行されると、みんなのHTLにストリーミングで投稿が流れる。
こうして、LTLは現状で4時間45分の遅延、HTLは9時間以上の遅延になる。
仕組みとしては恐らくそういうこと。
@nieein56 問題ないです。遅延無しで来てます。
ここしばらく恒常的に一部の処理(ブーストとか)が遅くてタイムアウトするのは観測していますが、明日のメンテナンス後に解決することを期待しています!
mstdn.jpは、その規模と役割から、技術面だけでも様々な例外に対処しないと安定させられないハズで、ここは様々な運用ノウハウが要ると思います。
サーバ運用の一般的な問題はもとより、Mastodon固有の問題に対しても、ソースコードを読み込んで、実際に動かし、どういう動きをするか把握していないと、適切な対処を行うのも難しいハズです。
ぬるかるさん、きぼうソフト・DSNOは、そのぐらいは出来て当たり前の技術を持っていたわけです。
前任者達、そういうの説明しないのでわからないと思いますがw
friends.nico、best-friends.chatのロージーさん(ハト先生)、まさらっきさんは、そのへんは完全にプロで、メッチャ強いです。
Pawooも、いろいろ独自に改造してきただけあって他のMastodonより問題が起きにくいよう色々仕込んであり、わかる人が見張っているので、凄く安定していると思います。
mastodon.socialは、そういう意味では最強です。オリジナル開発者ですからね。それでも長年wasabiに苦しめられてきましたw
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@fujii_yuji 詳しい説明がまだされてないけど、アラビア語のテロ予告みたいなのがあったようで、昨日4時間ぐらいサーバ事業者から停止措置を受けてました。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@nelsoncoffeeroaster なんか話している前提をひっくり返されて本気で驚いているシチュエーション憧れるじゃないですか(憧れません)
まぁ、なしきの真似してみたいだけです!
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
お一人様やめて #fedibird 来る人、元社長って感じで、良さも大変さもわかってて、納得して『お世話になります』って来るので、めっちゃ頼もしさあるよね。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
mstdn.jpは現在、何らかの原因によりdefaultキューにジョブが大量に積み上がっていて、処理が遅延しているものと思われます。
現在、概ね5時間8分前のジョブが処理されています。
HTLは、LTLの概ね2倍遅延します。
LTLはdefaultキューで処理されるのを1回、HTLはdefaultキューで処理されるのを2回待たなければならないためです。
https://fedibird.com/@noellabo/104453210174536916
LTLは、全員同じデータを元に表示するので、データベースから取得すれば最新の情報を表示できます。
ストリーミングはdefaultキューで処理されたものが流れてくるので、遅延しています。
クライアントから利用している場合は、ストリーミングは切った方が良いです。
最新投稿は、スタートメニューを表示して、ローカルタイムラインをクリックすることで更新してください。ピン留めした絡むも更新されます。
ホームとリストは、ユーザー別にdefaultキューに積んだジョブにより構築されるものなので、処理が完了するまで最新の内容に更新されません。これは現状、あきらめるしかないです。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
mstdn.jpのアカウント、ほとんど人をフォローしてないので遅延具合がわからないんだけど、Fedibird中曽根さんの18時間前の投稿が流れてきたのはちょっと遅延しすぎだな……。
新潟のきらら展、会期メッチャ長いので、都合の良い日に行って、展示作品みて、グッズいっぱい買ってくるといいよ。都内だと催事まともに開けないからな……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
正常なトラフィックが迷惑になることはないと思うよ。本来の処理能力なら普通に捌ける内容なんだからキニスンナ。
mstdn.jpが復帰する際、ゆっくり待機が解消されていくように、キューを絞ればいいんだよ。
運営者が上手にサーバをコントロールすれば済むこと。
運営者からお願いがあったら、その時に考えれば良いよ。
(mstdn.jpへのリアクションは遠慮しなくていいと思うよって話)
@nzws アバターがおぬすけパイセンのイラストに代わってる!!
QT: https://don.nzws.me/@nzws/104453381120749566
@daira 実は、確認しようとしたら、ウチのルーターもゴネだして、繋がらなくなったりして超焦りましたw
接続している人のルートとか、IPv4とIPv6とか、いろいろ不具合も条件付きで発生するので、気にせず呟いて下さい。その方が気付くのはやくなるので!
このアカウントは、notestockで公開設定になっていません。
広告ブロッカーでmstdn.jp/api/v1/streaming/をブロックしたらLTLに最新トゥしか現れなくなって見やすくなる
5時間前のトゥ流れるのが楽しめなくなるので一長一短だけど
このアカウントは、notestockで公開設定になっていません。
@rk_asylum みんなわかってないかもしれないけど、DSNO、あれで頼りになる管理者だったんだぜ。それが7月から完全に手を引いちゃったんだから、ここは正念場であります。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
LTLの回復速度が減速してきたね。HTLまで含めると、解消までまだ数時間かかるな。
でもこのぐらいの速度じゃないと、負荷が高まり過ぎちゃうから、丁度良いと思う。