Ruby 2.1+ allows tracing object allocations, see more details in this article.
I enabled it and dumped the Ruby memory usage data in a SLES12-SP2 Beta3 installation
- Tested in a x86_64 VirtualBox VM
- In a graphical (Qt) installation
- The dump was created at the installation proposal when all data needed for installation were collected.
- I just left the defaults without going into details, loading/displaying details could allocate some more objects
- The registration has been skipped
- The dump obviously contains the data only from the Ruby YaST part, it does not include the other parts (e.g. SCR agents, Perl modules) or external libraries (libzypp, Qt, X11,...)
-
File
memory_dump.json.xz
contains the collected memory data, rununxz memory_dump.json.xz
to uncompress it before analyzing it. -
File
dump_collector.rb
contains a simple Ruby script which reads a dump file in JSON format and prints the places which create the largest objects (in total).
Just run./dump_collector.rb memory_dump.json
command.
Feel free to modify the script to collect a different statistics.
A quick scan found out that the place which consumes most memory is
/usr/share/YaST2/lib/installation/ssh_config_file.rb:45:STRING: count: 4, total size: 274056
which loads the SSH keys and configuration from the previous installation and needs about 270kB memory.
The question is we can optimize it better, the SSH keys actually need to be stored somewhere as the target partition will be reformatted...
The only optimization could be probably possible when the user selects to not copy the keys. In that case we could drop the loaded keys when the installation starts. But that's not the default so this improvement would actually help only in some cases...
You can collect a different statistics from the data, e.g. the place which creates the most objects, which methods, check the object "age" (the GC generation value), etc...
The article link is 404 but will work if the trailing slash is removed: Ruby 2.1: objspace.so