Bug #1722

Puppetmaster sits at 100% CPU usage after client disconnect

Added by Robert Lazzurs almost 2 years ago. Updated almost 2 years ago.

Status:Needs design decision Start:10/31/2008
Priority:Normal Due date:
Assignee:Robert Lazzurs % Done:

0%
Category:transactions
Target version:-
Affected version:0.24.5 Branch:
Keywords:
Votes: 0

Description

If for some reason a client disconnects say due to a timeout the puppetmaster server will just sit and use up all of the CPU power on the server.

If there is anything more you need me to add to this please let me know.

History

#1
Updated by Robert Lazzurs almost 2 years ago

Hello,

Some more useful information I hope.

I tested this with 7 puppet clients running Fedora 8 and the server running 5 puppetmasterd processes on the server using —mongrel and going through nginx. The server was running Fedora 9.

Puppet was the RPM available from the distribution.

I can make this happen every time I try and run the above and I have not seen an end to the CPU usage after 20 mins when I had to kill the puppetmasterd processes on the server.

I hope this extra information is helpful, if you need anything else please let me know.

#2
Updated by Brice Figureau almost 2 years ago

lazzurs wrote:

If there is anything more you need me to add to this please let me know.

I think you should: * include puppetmasterd logs and clients logs in debug mode * try to reproduce it with a webrick only test install * try to reproduce with a simple config that someone else can run

#3
Updated by Robert Lazzurs almost 2 years ago

Excellent, thanks for the feedback. I will get this information added on Monday or Tuesday.

Thanks again.

#4
Updated by James Turnbull almost 2 years ago

  • Category set to transactions
  • Status changed from Unreviewed to Needs design decision

#5
Updated by James Turnbull almost 2 years ago

  • Assignee set to Robert Lazzurs

#6
Updated by Brice Figureau almost 2 years ago

lazzurs wrote:

Excellent, thanks for the feedback. I will get this information added on Monday or Tuesday.

Also, you should try to instrument your ruby interpreter: * strace the live process to find if it spends time in the kernel * use gdb with a ruby extension to get a ruby stacktrace: http://eigenclass.org/hiki.rb?ruby+live+process+introspection

Also available in: Atom PDF