On Wed, Jan 11, 2017 at 09:40:00PM +0000, R.I.Pienaar wrote: > > > ----- Original Message ----- > > From: "Christopher Wood" <christopher_w...@pobox.com> > > To: "puppet-users" <puppet-users@googlegroups.com> > > Sent: Wednesday, 11 January, 2017 22:33:22 > > Subject: Re: [Puppet Users] Puppet managing thousands of resources > > > Out of gruesome interest, 5000 resources of what? > > > > Assuming I'm remembering the path correctly, something like this would > > count it > > up, modify for your local case (assuming no puppetdb at your place) to > > search > > for resource types: > > > > python -m json.tool /var/lib/puppet/client_data/catalog/`hostname -f`.json | > > grep '"type":' | sort | uniq -c | sort -rn | head > > last_run_summary.yaml will show totals already also total time per resource > type :)
That's fairly aggregate. Were this issue of lengthy agent run times presented to me I would start out being more interested in the resource types as they might appear in the manifests. I've had success reducing catalog compilation times by optimizing away from stacks of tiny resources (defines, classes, lists of stale ensure=>absent resources). Here's a contrived example but based on something that happened here. # super puppetdb querying of all catalogs here 200 File 160 Class 140 Package 70 Customsoftware::Includefile If they're all files this specific method won't be a useful count but the notion of exploring just what's going on here is what I'm getting at. > > What do you mean by populating local files via ENC? I'm drawing a blank. Or > > perhaps my mind is recoiling from the notion that you're sending contents of > > files in via top-level ENC variables. > > > > (For reference catalog sizes around here go from 500-2000 resources with > > agent > > funs mostly from 15-90 seconds, 2-7 minutes in the initial run. (Because > > some > > departments do actually have sensible reasons to manage things with that > > granularity.) We're not so big though.) > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/1250936490.1005855.1484170800075.JavaMail.zimbra%40devco.net. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20170111222135.GA4047%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
