Impact of preseeded snap packages on boot time of the live session

snapd
1

For testing, I’ve been looking at the impact of preseeding snap packages on boot speed of the live session.

The tests have been executed on VMs for convenience, disk files are on an SSD and running the test was the only activity of the host. The VMs have network connectivity and the ISO to run without snap is the same ISO than Ubuntu Bionic Desktop from which I removed snapd and preseeded snap packages.

Preinstalled snaps are:

  • Gnome 3.26
  • Gnome Calculator
  • Gnome Character
  • Gnome Logs
  • Gnome System monitor

The live cd has been instrumented with bootchart to collect boot data.

I did a blank boot, to eliminate the impact of loading the ISO in disk cache then executed 5 runs. Boot time is calculated when gnome-shell starts.

Here are the results:

Default Ubuntu Bionic Desktop ISO
Avg time to boot (seconds): 57.146 (58.74, 54.13, 57.63, 59.42, 55.81)

bootchart-bionic-desktop-default
bootchart-bionic-desktop-default2957×5664 682 KB

ISO w/o snaps
Avg time to boot (seconds): 52.302 (52.23, 51.3, 51.4, 55.1, 51.48)

bootchart-bionic-desktop-nosnap
bootchart-bionic-desktop-nosnap2631×5120 610 KB

Preseeding snaps increases boot time by 9.3%

Looking at the top 3 CPU consumers we find unsquashfs and snapd. snapd and snap are in the top 3 IO consumers.

I moved the snaps from the filesystem squashfs to the CD filesystem to check if having a squashfs inside a squashfs had an impact. But the performance gain is less than 2s.

So it seems that uncompressing the snaps on the ISO would improve boot time by removing the overhead generated by unsquashfs.

This test is focused on snaps but it is of course not the only factor that impacts boot speed of Ubuntu.

1 Like
2

This isn’t a very thought-through comment, but why is unsquashfs running at all? Everything should be mounted via the kernel squashfs driver, not being unsquashfsed surely?

3

I’d be interested to see the same test repeated with ISO on USB stick rather than loading (and reading from) your fast SSD. Booting from USB is a real world application of the Ubuntu installer for many people doing a clean install.

1 Like
4

we always di extract meta/snap.yaml with unsquashfs (the tool) before mounting,

but we have also grown more validation code recently before mounting (I think) that also uses unsquashfs (the tool) (I think), @chipaca should know more

5

Yes, the validation code also uses unsquashfs, as it runs before we consider the snap to be good enough for mounting. It does a single pass of the file, though, so for a typical snap there should be just those two invocations (I think gadget snaps have more yaml files thare are extracted like snap.yaml is, but they shouldn’t be an issue here).

We could switch the validation to run post-mount, if that’s deemed acceptable, but I don’t know if it’d help.

6

The snapd/unsquashfs one doesn’t surprise me too much (although I’m surprised unsquashfs uses that much CPU), but the one that is surprising is snap. Is there a way of having the arguments of the command and not just the command?

7

Here are the commands with their arguments:

:unsquashfs -i -d /tmp/read-file837795685/unpack /var/lib/snapd/seed/snaps/core_4206.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/core_4206.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/core_4206.snap 
:unsquashfs -i -d /tmp/read-file614141824/unpack /var/lib/snapd/seed/snaps/gnome-3-26-1604_53.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/gnome-3-26-1604_53.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/gnome-3-26-1604_53.snap 
:unsquashfs -i -d /tmp/read-file885976799/unpack /var/lib/snapd/seed/snaps/gnome-calculator_75.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/gnome-calculator_75.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/gnome-calculator_75.snap 
:unsquashfs -i -d /tmp/read-file358604466/unpack /var/lib/snapd/seed/snaps/gnome-characters_50.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/gnome-characters_50.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/gnome-characters_50.snap 
:unsquashfs -i -d /tmp/read-file521843305/unpack /var/lib/snapd/seed/snaps/gnome-logs_23.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/gnome-logs_23.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/gnome-logs_23.snap 
:unsquashfs -i -d /tmp/read-file760249012/unpack /var/lib/snapd/seed/snaps/gnome-system-monitor_31.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/gnome-system-monitor_31.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/gnome-system-monitor_31.snap 
:unsquashfs -i -d /tmp/read-file654988294/unpack /var/lib/snapd/seed/snaps/core_4206.snap meta/snap.yaml 
:unsquashfs -no-progress -dest _ -l /var/lib/snapd/seed/snaps/core_4206.snap meta/hooks 
:unsquashfs -no-progress -dest . -ll /var/lib/snapd/seed/snaps/core_4206.snap
8

Sorry, I should’ve been clearer: the snap command that’s using so much io, that’s the one I’d like to know about.

Thank you!