This message was deleted.

My regex

(?:X11Forwarding)[^\s]+

is to match strings with X11Forwarding and stops on a white space, proven working in regex tests, but if I put it in a puppet code :

file_line { 'testing' :

ensure => present,

path  => '/home/ccpro/test2',

line  => 'X11Forwarding ayaw',

match => '(?:X11Forwarding)[^\s]+',

multiple => true,

replace_all_matches_not_matching_line => true,

}

the regex is matching the string, including the white spaces and strings after the white spaces : Example : X11Forwarding Part2 Test What could be the problem?

file_line

matches a whole line, as the name implies

Hi everyone. Is there some place where I can track the progress of the Debian Bookworm packaging?

They are allegedly aiming for end of quarter

@Stephen good to know. I found this JIRA issue that seemed relevant, but the link it broken apparently due to some migration: https://tickets.puppetlabs.com/browse/PA-4995

this sort of explains the background

ah, thanks for that link!

I’m reading the performance tuning documentation for puppet 7 master server (https://www.puppet.com/docs/puppet/7/server/tuning_guide.html) I’m trying to understand the levers available to optimise throughput on a small personal setup, I get the point of the max-active-instances having a 1:1 ratio with a puppet run from a client, what I’m looking to do is understand how to get the maximum throughput on those puppet runs as I’m limited by 4 cores available, with around 20 consecutive clients checking in frequently

reading the documentation on the JVM heap size, beyond the obvious that more = good because more can be done in active memory which is faster, I’m sure how far to push that, because there will surly be a limit of how much memory can actually be used effectively

also how to be effective with settings such as max-request-per-instance and max-queued-requests to recycle the processes but allow the right size of que to form

tl;dr tuning: • set max-request-per-instance to infinity (should be the default I think). That's only required if you've memory leaks in your functions • start with 1G HEAP per jruby instance • install the puppet_operational_dashboard to gather metrics • ensure you use the latest jruby that your puppetserver version supports • one jruby instance per logical cpu core is fine if the server doesn't to much else. if you have a lot of function that wait for IO/network you can go up to two jruby instances per core

when you run into performance problems: • check which garbage collection you're using • ensure reserved code cache is set to 2G • ensure min+max heap size are equal • avoid more 32-64GB HEAP sizes

interesting, thank you

(and id max-request is infinity by default)

let me know if you've performance problems

I’m certainly hitting a visual performance problem, but I need to gather some data to see if it’s real and where the bottleneck is (visually some clients are failing to check in every time)

what's their error message

machine is queing puppet requests ( I think, hence gathering data) which is holding cpu

error is resource unavailable

let me gather some proper data

(help and offer of help is appreciated)

for my interest, why would I set reserved code cache is set to 2G ?

-XX:ReservedCodeCacheSize=2G

in the JVM startup params

yeah, I got it, but why 2G ?

more caching is better but JVM only supports 2G

that's the maximum

wow, didn’t know that

nice