まぁまぁ頑張った。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird ちょっと後ろで走らせていたプロセスがデータベース接続を飽和させたようで、500エラーなどが出ていたかと思います。さきほど対処しました。
ご心配お掛けしました。
@Yashima おはようございます!
DBサーバ側に問題があった感じなので、swap増強して、負荷を与えてテスト中です。メモリちょっと足りなかったかなー。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird お知らせ入れようと思ったら終わってしまった……。
ここ2時間ばかり、少々重めのタスクを走らせて負荷試験的なことをしておりました。私自身はあまり確認できなかったのですが、やはり相応に重かったようですね……。
データベースサーバの、おそらくメモリ不足から動作不安定になることがあったようなので、swapを増強しつつ、一定の負荷をかけつつ様子をみておりました。効果があって安定したようです。先程は待機が6,000ぐらい積まれるところまで詰まりましたが、エラーにならず捌ききってくれました。
あとは、私が余計なことをしなければ安定するでしょうw
Subway Tooterが対応してくれていることもあり、Mastodonのお知らせ、きちんと機能するという実感を持ちました。
もとより全員に伝えることはできないワケですが、アクティブの一定割合を超えれば実用性があると判断できます。絵文字リアクションもなかなか役に立っています。
#fedibird 第二弾。メディア削除のタスクを走らせ始めました。concurrency=1で実行しているのもあり、CPU使用率は12%前後ですね。
挙動がおかしいとか、重い!など気がついたことがありましたら教えてください。
私のMastodonデータベース移設作業ですが、移設先をレプリケーションのスタンバイサーバにしてから切り替えることがほとんどです。
旧鯖のpostgresql.confに
listen_addresses = '*'
synchronous_commit = off
max_wal_senders = 3
wal_level = replica
hot_standby = on
pg_hba.confに
host replication replication_user xx.xx.xx.xx/32 md5
ufw allow from xx.xx.xx.xx to any port 5432 proto tcp
などと準備しておいて、新鯖で
pb_basebackup -h yy.yy.yy.yy -D /var/lib/postgresql/12/main -U replication_user -R -P
pg_ctl start
.env.productionを新鯖に書き換え、鯖とめて、
pg_ctl promote
でDB本番移行。鯖再開という感じです。
replication_userを事前に作成しておくのを説明してないな……。まぁ、イメージがわかればOKということで。
psql -c "CREATE ROLE replication_user LOGIN REPLICATION PASSWORD 'xxxxxxxxx'";
レプリケーションやDB鯖移設、難しくないよ、というお話でした。
以前、そのへんを少し丁寧に書いたヤツはこちら。
https://noellabo.qrunch.io/entries/xvEfTs4zVrTzqSM7
#fedibird ちょっとしばらくmedia remove動かしておくので、体感速度とかエラーでてないかとか、見られる人みといて。
このアカウントは、notestockで公開設定になっていません。
#fedibird 待機キューの詰まり方がなんかおかしいな? 引用関係のコードに問題があるかもしれん。要確認。
#fedibird 引用した投稿のidを保持するフィールドにインデックスが設定されていなかったことが高負荷の原因と思われるため、対処しました。
処理の98%を占めるスロークエリ……。
このアカウントは、notestockで公開設定になっていません。
PleromaがActivityやObjectをJSONのまま保持して使うので、それでUI側が死んだりしてやっかいだった……。
リレーは、pub-relay(mastodon)がCrystal、pub-relay-proto(mastodon)がRuby、ActivityRelay(Pleroma)がPython、Activity-Relay(雪餅)がGo、ランランさんのがNode.js
@wakin quote_idにインデックスつけました。
https://github.com/wakin-/mastodon/pull/46
普段はインデックスなくても大差ないですが、アカウント削除などstatusの大量削除が行われると死ぬほど遅くてヤバイです。
@weep 突如現れたLTLのあるsyuiloが管理者のMisskey。MisskeyHost(村上さんのホスティングサービス)で提供されている。
このアカウントは、notestockで公開設定になっていません。
masterで発生していた、新規にログインできない問題、解決しましたね。
https://github.com/tootsuite/mastodon/pull/13177
昨日私が流した情報に誤りがあり、puma 4.3.3にて解決していたようです。
puma 4.3.3を使用することでMastodonでも無事にログインできるようになりました。
HTTPヘッダへのインジェクション対策を行った際に、改行の取り扱いに問題があり、クッキーのヘッダを壊してしまうことが原因だったようです。テストケースが甘くて気がつかなかったみたいですね。
https://github.com/puma/puma/issues/2132
@mitarashi3799 まったくログインできなくなる奴だから、たぶん別の話だと思うよ!
毎日、開発中の最新使ってるようなサーバだけの問題。
#fedibird 昨日行っていたメディア削除は無事に完了し、700GB超だった容量が230GBほどになりました。たぶん月額$12〜$13ぐらいの節約になるかな。
そして今朝から、データベースのリードレプリカを有効にしました。
Fedibirdのデータベースは、独立した2つのVPS上にあって、それぞれ、マスターと、それの複製(レプリカ)になっています。
これまでは、マスターだけを更新・参照していて、レプリカは非常時に備えて待機しているだけでした。
これを、更新をマスターに、参照をレプリカに対して行うように設定しました。
この運用方法は、2台のサーバで手分けして対応するようになるので、1台あたりの負担が軽くなるメリットがあります。
同期レプリケーションが必須になった分、更新の完了に少し時間がかかるようになっていますが、体感できるほどではないと思います。
同期レプリケーションは、postgresql.confに
synchronous_commit = remote_apply
などの設定が必要です。
常時バックアップのレプリカであれば、非同期の方がパフォーマンス面で有利なので、offの方が良いでしょう。
リードレプリカの設定については、Mastodonの公式ドキュメントに記載があります。
https://docs.joinmastodon.org/admin/scaling/#read-replicas
ソースコード上の config/database.yml にdb設定を直接書くわけにはいかないので、ウチではこんな風に変更しています。環境変数を使って、.env.productionにデータベース接続を記述します。pgheroも設定しておいた方がいいですね。
https://github.com/fedibird/mastodon/commit/32abc914c589ca2e3be3c952aeeeea2fe6aaebd9
まめもさんがコレになっていた。ご愁傷様です……。
QT: https://fedibird.com/@noellabo/103742625819965813
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
masterで発生していた、新規にログインできない問題、解決しましたね。
https://github.com/tootsuite/mastodon/pull/13177
昨日私が流した情報に誤りがあり、puma 4.3.3にて解決していたようです。
puma 4.3.3を使用することでMastodonでも無事にログインできるようになりました。
HTTPヘッダへのインジェクション対策を行った際に、改行の取り扱いに問題があり、クッキーのヘッダを壊してしまうことが原因だったようです。テストケースが甘くて気がつかなかったみたいですね。
https://github.com/puma/puma/issues/2132
@mayaeh お知らせありがとうございます!
あれこれやっているときに、pumaのissueをちゃんと見つけられていれば……。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird 深夜にごそごそメンテしてましたが、ElasticSearchというMastodonの全文検索のエンジンになっているサービスが落ちており、大量の未処理ジョブを抱えていたのを解消させておりました。
あわせて、sidekiqのスレッド数の調整など細かな調整を行いました。
もうサーバ動作の方は落ち着いているかと思います。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@frfr 遅い理由はわかったので、ちょっと強引にスピードアップしてみたよ。
https://github.com/fedibird/mastodon/commit/54a602d548cb93b9f54ccb254f87663ede089454
やり方がめっちゃ汚いのと、ブロックしてる人が多かったりするとちゃんと表示されない弱点があって、何か対処考えようと思ってるけど、とりあえず実用上はほぼ問題なさそう。
ハッシュタグタイムラインの取得クエリが遅いのは、該当のハッシュタグが使われている件数が一定以上多い場合にwork_memを超えてしまい、Bitmap Index Scanした後にexactではなくlossyで処理されて、Bitmap Heap Scan のRecheckが走ってしまうため。
何を言っているかわからないと思うのでw、詳しい人が説明してくれてる記事をみて……。
https://taityo-diary.hatenablog.jp/entry/2018/07/07/071928
work_memはそうそう大きくできないので、frfrとかabyss_fun、theboss_techのような件数の多いタグに対応するのは難しい。
んで、私が今回とったアプローチは、通常は最後に行うページング用のパラメータを、事前にハッシュタグを抽出する際に適用して処理対象件数を減らすというもの。とりあえず200件だけ取得してあとは無視するようにしたので、取得した200件がロック対象だった場合にタイムラインそれ以上遡れないという問題がある。
まぁ何にしても快適にはなった。
ただ、ちょっとこれを公式にぶち込むのはあんまりなので、もっと洗練させたい。
@p_q こっちもやっていかないとねー。Default settingは、set :quiet とか set :json ってしておくと、毎回オプションつけなくても既定値になる奴。set :json:off って感じで解除。:quietにしとくと、実行結果をリプライしてこなくなる。
@frfr デフォルトハッシュタグ適用のサーバ向け
https://github.com/fedibird/dtp-mstdn-jp/commit/834240223021c87074ccdec5170de824fc5794c1
#theboss_tech タグは、新参のFedibirdで見るより古参のDTP-Mstdn.jpで見た方がいいんですが、今回ハッシュタグの高速化を図ったので、すぐに表示されるようになりました。軽い。
DTP鯖でみる #theboss_tech
https://dtp-mstdn.jp/tags/theboss_tech
スパム退治のやつ。ふざけて文言を真似しているアカウントも容赦なく削除される。危険。
Account.where('note like ?', '%i am playful person. I would like to make your dreams and hidden fantasies comes true.%').map{ |account| SuspendAccountService.new.call(account, reserve_email: false) }
このアカウントは、notestockで公開設定になっていません。
@sublimer Nelson Coffee Roasterは、仙台にあるコーヒー豆屋さんで、Pawooがメイン。マストドンユーザーによく知られていて、通販で多くの人が利用しています。ここのコーヒー豆は美味しいです。
http://nelsonbeans.com/
三上洋さんはmstdn.jpアカウントがメインのジャーナリスト。
https://ja.wikipedia.org/wiki/%E4%B8%89%E4%B8%8A%E6%B4%8B
艦これ好きでいつもコメダにいるダメな感じのおじさんキャラでありながら、Twitterやマストドンの住人で界隈に詳しく、記事を書いたりテレビに映っているメディアの人でもある。偉ぶらず、いじらせてくれる、愛されキャラ。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird WebUIで、単独で絵文字を投稿すると拡大される奴(はんどんから拝借)を適用してあります。クライアントアプリでは、 tootoiseでも同様になります。
#fedibird のハッシュタグタイムラインの取得を高速化しました。 #rssfeed とか #news 、 #frfr #abyss_fun などの激重タグが、他のタグと同様の速度で表示されます。
……まぁ、普通に見えるだけなので、困っていなかった人は、特に嬉しくないかもしれません……。
(ブロックしまくっている人は、取得するハッシュタグ件数を絞り込んだ副作用で、ブロックしている人の投稿を取り除くことで取得データが空になってしまうことがあり、正しく表示できない場合があります)
ごち鯖も日に日に gochisou_photo タグが激重になっていくから、高速化しないとヤバイんだけど、現在の実装はあまりおすすめできないにょろ〜。
(なので、本家にはプルリクしてない)
副作用のないスマートな実装にせねば……。
ハッシュタグタイムラインの取得クエリが遅いのは、該当のハッシュタグが使われている件数が一定以上多い場合にwork_memを超えてしまい、Bitmap Index Scanした後にexactではなくlossyで処理されて、Bitmap Heap Scan のRecheckが走ってしまうため。
何を言っているかわからないと思うのでw、詳しい人が説明してくれてる記事をみて……。
https://taityo-diary.hatenablog.jp/entry/2018/07/07/071928
work_memはそうそう大きくできないので、frfrとかabyss_fun、theboss_techのような件数の多いタグに対応するのは難しい。
んで、私が今回とったアプローチは、通常は最後に行うページング用のパラメータを、事前にハッシュタグを抽出する際に適用して処理対象件数を減らすというもの。とりあえず200件だけ取得してあとは無視するようにしたので、取得した200件がロック対象だった場合にタイムラインそれ以上遡れないという問題がある。
まぁ何にしても快適にはなった。
ただ、ちょっとこれを公式にぶち込むのはあんまりなので、もっと洗練させたい。
はんどんのコミットはこれね。
鯖缶陣は、下の二つを設定画面のカスタムCSSに書けば動くよ。
https://github.com/tootsuite/mastodon/commit/50e1a18f00d5af8a664cf9e100bc369d2b117d4d
Thanks! @highemerly
@momongachan 青い鳥おおきい……
:only-child だから、リンクになる要素(aタグ)とか他の兄弟要素がなければヒットするのかな……。
あと、アイコンを押す(アクティブにする)と、とても大きく表示されるよw
このアカウントは、notestockで公開設定になっていません。
@noel カレーboost bot です、こんにちは!
毎食カレーでもいいよね。いろんなもの食べたいけど、カレーはいつでもOK。
「き」って入れると「霧島ひなた」ってサジェストしてくれるATOKと暮らしているよ。「きん」は金と勤労感謝の日だね。
近所のフードコートにオムライスやさんが入っていた時は、ちょこちょこ食べに行けて幸せだったなぁ。メッチャ太るけどw
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
以下のURLでもくもく会やるので皆さんのご参加お待ちしてまーす。
もくもく会会場:
https://zoom.us/j/5582500093
@Cutls @eniehack @eniehack @Yohei_Zuho @h12o @mimikun @ijs01140
@noellabo @204504bySE @kyuizu
お疲れ様です。この投稿は意図的にpublicで投稿しております。connpass( https://connpass.com/event/165550/ )に参加登録していない方でもZoomに遊びに来ていらっしゃった方にもお送りしています。
第1回分散SNS萬本2もくもく会にいらっしゃってありがとうございました!内容としてはもくもく会というよりはインタラクティブなセミナーになっていましたがw
以下のURLに議事録が書いてあります。
https://www.evernote.com/shard/s197/sh/39ea3160-e7dc-4c01-8930-2c86b88425d5/d38532869d808cc34c38b33e8fa2bff1
また、第2回について本当は今週やりたかったのですが、色々なアレそれで僕がかなりすり減ってしまってて今週やるエネルギーが尽きてしまったので、来週に回させてください。
次回は決め打ちして腹くくってやります。
**3/5(木)21時から23時まで**
行います!ふるってお越しくださいまし。
趣旨としては、リモート会議室にあつまって各自がやりたいことやって、終わりあたりで進捗を報告してえらいっして終わる流れです。
もくもく会会場:
https://zoom.us/j/5582500093
このアカウントは、notestockで公開設定になっていません。
@syuilo さすがや。
多くの会社は、有給をなるべく出したくないので、半年後から10日っていうのが普通だからねー。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ねむい ねむい ねむい ねむい
ねむい ねむい ねむい ねむい
テラねむい
テラねむい
ねむいので早く寝たい
(当時よく聴いていた。ねむい)
6人の初音ミクにオリジナル曲を歌わせてみた
https://www.nicovideo.jp/watch/sm1187304
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ちなみに日中のにゃーんは、Illustratorのデータに潜んでいた不具合で、カット機の動作がおかしくて、ヘンな製品が出来てしまった件についてである。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Pleroma 2.0リリースを目前に控えてFediverse各地はお祭り騒ぎなのですが(それほどでもない)、とりあえず目に見える変更点としてMisskeyと互換性のある絵文字リアクションがあります。楽しみですね! #pleroma
(画像:のえろまの投稿に、のえすきーからのリアクションがついている様子)
のえろま(Pleroma 2.0相当)
https://pleroma.noellabo.jp
のえすきー(Misskey v12.21.0)
https://misskey.noellabo.jp
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@Rano_Zy ハスラムがすぐに突出して勝手に死ぬ方がよほど迷惑でしたね。
よく考えると酷いゲームだった気がしますが、思い出は美しいw
@aqz ウチもFedibird同等機能を持っているサーバ(ふるどん、qoto.org、DTP-Mstdn.jpなど)から、同じようにfedibird.comタイムラインが見えるんですが、要するに公開投稿は外から見えているので、LTLが見えてないと思い込まない方がいいですよ、というお話です。この話をうけて。
https://misskey.io/notes/84kg4j24ap
実際にこれが問題になるか、という視点で言うと、外から見える分にはほとんど影響がないな、という評価です。この件は別途書きます。
Fedibirdやmisskey.ioのように、LTLを無効にしているサーバがいくつか存在します。
ただし、これらのサーバで公開で行った投稿は、外部のサーバからドメインをキーにしてフィルタリングすることで、まるでLTLが見えているように再現することが可能です。
FTLが有効であれば、サーバ内部からもクライアントアプリなどで再現できます。
fedibird.comの場合、リレーに入っているため、外部からほぼ完全なLTLを再現できます。
misskey.ioの場合は、リレーに入ってはいないため、観測するサーバからフォローされているユーザーだけになります。
公開の投稿については、見えていないつもりにならないことが重要です。
では、それではLTLを廃止した意味がなくなるかといえば、そうでもありません。
わざわざ外部からLTL相当のものを観測する人は、サーバ所属ユーザーのごく一部と、外部のユーザーだけです。
LTLについて問題になることの大部分は、ローカルのユーザーのほぼ全員がそれを見ている・すぐに見ることができるというところから発生するためです。
これ微妙にマズイ挙動だな……。
私(1) -> 相手(2) -> 私(3) -> 相手(4) -> 私(5)
ってツリーで、私(1)を削除したら、相手(2)と相手(4)が消えて、私(3)と私(5)が残っている。
私がmisskeyユーザーなら全部綺麗に消えるから問題にならないのかもしれんけど、misskeyと外部のやりとりだとmisskey側だけが消える。
相手のリプライだけ消えるの、なんか邪悪じゃない?
このアカウントは、notestockで公開設定になっていません。
@eniehack 現行のpub-relay 2.0をフォークしたリポジトリ作って、そっちにあらためてまとめ直しました。
pub-relay 2.0
https://github.com/noellabo/pub-relay
selective-relay 2.0(ハッシュタグリレー)
https://github.com/dtp-mstdn-jp/selective-relay
ベースは同じですが、途中から別物に分岐しています。後者はコードが汚く複雑なので、参考にとどめた方が良いかと思います……。
#ハッシュタグリレー のリレー制御エージェントに、サーバ管理者用のコマンドが追加されます。
Mastodonの場合、サイト設定の連絡先ユーザー名に指定されているアカウント、PleromaとMisskeyの場合はAdminになっているアカウントを管理者として登録できます。
relayctlにauthコマンドを送信してください。
このアカウントは、notestockで公開設定になっていません。
Mastodonが配送に失敗したジョブに対処する仕組み
https://noellabo.qrunch.io/entries/oq3sL7PQhFMrc6Bb
Mastodonがジョブの再試行に用いている、Sidekiq、Stoplight、DeliveryFailureTrackerについて、ざっくり説明した記事を書きました。
基礎知識として知っておくと良い内容かと思います。