Depending on what the trocla library does, it could be leaking objects to the java layer, in which case tuning the max-requests-per-instance down would not help. In general, the best way to find leaks like you are talking about is described here: https://puppet.com/blog/puppet-server-advanced-memory-debugging and involves taking some heap dumps and investigating what changes between dumps to see what is leaking.
On Tue, Oct 3, 2017 at 5:11 AM, Poil <[email protected]> wrote: > Hi, > > We have PuppetServer 2.8 on RHEL7. > > After some days computation of the catalog become slower and slower; the > load average of the compute nodes increased and the compute goes in timeout. > > All our 4 computes nodes have 48 cores, only 10% of each core is used when > the timeout occured. > > We are on hiera v3, we only tuned "max-requests-per-instance: 5000" because > of a databases connection leak with our Trocla library. > > Only 150 nodes are connected to our PuppetServer. > > We never had this problem with Puppet3 (with more than 3000 nodes) > > Anyone have already see this or have a tips to resolv this ? > > Best regards, > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/c6a457e9-5caf-f048-68b7-9dbdc867a5bb%40quake.fr. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACD%3DwAc_nSQgO22P7RwytO1vz4X8KtgazJ5P75AqUfmyTuhjwQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
