@ganyo ぺーーーい!
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@tadd 弊ぼっちはメモリ512MBにぎゅうぎゅうにプロセスを詰めてるのでJITは無しです。YJITだとメモリ2倍くらい必要になる感じなんですよね…。
ローカルから発言してるのは僕だけで、リモートからみた使い心地はリモートへの配達の遅延に依存してると思うんだけど、リモートへん配達の遅延はネットワークがボトルネックでだいたい1秒/送信先に決まっちゃってて、JITするよりメモリを節約してスレッドを増やす方がいい感じになっちゃってます。
@tadd なるほど~。そのうち挑戦してみたいもんです。
あ、そういえばRubyを3.1から3.2に上げてメモリのふるまいが変わったようで、何時間かに1度なにもかも遅くなる現象が起きたのは、full GCを抑制するようにしきい値を上げて対応できました。Herokuなのでプロセスの寿命は1日ちょっとしかなく、その中で最適化できるのは悪くなさそうです。
@tadd GCの件はバグではないと思っています。
遅くなる現象はプロセスの起動からしばらくしてからしか起きず、応答時間以外にはScoutで監視してるRubyプロセスのみのメモリ利用量くらいしか同時に変化のあるメトリクスをみつけられませんでした。この現象の頻度はRUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTORとRUBY_GC_OLDMALLOC_LIMITをgc.cの2倍に設定して下り、RUBY_GC_OLDMALLOC_LIMITをさらに2倍(デフォルトの4倍)にして出なくなりました。なので、full GCで遅くなっていたと解釈しています。
弊ぼっちは恒常的にスワップを使っているのでGCによる速度の低下の影響が十分メモリのある環境と比べて非常に大きいと推測されるので、一般的に対処の必要な現象ではないと思っています。
Ruby 3.1と3.2の違いを把握できてるわけではないので、もし確認するとすれば、3.1でRUBY_GC_OLDMALLOC_LIMITを小さくして同じ現象が見られるか試してみたい気がします。
@tadd それより!RailsがRedisから読もうとしたオブジェクトがundefined method `fetch_value' for nil:NilClassを起こしちゃうのはたぶん3.2特有でなんとかしたいでつ!
https://github.com/mastodon/mastodon/issues/23644
@tadd Redisクライアントは上げかけてパフォーマンスが出なくて下げました(今にして思うとGCが原因だったのかもしれません)。Rubyだけ3.1に下げて再現するか試したいんですけど、まだその機会がありません。そもそもなかなか再現してくれないんですよねートホホ
このアカウントは、notestockで公開設定になっていません。
@tadd ありがとうございました〜。どれも再現性が高そうで、単体では無関係そうな感じでした。
このエラーは弊ぼっちでは月に1度くらい(たぶん正確にはキャッシュされたStatus/トゥート 1個)しか起きていません…とか書いてると、Redisに書く側のrace conditionとかに原因があるのかもしれないと思えてきました。
uedder's blog – Linus Torvalds 氏の理想の git 運用と GitHub
https://blog.uedder.com/linus_torvalds_complains_about_github_merges.html
あー
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする
https://zenn.dev/mizchi/articles/yarn-v1-to-v3
このアカウントは、notestockで公開設定になっていません。