Thank you very much for your attention and for the tips.
I set the PuppetServer memory from 2 to 4 GB.
JAVA_ARGS = "- Xms4G -Xmx4G"
I also adjusted the number of JRuby instances from 4 to 2.
It's been 4 hours since I made this configuration and the problem was
It used to happen every 30 or 40 minutes.
Abraço e fica com Deus.
Livro de Puppet => novatec.com.br/livros/puppet
Livro de Zabbix => novatec.com.br/livros/zabbix
2018-03-12 18:05 GMT-03:00 Justin Stoller <jus...@puppet.com>:
> On Sun, Mar 11, 2018 at 4:58 AM, Aécio <aeciopi...@gmail.com> wrote:
>> Hello guys!
>> I have the following problem: every 30 or 40 minutes, I get a
>> notification that port 8140 / TCP (from PuppetServer) is closed and
>> puppet-agent (from client servers) can not get the catalog and / or send
>> Looking at the log in /var/log/puppetlabs/puppetserver/puppetserver.log
>> and watching the process, I saw that the puppetserver service did not stop.
>> Can anyone help me solve this problem?
>> What have I done?
>> 1) I have read the page https://puppet.com/docs/puppet
>> 2) I installed PuppetServer 2.8.1 (compatible with Puppet4.x) on a server
>> with 6GB of RAM and 2 vCPU and changed the following settings:
>> # /etc/default/puppetserver
>> JAVA_ARGS = "- Xms2G -Xmx2G"
> Is there a reason not to give it more ram? I see you have 6gs on the
> system, usually folks put the server on a dedicated box and give it all but
> 1 or 2 gigs of the memory available, having said that for a small
> installation 2 gigs should be enough.
>> # /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf
>> max-active-instances: 4
> Usually we default max-active-instances to (number of cps - 1) with a max
> of 4. That would give you a max-active-instances of 1. 4 is too many for a
> box with 2 vCPUs and 2gs of memory.
> This is my own recency bias but we were just working on a problem where
> all JRuby instances were flushed at the same time and caused an
> unacceptable pause. The port shouldn't close during that time however,
> requests should just pile up. If it was a JRuby instance issue, knowing the
> number of agents checking in and tuning max-requests-per-instance might
> help (in addition to lowering the number of max-active-instances), you
> would also see all of the JRuby instances being flushed and new ones primed
> in the logs during the downtime.
> Do you have anything HUPing the server at these times? Reloading the
> server shouldn't take nearly that long but might take an extended period
> with those memory and instance allocations.
> You wouldn't see the whole process go down, but you would see some
> shutdown startup functions in the logs, and at debug see an actual notice
> that it was happening because of a HUP.
> Hope that helps,
>> Unfortunately, the issue has not been resolved.
>> Thanks for the attention and any help.
>> Aécio Pires
>> Book of Puppet => novatec.com.br/livros/puppet
>> Book of Zabbix => novatec.com.br/livros/zabbix
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.