Issue #11381 has been updated by Jo Rhett.
James Turnbull wrote: > From my perspective, you've ignored suggestions from me, Brice, Eric and > others from this ticket and IRC chats but I don't think there's any point in > arguing with you. I am honestly unaware of any suggestions that I haven't tried to follow. * I can't invest company's time in MCO when it is questioning the value of Puppet at this time. * I have been attempting to get ruby 1.8.7 installed without any luck at this point. Still working on it. > If you don't want to roll your own packages I am busy trying to get a working locally rolled ruby. > I am sorry we can't seem to solve your problems but we've (being both Puppet > Labs and the community) invested a huge amount of time in helping you often > despite your tone and attitude towards us. I believe that most of the time I've been both patient and easy on most issues. My tickets have been mostly been improvements that I believe most people would appreciate. This issue with the server completely falling over with nothing but "upgrade ruby" I have found very frustrating, and my frustration is echoing into the ticket. This isn't an easy task, and no justification has been given to support the suggestion. It feels like typical tech support "try rebooting" followed by "install the latest". Even a single suggestion for things to evaluate would be appreciated. Brice Figureau wrote: > That means looking into logs, correlating puppetmaster pids with catalog runs > and client connections, tracing up to the apache log. That's the only way you > will understand why your rack setup creates more ruby processes than what is > configured. Oh trust me, this is what I've been spending most of my time on. I've been pouring over logs, details, stats and trying to determine what is happening. Part of my frustration here is that ^this^ is the nature of true debugging. I am certain that PuppetLabs has extensive experience with these kinds of problems and could send me some suggestions: look for this, double-check this. But they aren't. Nothing analytical at all except "upgrade ruby". > I suggest you to replicate the problem on a test server using for instance > puppet-load (snip) > Then you'll be able to tweak your passenger settings until you find the magic > number that prevents so many rubies or you finally understand why there are > so many. And on this test server you could even try a newer ruby to verify it > solves or not your issues. Of course. I built such a server last night. It is identical in every way, but for unknown reasons puppet won't start under passenger on this identical system. I reported this in https://projects.puppetlabs.com/issues/11409 Testing is dead in the water until this issue is cleared up. ---------------------------------------- Bug #11381: puppetmaster death spiral under passenger -- document the needs! https://projects.puppetlabs.com/issues/11381 Author: Jo Rhett Status: Needs More Information Priority: Normal Assignee: Jo Rhett Category: passenger Target version: Affected Puppet version: 2.6.12 Keywords: Branch: Having run a cfengine master server that handled 25k clients, I guess I should feel spoiled. But the apparent system requirements for puppetmaster are phenomenal. With a mere 500 nodes we have a dedicated machine with 4 cores, 8 GB of memory and 6GB of swap, and yet puppetmaster goes into a death spiral daily. There is nothing on this host other than apache, passenger and puppetmaster. (and nrpe/nagios test to ensure puppet client is running) This is what top looks like when it happens: <pre> top - 01:18:06 up 1 day, 1:53, 2 users, load average: 185.70, 148.74, 77.73 Tasks: 379 total, 181 running, 198 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 99.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.1%hi, 0.1%si, 0.0%st Mem: 8174508k total, 8132764k used, 41744k free, 524k buffers Swap: 6094840k total, 6094840k used, 0k free, 19784k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7938 puppet 18 0 216m 100m 648 R 43.0 1.3 0:02.65 ruby 31786 puppet 19 0 215m 107m 1724 R 34.1 1.3 2:46.71 ruby 364 root 15 0 0 0 0 S 13.2 0.0 1:21.89 pdflush 7868 puppet 19 0 217m 102m 648 R 11.4 1.3 0:05.21 ruby 8028 root 15 0 0 0 0 S 11.4 0.0 0:21.73 pdflush 7804 puppet 19 0 212m 96m 648 R 11.1 1.2 0:02.38 ruby 7802 puppet 18 0 243m 131m 840 R 7.4 1.6 0:06.40 ruby 7692 puppet 19 0 212m 16m 648 R 7.1 0.2 0:06.10 ruby 7573 puppet 18 0 210m 12m 648 R 6.1 0.2 0:13.12 ruby 7900 puppet 18 0 225m 111m 648 R 6.1 1.4 0:05.88 ruby 7926 puppet 19 0 215m 105m 648 R 6.1 1.3 0:03.42 ruby 7941 puppet 18 0 181m 79m 648 R 6.1 1.0 0:02.68 ruby 7561 puppet 18 0 200m 21m 648 R 5.8 0.3 0:13.21 ruby 7792 puppet 18 0 222m 113m 940 R 4.9 1.4 0:11.08 ruby 8113 root 19 0 102m 896 608 R 4.9 0.0 0:01.40 crond 7902 puppet 18 0 209m 100m 852 R 4.3 1.3 0:04.42 ruby 7429 puppet 18 0 207m 25m 648 R 4.0 0.3 0:10.24 ruby 31816 puppet 19 0 225m 117m 1652 R 4.0 1.5 2:28.63 ruby 7685 puppet 18 0 210m 19m 648 R 3.7 0.2 0:10.95 ruby 7918 puppet 18 0 215m 101m 648 R 3.7 1.3 0:03.52 ruby 8121 root 18 0 60476 1144 800 R 3.4 0.0 0:00.73 sshd 31825 puppet 18 0 220m 110m 1652 R 3.4 1.4 2:54.23 ruby 7417 puppet 19 0 198m 30m 648 R 3.1 0.4 0:10.72 ruby 7459 puppet 19 0 206m 17m 648 R 3.1 0.2 0:08.91 ruby 7479 puppet 19 0 199m 17m 648 R 3.1 0.2 0:09.01 ruby 7570 puppet 18 0 205m 19m 648 R 3.1 0.2 0:14.22 ruby 7576 puppet 19 0 212m 12m 648 R 3.1 0.2 0:08.61 ruby 7585 puppet 19 0 207m 18m 648 R 3.1 0.2 0:07.44 ruby 7589 puppet 19 0 204m 14m 648 R 3.1 0.2 0:07.00 ruby 7593 puppet 19 0 181m 81m 1548 R 3.1 1.0 0:37.07 ruby 7620 puppet 19 0 210m 17m 648 R 3.1 0.2 0:07.81 ruby 7625 puppet 19 0 209m 21m 648 R 3.1 0.3 0:08.22 ruby 7652 puppet 18 0 164m 10m 648 R 3.1 0.1 0:03.61 ruby 7656 puppet 19 0 213m 35m 648 R 3.1 0.5 0:18.16 ruby 7669 puppet 19 0 204m 23m 648 R 3.1 0.3 0:10.32 ruby 7672 puppet 19 0 207m 14m 648 R 3.1 0.2 0:06.61 ruby 7676 puppet 20 0 205m 17m 648 R 3.1 0.2 0:07.71 ruby 7708 puppet 18 0 208m 16m 648 R 3.1 0.2 0:04.46 ruby 7739 puppet 19 0 221m 14m 648 R 3.1 0.2 0:04.93 ruby 7743 puppet 19 0 212m 34m 648 R 3.1 0.4 0:04.51 ruby 7747 puppet 19 0 207m 25m 648 R 3.1 0.3 0:08.15 ruby 7794 puppet 19 0 213m 41m 648 R 3.1 0.5 0:07.06 ruby 7842 puppet 18 0 211m 100m 648 R 3.1 1.3 0:06.48 ruby 7850 puppet 19 0 212m 96m 852 R 3.1 1.2 0:05.51 ruby 7852 puppet 19 0 212m 95m 648 R 3.1 1.2 0:01.68 ruby 7855 puppet 19 0 209m 97m 924 R 3.1 1.2 0:10.06 ruby 7872 puppet 19 0 214m 97m 852 R 3.1 1.2 0:08.38 ruby </pre> 1. Passenger clients are limited to 20. Where did all these other ruby instances come from? (there is no other ruby code on the system) 2. Why is it willing to spawn until system death? How can I limit this? CentOS 5.7 with ruby 1.8.5 and all puppet packages from yum.puppetlabs.com Passenger 3.0.11 at the moment but we first saw this with passenger 2.2 and upgraded without any change in behavior. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
