Installer memory usage in F19 Beta TC3

So I had a few spare cycles this morning and thought I'd look at the memory usage of the installer in F19 Beta TC3. The awesome Chris Lumens made this much easier back in 2011 by adding memory use logging functionality to anaconda. He wrote up his findings at the time - based on a Fedora 15 install - in this blog post. I ran a very similar test to Chris' using F19 Beta TC3. We both did a default package set install from a DVD image. Only difference is that I did not switch language to German in the anaconda UI, as Chris did. Here's my graph: As Chris did, I've annotated the spikes (although much more messily than he did). So, what do we see? It's a bit hard to see in this graph as I blew through the install process very quickly, but I just ran another test, and if I complete the necessary spokes and leave the UI sitting at the hub screen before actually kicking off an install, the 'background level' of anaconda itself is 329MB. In Chris' graph, this 'background level' before package installation kicks in looks like it's around 200MB. However, oldUI was very different from newUI, and most of the difference there may be accounted for by the fact that we've already fired up storage and repository configuration code at this point. The 'background level' during package installation - where the line sort of mostly sits aside from spikes - is around 590MB in my data. In Chris' F15 test, it looks like it was around 520MB-530MB (eyeballing it). So usage has increased about 60-70MB there. The spikes are as follows: A - sepolgen-ifgen running during install of policycoreutils-devel package (spikes to 796MB) B and C - both gtk-update-icon-cache, running during %posttrans I believe. See icon cache packaging guidelines. D - this whole ramp is yum's "VerifyTransaction" action, which is new since Fedora 15 (I forget which release introduced it) The shorter unlabelled spikes I haven't looked into, but they're probably update-mime-databases, like the similar small spikes in Chris' F15 run. It's rather odd that gtk-update-icon-cache runs multiple times in %posttrans, the policy seems designed to prevent this happening. From the raw data it looks like it runs three times, once at 08:29-31, once at 08:36-38, and once at 09:17. The memory usage spikes in all three cases. edit: Thanks to kalev who came up with a nifty bit of RPM magic to inspect all scripts that do gtk-update-icon-cache, it looks like this makes sense: there are three icon themes of significant size that are updated in %posttrans of various packages, hicolor, gnome and HighContrast. So the three spikes associated with gtk-update-icon-cache runs make sense. So it looks like since F15, the general 'background' usage of memory during an anaconda run has increased modestly, and the spikes in usage have changed somewhat. The good news is that the highest spike in a default F19 run is lower than the highest spike in a default F15 run; Chris' graph spikes clear over 800MB, while mine just touches it. The big spike in F15 was "from the selinux-policy-targeted package's %post running semodule"; that's gone completely in F19, there is no spike at all associated with selinux-policy-targeted. However, the biggest spike in F19 appears to be a new one: it is a different SELinux spike, this time sepolgen-ifgen running during install of policycoreutils-devel. It is not quite as big as the F15 spike, but obviously something we should try and optimize if possible. gtk-update-icon-cache caused spikes both times. However, during F15 it ran only once (according to Chris), and was a somewhat smaller spike. It's labelled K in Chris' graph, and is a spike of 70-80MB, to 600MB total. In F19Btc3, the spike is of 110MB, to 700MB total. The 'depmod' spike from Chris' run seems to have disappeared now. Finally, the 'ramp' associated with the new VerifyTransaction step in yum is a new issue, and possibly worrying: I haven't tested with a larger package set, but this test indicates that the memory usage never seems to level off, which would indicate that memory usage during VerifyTransaction is directly proportionate to the number of packages being installed. So at least theoretically, if you did a really big package set install, the memory usage during VerifyTransaction might be the highest of all, and could go quite high. I'll try doing an 'as much stuff as possible' install and see how high it gets. So we have a mixed picture from this small comparison; in fact the highest memory usage of a stock DVD install seems to have gone down slightly since F15, but there's clearly room for improvement, and there may be issues with larger package sets that we didn't have in F15.