このアカウントは、notestockで公開設定になっていません。

WebというかUIに特化してる感じはある。カラープロファイルは一応埋め込めるけども、まあ使わない

一方でWebPが弱いのは最大ピクセルサイズ。268MPしかない。10年後のデジカメ画像は保存できなさそう。

WebPの良いところは非可逆で透過できるとこだよね。PNGじゃ無理なやつ

1800ほど溜まった再試行を消化し終わりました。復旧完了？

このアカウントは、notestockで公開設定になっていません。

@weep ありがとうございます。試しにロード部分でURLを変更してみます。

@weep 表示にWeb技術を使ってないクライアントだとSVGサポートは割とハードルが高いので、テストできるタンスがあると助かります。

@weep いまSVG画像を使ってるインスタンスは何がありますか？

Web技術なしでSVG表示は割とめんどくさいやつだ

@mayaeh paperclipだけでなくオブジェクトストレージの制限もあるだろうから、分割は出来た方がいいでしょうね。app/model/backup.rb が複数のファイルを持てるようにして関連部分を全部ガッツリ書き換える重いやつになりそうですけど。

@mayaeh むしろ1ファイルのアーカイブにしてしまうのが問題なので、アーカイブを分割した複数のファイルをやりとりできるようにするべきでは。

「メディアサーバが落ちててもマストドンの応答性が下がらないようにする」だけなら手動対応で別にいいか、と思ったので突飛なことは言わない。これを自動化するためだけに色々やるのは手間に見合わない。

素の状態でも待機した上で必ず失敗するのなら、即座に失敗させた方がマシ

根本的には、IDを発行してからファイルアップロードが終わるまでDBトランザクションを握りっぱなしのpaperclipが悪いと思う。「IDに合わせたファイル名を持つ」必然性が全く感じられない。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

@mayaeh 私の今回のは不安定じゃなくて全く接続できないので、connect()を即座に失敗させるようにしてストレージ側が復旧したら元の設定に戻す方が負荷が少ないと思います。タイムアウト値を設定可能にするPRも書いてみましたが https://github.com/tootsuite/mastodon/pull/12459/files そもそもRubyのnet/httpのopen_timeoutは DNS名前解決の待ち時間には効かないのですよね…。

@mayaeh 情報ありがとうございます。

@hanage999 情報ありがとうございます。 ただ、私の今回のは不安定ではなく全く接続できないので、connect()を即座に失敗させる対応の方が適切なのでした。

残念ながら焼け石に水だった。defaultキューが詰まるだけでなくDBのトランザクションを開きっぱなしにするのでpgbouncerのバックエンドコネクションを使い切りサービス全体が応答しなくなる。仕方ないので .env.production を変更してS3_ENDPOINT=https://nonexistent.uso など存在しないホストを指定した。メディアサーバへの書き込みが即座にエラーとなり、他の部分には影響しなくなる。

マストドン側のエラーログ。 https://gist.github.com/tateisu/0286a760e0f1ece355acb11d041b53d9 defaultキューが詰まるのヤバイ。タイムアウトは https://github.com/tootsuite/mastodon/blob/master/config/initializers/paperclip.rb で http_open_timeout: 5 とハードコードされている。 とりあえずdefaultキューを捌くsidekiqを増やす。 docker-compose up -d --scale sidekiq_default=2

このアカウントは、notestockで公開設定になっていません。

DigitalOcean Spaces のインシデントがあった https://status.digitalocean.com/incidents/0ftrmj4l3z1m

LinkCrawlWorkerがSeahorse::Client::NetworkingError: execution expired を出してて、スタックとレース見るとメディアサーバへのデータ保存でconnectがタイムアウトしてるぽい

朝7時ごろからこのサーバの負荷が上がってますね。