Thanks for the response. Nice to get some new data points.
We're unfortunately unable to lengthen the environment cache past 30s
till we get r10k wired up and able to clear the cache automatically.
We're running 32 instances for 32 cores which seems fine, but I'm not
clear on if I should run lower. I set JAVA_ARGS="-Xms18g -Xmx18g
-XX:+UseG1GC" which seems fine the number of cores so far. Have not had
crashing problems. CPU was running 90-100% till I set the heaviest
hitting role to once an hour while we make changes.
One interesting data point is that I was using an ancient function as a
replacement from fqdn_rand(60,$seed) to keep crons from moving around
during the transition. Removing the function from the majority of cases
dropping compile times by 1-3 seconds and smoothed out the CPU curve. I
suspect this function was running poorly and might be the cause of my
1.9.3 Ruby deprecation notices I see in the logs. I suspect the more
Ruby/stdlib I remove from the manifests the better performance will be.
In regards to agents I ran a few tests on our Centos6 hosts. Definitely
see an improvement in apply times particularly in roles that have a lot
of file resources. Dropped from 45s to 30s on one of these roles which
should be http connection reuse though still need to verify it's because
we're using something other than 1.8.7 as the runtime.
Ramin
On 2/11/18 5:31 AM, Poil wrote:
Here at Claranet France, when we've switched to Puppet4, we've made
several mistake
First, the environment cache wasn't enable, and the performance with
Puppet4 is very bad when it's not.
Second, when we've reached 3000 nodes (we have 4 master nodes, 48 core,
64GB, behind 2 HaProxy) the catalog application (not compute) became
slow and slower. we tried to increase the number of JRuby instances from
4 (max in auto mode) to 12 but we had very high load and crashes. The
problem is that the JVM memory is shared between all JRuby Instance, so
just increase th xmx/xms to 1GB per JRuby instance seems to have
resolved all our performance problem.
Now our catalog application time is about 50% faster than on our old
Puppet3 infrastructures (we've also switch all our agent to Puppet4).
Best regards,
Le 11/02/2018 à 02:39, Ramin K a écrit :
tos 6 running Puppet 3.8.x. Ruby 1.8.7 so no http multiplexing. 50% of
agents on Centos 7 w/
--
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/241ab472-fdf4-2d77-dcc6-806b476e37ee%40badapple.net.
For more options, visit https://groups.google.com/d/optout.
