na, dont do that

in /etc/default/puppetserver or something, set JAVA_BIN

updating the default java might break other stuff

oh i meant for your other applications

Yeah, it’s a vendored Java. No touchy

but yes for puppetserver for sure do that

but i would probably just leave it as using 8

it works way faster with java 11

PE vendores Java, FOSS doesnt. and performance /memory allocation for 11 is way better compared to 8

If it’s in /opt/puppetlabs, I don’t touch it unless led by Puppet support.

that's fair

Ok, thanks 🙂

@CVQuesty, you don't have to, since PE uses 11 🙂

Yup, PE 2019 and 2021 use Java 11. Java 17 is on the horizon.

message has been deleted

Puppet Server relies heavily on the Java JIT compiler --- which is much improved in Java 11 relative to Java 8. Garbage collection algorithms have also been improved between Java 11 and Java 8. Java 11 switches the default collector to G1, but we’ve found through research and experimentation that the ParallelGC works better with JRuby, so

-XX:+UseParallelGC

in

JAVA_ARGS

is a good idea when using 11 or newer.

do you already knownif we will see java 17 in PE 2021 as opt-in option?

I haven’t heard of any plans to that effect. Switching the Java version up is a pretty big change, so it might be something that shows up in the Puppet 8 timeline.

dang

message has been deleted

UseParallelGC is also what i've found in my testing to be superior

incase you notice - (I didn’t use certless for this call because i needed to modify auth.conf to run from these compilers directly)

incase you notice - (I didn’t use certless for this call because i needed to modify auth.conf to run from these compilers directly - hence the /v3 endpoint calls)

from what it seems like, it’s unable to get the certname from puppetdb (and maybe corresponding facts?), but there is access (tested with curl too) since it’s able to get facts / certname when it’s compiled against 1 node

hehe, next thing would be strace

Yeah. Aleksey Shipilëv posted some analysis here: https://github.com/jruby/jruby/issues/5789#issuecomment-511931326 Sounds like the gist is that the things G1 does to ensure pause times are low have a lot of overhead with the way JRuby works. So, you get better overall throughput at the cost of increased pause times with ParallelGC. Since

puppet

runs on a 30 minute schedule, it’s probably a good trade-off overall to use ParallelGC and pack more agent runs into that 30 minute window, even if some see a handful of seconds of latency.

Yeah. Aleksey Shipilëv posted some analysis here: https://github.com/jruby/jruby/issues/5789#issuecomment-511931326 Sounds like the gist is that the things G1 does to ensure pause times are low have a lot of overhead with the way JRuby works. So, you get better overall throughput at the cost of increased pause times with ParallelGC. Since

puppet

runs on a 30 minute schedule, it’s probably a good trade-off overall to use ParallelGC and pack more agent runs into that 30 minute window, even if some see a handful of seconds of latency.

https://github.com/camptocamp/puppet-catalog-diff/blob/master/lib/puppet/catalog-diff/compilecatalog.rb you can trow a bunch of Puppet.debug() statements into that file tomorrow

If I have this in a hiera yaml file:

mysql::server::override_options:
  'mysqld':
    bind_address: '*'
    expire_logs_days: 1
    innodb_buffer_pool_size: 1G
    innodb_file_per_table: 'ON'

How can I have something similar on a more "precise" hiera file, but that changes only one parameter?

you would need to set lookup_options on that key ( https://puppet.com/docs/puppet/7/hiera_merging.html#setting_lookup_options_to_refine_the_result_of_a_lookup )