In regard to: [Puppet Users] Re: workarounds for ruby segfaults on puppet...:

For those of you that are using puppet on RHEL 6.x (/CentOS/Oracle
Linux/Scientific Linux/etc.) and have experienced ruby segfaults on
your puppet master(s), what workaround or workarounds have you been
using?


I found that adding the following to config.ru stops the problem.
ARGV << "--profile"
I am presuming this is because the --profile option is incrementing the
reference count to all the objects in memory for a single catalog compile
and prevents the ruby GC bug from thinking something is no longer needed.

Thanks John!  I had seen that + other options, but I was pretty concerned
about running our production master with the amount of logging it would
generate.  I'll give just --profile a try and see if the situation
improves.

Another option that will be crazy memory intensive is to disable GC in
config.ru
GC.disable

This worked fine on our test machines, but the only way to make it
sustainable in production is to set a really low PassengerMaxRequests.
This wasn't a good option for us in production either, as it removed the
performance gains of hiera file caching.  If you don't have a lot of
parameterized classes or your Puppet Masters have a lot of capacity,
disabling GC and lowering PassengerMaxRequests might be an option, but I
still think "--profile" is the better way to go.

We don't have a lot of parameterized classes, but their use is definitely
growing, especially as we start making more use of the best forge modules.
GC.disable is a good fall-back idea for us, if the --profile option
doesn't completely fix it.

I found a bugzilla on the GC bug, don't have the number handy, but it
basically said that GC in ruby 1.8.7 has a flawed design and this can't be
fixed.  So the only real way to avoid all the headaches this bug can cause
is repackage to ruby193 or upgrade to Red Hat 7.

Yeah, I had seen that one too:

        https://bugzilla.redhat.com/show_bug.cgi?id=843199

It was the "it's so broken it can't be fixed" that caused me to ask here.

You have been extremely helpful!  Thanks so much for the information
you've provided!  It very likely has saved me a lot of work.

Tim
--
Tim Mooney                                             tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

Reply via email to