The environment caching is already there, use the environment_timeout 
setting. Mine is set to unlimited and I reload at deploy time by touching 
tmp/restart.txt. This so far seems to work really well.

On Thursday, 22 May 2014 19:26:47 UTC+2, Tristan Smith wrote:
>
> Dang. That does look an awful lot like my issue. I am in fact using 
> directory environments (mostly because of the screaming deprecation 
> warnings telling me I was a bad man if I didn't).
>
> :/ Shame on me for using a .0 release.
>
> On Thursday, May 22, 2014 10:17:24 AM UTC-7, Ellison Marks wrote:
>>
>> Hey, I think I remember another thread that mentioned that there were 
>> some performance issues with directory environments. Basically, the next 
>> 3.6 release will add a caching option that mostly alleviated the problem 
>> for the OP from that thread.
>>
>> https://groups.google.com/forum/#!topic/puppet-users/wzy8NPWauu4
>>
>> On Thursday, May 22, 2014 9:59:25 AM UTC-7, Tristan Smith wrote:
>>>
>>> After much hacking to get directory environments settled and the 
>>> manifest directory in place, I rolled Puppet 3.6 to our puppetmasters last 
>>> night.
>>>
>>> One of our puppetmasters has nearabouts 1000 clients, runs passenger 
>>> under apache 2.2 (ruby 1.8.7, sadly, thanks CentOS), and normally doesn't 
>>> really notice puppet running - basically peaks out at 20% CPU usage.
>>>
>>> Under 3.6, even doubling the passenger worker count, it couldn't keep up 
>>> with the load - I started running out of apache procs due to workers stuck 
>>> in waiting mode and they were all just hanging waiting for a passenger 
>>> worker to free up. CPU usage on the system capped out.
>>>
>>> Strace -c on the passenger workers had them spending 30% of their time 
>>> in clone() and 60% in wait4(), fwiw.
>>>
>>> I'm going to be digging to figure out what in hell changed to cause 
>>> this, but has anyone else experienced a significant change in performance 
>>> under 3.6?
>>>
>>> --Triss
>>>
>>

-- 
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/bf6ee783-8570-4b5c-a47a-9b135b01811c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to