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 reports. > > 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/ > puppetserver/2.7/tuning_guide.html > > 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, Justin > > 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/ > msgid/puppet-dev/CALCxXJhp5806ZZPS9T0KNBUfhcpbe > AmEK3C1s3RR8OUOAT9oFw%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CALCxXJhp5806ZZPS9T0KNBUfhcpbeAmEK3C1s3RR8OUOAT9oFw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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/msgid/puppet-dev/CA%2B%3DBEqXUf%2BuZo0Nf7ENtafK7XdeMvEwBPk-XgM27h1A-FuBWmQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
