神楽坂しえる @Clworld@md.ggtea.org

ProcessFeedServiceがリファクタされた結果読む時にクラスをたらい回しにされてる
After ProcessFeedService is refactored, I'm sent around many classes when I read ProcessFeedService...

@unarist 前にこのせいで私がIPv6onlyインスタンスのtootをBoostすると私の発言としてIPv6非対応インスタンスに飛んでいくって問題が発生していたはず。

@unarist そうじゃないんです。一旦statusが作成された後の処理が失敗した時にrollbackされて元のstatusが削除されないと再実行された時にこのstatusは既に存在するのでokって判定になってDBから取ってくるだけで処理が成功してしまうのです。

@unarist transaction無いと致命的に駄目じゃないです？駄目なのを直すためにtransaction入れたんですし。

@unarist 😴💤

@unarist 私の認識だとそう…🤔 今深く考えると寝れなくなりそうなのでねる…

@unarist streamingの方は画像取得まで行われた後にpush処理のsidekiqが呼ばれるから大丈夫な認識🤔(media_attachmentは)
RESTはstatusレコードが出来ると読み込まれてしまうけど前にtransactionが入ってるしなんとかなりそうな気もする…🤔？？？

@unarist REST API ?🤔

@Clworld When toot is on WebUI, it must be anything is ready(except OpenGraph). So, transcoding image task cannot be delayed... and transcoding task is called synchronously from various workers.

Wish: delayed paperclip transcode😩

@Naf なるほどー
fnyaがディスク使用3.5Gなのでsetup時に最小限にしたのは多少効果があるっぽくて嬉しい。メモリはもう少し動いた後の状態で聞いた方が良かった予感…🤔 64bitです？

@Naf free -m と df -lh どのくらいです？(個人的興味😅 )

@unarist メモリを大量に使うバグがあるとかないとか直ったとかなんかいろいろ見つかって分からない(…😑 )

@unarist 当然のように画像ダウンロードとトランスコードもある…😅

@Clworld 向こうからデータを取ってくる処理がまずそうって考えるとHTTPかpaperclip...?🤔

@Clworld
memusage of each queues..(at md.ggtea.org)
defaut&pull queue consumes lots of memory..why?
default: 574MB(20 thread)
mailers: 140MB(5 thread)
pull: 477MB(10 thread)
push: 230MB(20 thread)

xanacさんのやつインスタンスそのものが創作物っぽいしただしい

@Clworld
容疑者1: ActiveRecord
容疑者2: paperclip + Imagemagick
容疑者3: HTTPリクエストで取得する系処理
容疑者4: XML

しかし冷静に考えるとMastdonのSidekiq/pumaのメモリ使用量多すぎません？だれがこんなに使っているのです？