Rubyのextendであったこわい話

Transcript

1. extendはこわい
2. 自己紹介 名前：藤田 将志 所属：DIGGLE株式会社 自己紹介： • Ruby on Rails や React などを使用した、管理会計のためのtoBのSaasを開発し ています。 ◦ 弊社は2023、2024Ruby会議のスポンサーで、とても Rubyにお世話になっています 😊 • 兵庫県神戸市出身で、とても関西が恋しいです
3. 事の始まり • Userの一覧を、誕生日（birthday）順に取得・処理する際のメモリ使用量を改善す るために、バッチ処理にしたい • find_eachはID順のバッチ処理のため、使えない 再現用コード https://github.com/fujitamasashi255/ruby-extend-memory-test バージョン • ruby 3.3.4 • Rails 7.1.3.4
4. 事の始まり あまり深く考えずに、以下のように実装してみた →メモリ使用量が改善されない😭 （本発表とは関係ありませんが、 Userモデルのクラスメソッドとして定義することで、問題は解決しました。） • FindEachInOrder モジュールを作成 ◦ find_each_in_order メソッド ▪ order を含む場合に、 find_each と同じように処 理を実行できる • FindEachInOrder モジュールを User::ActiveRecord_Relation オブジェクトにextendする
5. 事の始まり 調査の末、以下のコードでも同じ感じになることがわかった。 extendすると、find_each のメモリ使用量が増加する、、、
6. メモリ使用量を計測 extendあり • 10万件のUserレコード • 10000件ごとにrssを取得 extendなし
7. profilerを実行してみる heap-profilerを実行してみる extendあり extendなし
8. heap-profiler 実行結果を細かく見ると extendあり Total allocated: 172.37 MB (1342040 objects) Total retained: 9.11 MB (34481 objects) allocated objects by file ----------------------------------- 6637 activerecord-7.1.3.4/lib/active_record/relation/query_methods.rb 4148 activerecord-7.1.3.4/lib/active_record/relation.rb 2001 activerecord-7.1.3.4/lib/active_record/relation/batches.rb 815 <internal:kernel> 578 activerecord-7.1.3.4/lib/active_record/relation/delegation.rb extendなし Total allocated: 171.48 MB (1334457 objects) Total retained: 9.10 MB (34108 objects) allocated objects by file ----------------------------------- 2988 activerecord-7.1.3.4/lib/active_record/relation/query_methods.rb 1230 activerecord-7.1.3.4/lib/active_record/relation.rb 1701 activerecord-7.1.3.4/lib/active_record/relation/batches.rb なし <internal:kernel> 476 activerecord-7.1.3.4/lib/active_record/relation/delegation.rb
9. なんとなくわかったこと1 allocated memory by location ----------------------------------- 645.08 kB <internal:kernel>:48 extendありのケースでは、<internal:kernel>:48 の実行によっ て、オブジェクトが生成されている ruby/kernel.rb ActiveRecord::QueryMethods#where ActiveRecord::Batches#find_each 内では、relation.whereによって、 User::ActiveRecord_Relation オブジェクトのcloneが発生する → clone 生成物ごとに異なる singleton_class が生成される → 多くのオブジェクトが作成される ActiveRecord::SpawnMethods#spawn
10. なんとなくわかったこと1 rb_obj_clone_setup rb_singleton_class_clone_and_attach singleton_class が attach されていな い場合、clone はスキップされる cloneの際、singleton_classもcloneが作成される
11. なんとなくわかったこと2 extendありのケースでは、 callcache がより多く生成される。 callcache: インラインメソッドキャッシュ のためのオブジェクト allocated objects by class ----------------------------------- 11652 <callcache> (IMEMO) ・・・extendあり 4275 <callcache> (IMEMO) ・・・extendなし インラインメソッドキャッシュ ： 笹田 耕一『プログラム言語 Ruby におけるメソッド キャッシング手法の検討』 より引用 メソッドディスパッチ命令 send のオペランドにメ ソッ ドキャッシュ用のオペランドを用意し，その領域に レ シーバのクラスとメソッド定義情報を格納する．ディス パッチ時，レシーバのクラスをキャッシュしたクラス と 比較し，等しければヒットとする． rb_callcache
12. なんとなくわかったこと2 WEB+DB PRESS Vol.122 笹田 耕一「Rubyのウラガワ」 P.143より引用 注16 クラスが異なるとメソッド探索が失敗します。つまり、同 じクラスのオブジェクト でも、それぞれが特異クラスを 持っているとクラスが異なると判定され、キャッ シュが効 きません。性能が必要な場面では特異クラスを作らないよ うにする とよいかもしれません。
13. なんとなくわかったこと2（補足） 【参考】その他、extendによるメモリ使用量への悪影響 • Call Cache for singleton methods can lead to "memory leaks" ◦ 引用：Eregon (Benoit Daloze) さんのコメント As a general note, creating a singleton class is not cheap, this should only be used for class objects (which always have one) and for a few rare global objects where it's convenient. Using Object#extend objects often/on the fast path is just "making programs slow and uncached". （訳）一般的な注意点として、シングルトンクラスの作成はコストが高いので、常にシングルトンクラスを持つクラ スオブジェクトや、便宜上必要な少数のグローバルオブジェクトにのみ使用すべきです。 `Object#extend` を頻 繁に使用したり、高速パスで使用したりすることは、単に「プログラムを遅くし、キャッシュを効かなくする」ことに なります。 • PoC: Cache Extended Collection Proxies
14. わからないこと allocated objects by location ----------------------------------- 606 activerecord-7.1.3.4/lib/active_record/relation/query_methods.rb:943 extendありの場合 なぜ、extendがあると、build_where_clause で より多くのオブジェクトが生成されるのか？ heap-profiler の見方の問題？？ ActiveRecodd::QueryMethods#build_where_clause
15. これから知りたいこと まとめ extendを使用すると、メモリ使用量でこわい思いをした → extendの使用ってこんなに気をつかう必要があるのか・・・ heap-profiler を見るコツみたいなのがあれば知りたい
16. ありがとうございました！