Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
installer memory consumption: where to look next

installer memory consumption: where to look next

Followup to "Collect memory usage data"

Part of

search strings

ruby memory

ruby memory profiling

explore the garbage collection (GC) time delay

RSS drops gradually in 90s after GC.start is called

Related, check why new validator seems to consume 8MiB AFTER it has finished


Substitute agents written in Perl

Extension of the above: do not use the current Perl-based yast2-users

remove ramdisk data

the RW data created at installation time (we did it for libzypp, then backtracked a bit whenit crashed)

remove squashfs data

The RO data created before installation starts. Also clarify how much of inst memory it takes - some of it remains compressed (squashfs), initrd is uncompressed.

"root" can be reduced to 70% if we remove the GUI stuff (Qt, X, TTF fonts) What if we told installation-images to build a root-nox that would only support TUI installation? The uncompressed size would be reduced by 30%.

"common" has 7 MB unpacked in /usr/lib64/python3.6/__pycache__

/suse/snwint/Export/instsys_sizes_now_and_then.txt This is kernel + initrd + root + common (all the images loaded to start yast) (85MiB xz compressed, 121MiB uncompressed cpio archive)

initrd contains squashfs'd parts/00_lib, parts/01_usr

850 KB /etc/services, can be reduced to 229 KB with minification:

sed 's/#.*//g;s/  */ /g;/^$/d' etc/services | wc

make tooling to inspect the size data again in the future

(a script to be pointed to a CD FS and making a du -a | sort -n over the packaged filesystems)

memusage is in glibc-tools.rpm

It is a simple LD_PRELOAD'ed profiler, can detect peaks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment