On Wed, 2012-06-13 at 13:52 -0700, Luke Kanies wrote: > On Jun 13, 2012, at 1:22 PM, Peter Meier wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > >> I would really appreciate that. I recently moved a larger > >> installation to 2.7 (latest) and I'm probably going back, as the > >> slow down + extended memory usage is just not worth it. > >> > >> Compile time doubled in my case (~60s compared to 27s). We > >> migrated everything away from global scope variables to class > >> parameters with hiera lookups, but I can't imagine that these > >> additional 30s come from these lookups only. Especially as we also > >> migrated from full to thin stored configs within that migration. I > >> can tell more once I downgraded to test my assumption. > > > > So I went back from latest 2.7 to latest 2.6 and I'm back at ~30s, > > which is what I had before migrating my 5 years of puppet code to > > something that will be accepted by 3.0. > > > > Although, I do a lot of hiera lookups now, but also switched from full > > storeconfigs to thin storeconfigs, I think the difference is huge and > > I'm wondering what might cause it. > > > > As I was asked to be able to share the configuration in question, I'm > > trying to figure out a set of modules that come near my live > > configuration. But it will take a few days. But hopefully in the end, > > I can present you something that you can debug. > > thin_storeconfigs vs. normal store_configs is a very big difference in > performance usually, and for some catalogs could absolutely explain a > 30s difference. > > Would it be possible to compare that setup to PuppetDB + 2.7? If > storeconfigs is the major source of slowdown, that should make it > much, much better (and nice charts showing performance, in addition).
I believe when the master is running with --debug that we print the time the (legacy) storeconfigs took. > Either way, though, 30s for a compile is obviously unacceptable. > *shudder* I have some catalogs with around 2k resources that take about 15s (excluding storeconfigs) on some moderate hardware. While I know how much work the master has to do when compiling, it always surprises me that it takes so much time (2k is not a lot). I believe puppet is hitting hard some MRI deficiencies (for instance like large number of objects created in a short time span, or too much use of "send") that are really detrimental to the catalog compilation time. Last time (back in 2.6.x) I tried to profile the master, it wasn't really conclusive (ie no large hotspot). Maybe perftools will be better than ruby-prof :) If I have some spare time in the next following weeks, I'll check perftools on my catalogs... -- Brice Figureau Follow the latest Puppet Community evolutions on www.planetpuppet.org! -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
