Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RBSのメモリ使用量改善への道
Search
pocke
July 27, 2024
Technology
1
19
RBSのメモリ使用量改善への道
pocke
July 27, 2024
Tweet
Share
More Decks by pocke
See All by pocke
The path to memory reduction in RBS
pocke
0
21
Community-driven RBS repository
pocke
2
1.1k
Active Record Query Quiz
pocke
1
1.3k
Let's write RBS!
pocke
1
4.7k
RBS and Rails, Present and Future
pocke
1
1.3k
The newsletter of RBS updates
pocke
1
3.3k
kwargs warning → Sentry
pocke
0
310
Ruboty and SKI
pocke
0
180
Regression test for RuboCop
pocke
0
210
Other Decks in Technology
See All in Technology
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
880
役員・マネージャー・著者・エンジニアそれぞれの立場から見たAWS認定資格
nrinetcom
PRO
5
6.9k
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
250
DeepSeekとは?何がいいの? - Databricksと学ぶDeepSeek! 〜これからのLLMに備えよ!〜
taka_aki
2
210
【Snowflake九州ユーザー会#2】BigQueryとSnowflakeを比較してそれぞれの良し悪しを掴む / BigQuery vs Snowflake: Pros & Cons
civitaspo
5
1.6k
エンジニアのキャリアパスと、 その中で自分が大切にしていること
noteinc
3
3.1k
OCI Success Journey OCIの何が評価されてる?疑問に答える事例セミナー(2025年2月実施)
oracle4engineer
PRO
2
280
AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering
yoshidashingo
9
4.4k
AIエージェント元年@日本生成AIユーザ会
shukob
1
290
エンジニアリング 💰Moneyジャー / Engineering Money-ger
kenchan
1
110
Ruby on Railsで持続可能な開発を行うために取り組んでいること
am1157154
3
190
完璧を捨てろ! “攻め”のQAがもたらすスピードと革新/20250306 Hiroki Hachisuka
shift_evolve
0
170
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
99
5.4k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Typedesign – Prime Four
hannesfritz
41
2.5k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
GitHub's CSS Performance
jonrohan
1030
460k
Writing Fast Ruby
sferik
628
61k
Become a Pro
speakerdeck
PRO
26
5.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
590
Navigating Team Friction
lara
183
15k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
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でバグ報告をした りしていい経験になった