What limits how fast we can install machines

February 27, 2015

Every so often I read about people talking about how fast they can get new machines installed and operational, generally in the context of how some system management framework or another accelerates the whole process. This has always kind of amused me, not because our install process is particularly fast but instead because of why it's not so fast:

The limit on how fast we install machines is how fast they can unpack packages to the local disk.

That's what takes almost all of the time; fetching (from a local mirror or the install media) and then unpacking a variegated pile of Ubuntu packages. A good part of this is the media speed of the install media, some of this is write speed to the system's disks, and some of this is all of the fiddling around that dpkg does in the process of installing packages, running postinstall scripts, and so on. The same thing is true of installing CentOS machines, OmniOS machines, and so on; almost all of the time is in the system installer and packaging system. What framework we wrap around this doesn't matter because we spend almost no time in said framework or doing things by hand.

The immediate corollary to this is that the only way to make any of our installs go much faster would be to do less work, ranging from installing fewer packages to drastic approaches where we reduce our 'package installs' towards 'unpack a tarball' (which would minimize package manager overhead). There are probably ways to do approach this, but again they have relatively little to do with what system install framework we use.

(I think part of the slowness is simply package manager overhead instead of raw disk IO speed limits. But this is inescapable unless we somehow jettison the package manager entirely.)

Sidebar: an illustration of how media speeds matter

Over time I've observed that both installs in my testing virtual machines and installs using the virtual DVDs provided by many KVM over IP management processors are clearly faster than installs done from real physical DVDs plugged into the machine. I've always assumed that this is because reading a DVD image from my local disk is faster than doing it from a real DVD drive (even including any KVM over IP virtual device network overhead).


Comments on this page:

By Albert at 2015-02-27 03:05:22:

Not necessarily. Today most deployments are VMs created from some sort of image or template, so almost everything is set up already, and the config management tools just apply the finishing touches. In situations where there are tens or hundreds of equal machines (web farms etc) It's not unrealistic to have a new machine or a bunch of them up and running in 5 minutes or less.

Of course, not all environments are alike.

By cks at 2015-02-27 12:29:26:

I don't think of cloning VM images as 'installing' a system. In that case you have a preinstalled system that you're just customizing; effectively you've already done most or all of the unpacking, writing stuff to the local disk, and package setup.

(This is a great way to speed up the whole process of bringing up a new machine, of course.)

By Timmy at 2015-03-03 16:13:20:

I have always wondered about this. There must be a faster way to do installs/updates. I (often) would not mind if the system took 90%+ of the RAM if it meant I could do other things faster.

Heavy usage of RAM Disks and only write the finished product to disk? Maybe there are hidden tuneables?

Written on 27 February 2015.
« My current issues with systemd's networkd in Fedora 21
Email from generic word domains is usually advance fee fraud spam »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Feb 27 01:24:39 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.