Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
RBSのメモリ使用量改善への道
Search
pocke
July 27, 2024
Technology
91
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
RBSのメモリ使用量改善への道
pocke
July 27, 2024
More Decks by pocke
See All by pocke
New "Type" system on PicoRuby
pocke
2
2k
プログラミングで遊ぶ
pocke
0
160
Witchcraft for Memory
pocke
1
6.8k
The path to memory reduction in RBS
pocke
0
100
Community-driven RBS repository
pocke
2
1.8k
Active Record Query Quiz
pocke
1
1.7k
Let's write RBS!
pocke
1
5.5k
RBS and Rails, Present and Future
pocke
1
1.4k
The newsletter of RBS updates
pocke
1
3.6k
Other Decks in Technology
See All in Technology
Snapshot Testing in Practice: Predictable and Reliable SwiftUI Views
fespinoza
0
160
FactoryBotアンチパターン / factory_bot anti-patterns
toshimaru
0
140
ハードウェアコンペでもAI駆動開発が進んでいる話
iotengineer22
1
570
自作バイナリを動かす「入口」8選
puhitaku
1
1.1k
生成AIで高い生産性を求められて、 悩み、乗り越えた話
mot_techtalk
2
130
BedrockとLambdaで作る リアルタイム進行型推理ゲーム
kawametho
0
210
OpenSharing について熱く語る〜AI アセットの共有について〜
kameitomohiro
0
240
[2026-09-30]ロックンロールは鳴り止まないっ - 信頼性かまってちゃん - 「データ駆動を投げ捨ててまで。」追いかける信頼性改善に向けた取り組みの話
tosite
0
210
「事実」を「計測」して、「解釈」する 〜AWS Lambdaのメモリ最適解の見つけ方〜
maimyyym
0
120
並行性の問題を防げ!実践トランザクション入門
occhi
0
280
生成AIを使って「人が」考える技術 ― AI時代の人機共想と実践ノウハウ|UNITT AC2026
ishiirikie
0
570
DevelopersIO 2026 知識の地図を描く ─ オントロジーとは何か?
ishikawa_satoru
1
930
Featured
See All Featured
Done Done
chrislema
187
17k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.9k
Claude Code のすすめ
schroneko
67
230k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Faster Mobile Websites
deanohume
310
32k
SEO for Brand Visibility & Recognition
aleyda
0
4.8k
Mobile First: as difficult as doing things right
swwweet
225
10k
From π to Pie charts
rasagy
1
390
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.4k
RailsConf 2023
tenderlove
30
1.6k
Product Roadmaps are Hard
iamctodd
55
13k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
203
77k
Transcript
RBSのメモリ使用量改善 への道 岡山Ruby, Ruby on Rails勉強会 #23
誰 • Pocke • Ruby committer • RBSのメンテナ • 2020年から岡山に住んでいます
Agenda メインのトピックが2つ • ファイル数が多い時に、Steepの実行速度を改善した話 • Ruby向けのメモリプロファイラを作っている話
なぜメモリ使用量の改善が必要なのか
なぜメモリ使用量の改善が必要なのか • Steepはメモリをたくさん使う ◦ LSP Serverとしてプロセスが常駐する ◦ 1プロセスあたり 1.5GB ▪
* LSPが立ち上がっているプロジェクト数 ▪ * CPUの数(並列化するため) • Steepを広く使ってもらうにはメモリ使用量改善が必要
Steepの実行速度を改善した話
Steepの実行速度を改善した話 • Steepのメモリ使用量の改善に取り組んでいたら、その 副産物として実行速度の改善ができた ◦ メモリ使用量の改善はまだ…… • これはこれで面白かったので、紹介します • (来週この内容でブログ記事を公開するよ)
メモリのプロファイリング • SamSaffron/memory_profilerを使う • すべてのメモリの確保と、確保したまま残っているメモ リを表示してくれる
memory_profiler の結果
memory_profiler の結果 set.rbがめちゃくちゃメモリを使っている!
わかった問題 • set.rb がメモリをたくさん確保している ◦ 全体のメモリ確保の70%ぐらいがここで確保されている • これを直せれば問題が解決できるかも!
わかっていないこと • set.rb のコードがどこから呼ばれているのかが分から ない • これがわからないとSteepのどこを直したらよいのかが 分からない
Rubyの雑パッチを書いた https://gist.github.com/pocke/7499e5799856393 b930684ebb905d41c
雑パッチ • MemoryProfilerは ObjectSpace.allocation_sourcefile などを使っ ている • このメソッドが位置情報を取得するところにパッチする ◦ 取得した位置情報がset.rbならば、バックトレースを1つ遡る
雑パッチ
再度memory_profilerを実行
再度memory_profilerを実行 Steepのどこがメモリを確保しているのかわかった!
None
None
None
実行速度の問題が解決された💪 https://github.com/soutaro/steep/pull/1184 でもメモリ使用率はまだ未解決…
新しいメモリプロファイラ
今までの反省点 • メモリ使用量を改善するつもりが、実行速度の改善に なってしまっていた • memory_profilerで正しく問題を捉えられていなかっ た
今までの反省点(2) • memory_profilerで見ていた指標は「すべてのメモリ 確保」 • 一方でメモリ使用量の削減のために知りたいのは「メモ リ使用量がピークの時にメモリを使っているオブジェク ト」 • ここでずれがあった
◦ たくさん確保されてはすぐ消えるオブジェクトがノイズとなっていた
これに対するアプローチ • 長生きしたオブジェクトに絞って、メモリのプロファイ リングをできるとよいのでは • つまり、GCを生き残ったオブジェクトに注目する
メモリプロファイラを作った https://github.com/pocke/majo • GCを1回でも生き残ったオブジェクトだけを集めて集計す るプロファイラ • 一応まともに使えるので、v1.0.0をリリース済み
使ってみた感想 • 出る情報はmemory_profilerと近い ◦ しかし「長生きしたオブジェクト」しか結果に含まれないので、ノイズ がないことがわかるのが大きい ◦ 案外どれが長生きでどれが短命なのかは自明ではない • CSV出力が意外とかなり便利
◦ もしくはスプレッドシートが便利とも言える • memory_profilerに比べると若干高速 ◦ 「全オブジェクト」を対象にするmemory_profilerはかなり遅い ◦ 一方で短命オブジェクトを無視できるMajoは若干マシ
余談(1) memory_profilerのretainedを見るんじゃだめだった の? • retainedを見るにはオブジェクトを生かしておく必要が あり、memory_profilerを差し込む場所を考えるのが むずかしい… • 「メモリ使用量がピークの時」にmemory_profilerを 止めないといけない
余談(2) • https://github.com/ruby/ruby/pull/10598 ◦ RubyのMajor GCだけを止めて、Minor GCのみを動かす機能追加のPR • 最初実現方法を考えている時に、このPRも試せないかな と眺めていた
• 結果としては使わなかったけれど、PRでバグ報告をした りしていい経験になった