W dniu poniedziałek, 28 stycznia 2013 16:49:38 UTC+1 użytkownik jcbollinger napisał: > > - 1 erb (35 lines with 5 variables substitution and 1 if/else clause) > > The erb evaluation is probably more costly than everything else about that > particular File declaration, combined. Especially so in that it requires > (in that particular case) up to four separate probes of the file system > just to find the template file. > > i replaced this erb with string "foo" and it showed sub-second differences, not really measurable for 2000 resources.
> > >> - 1 hiera call >> > > > I believe hiera caches data to the extent that it can do, but depending on > how your hierarchy is defined and how your data are arranged, it could > still be that each one of those hiera() calls involves filesystem probes > and possibly reading and parsing YAML. That's not particularly cheap even > if your data are simple. > disabling hiera shaves about 10 seconds on 2000 resources. not a big deal either. > - 1 exported resource >> > > > I must have overlooked that, but it's not especially cheap, either, > inasmuch as it involves connecting to and querying a DB. It's practically > expensive if the underlying DB is not local, as that then would involve > network activity. > disabling it shaves another 30 seconds on 2000 resources. nothing spectacular, considering that only adding 200-300 resources will make this time as high again. > - 4 calls to custom type (firewall) >> > > Which are probably cheap(ish), but that's not certain. > yes, hashing them out doesn't help much. > > In addition to the manifest-specific issues I discussed above, you should > also look at how your master is provisioned and loaded. Puppet is a bit of > a memory hog, so if the available physical RAM is low then Puppet may > perform a lot of expensive swaps between physical and virtual RAM. If the > master is sharing hardware with other services (even other masters in, for > example, a passenger setup), then contention for the disk subsystem could > slow everything, especially if you have SATA (or worse) disks instead of > SCSI. There are many other such possibilities. > > i've tried to bind those problems to i/o but putting manifests on ramdisk doesn't help at all. manifests are still compiling very slow. i know that those times are high. but anyway i can't find a single "bit" that makes it so. i think puppet is very sensitible to the way its used. when you look at ruby 1.8/1.9 comparisions for the same manifests, you can clearly see that something worrying is happening, as newer ruby should be more optimized, but instead it runs significantly slower. on production we use passenger with no of puppetmaster processes equal to number of threads (and queue of excessive catalog requests on haproxy on front of it). -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
