On Mon, May 4, 2009 at 2:07 PM, <ch+...@zeha.at> wrote: > > On Apr 30, 7:20 pm, Nigel Kersten <nig...@google.com> wrote: >> so here are my unorganized thoughts on Passenger settings. >> >> * PassengerMaxPoolSize >> >> This depends a lot on two primary variables. a) How much RAM you have. >> b) How much resident memory is needed for your environments/modules. >> Only way to determine this is with tweaking, and you'll need to be >> much more conservative than the suggested settings on the Passenger >> docs as your app takes up a lot more memory than your average site. > > Sure; the puppetmaster processes are quite heavy. > Right now I'm running with a MaxPoolSize of 10, fitting nicely into > the 2.5GB of reserved memory.
I'm finding a similar value works quite nicely in conjunction with setting PassengerMaxRequests 3000 Although I'm running with the defaults for idle time of 300 seconds anyway, I find that on overnight puppet runs (where we have one environment predominantly puppeting, but a few miscellaneous other environments also checking in less frequently), this has a significant impact upon memory usage. Without the max requests setting (which for us is about the equivalent of 20 puppet runs for that app instance), memory usage continues to climb. I'm not actually seeing memory leaks as such with 0.24.8. What I am seeing is that there is a large memory hit for an app instance loading a new environment, and that this doesn't necessarily get reclaimed quickly enough once that environment is no longer actively used by the puppet server. With that setting on, even if all 10 pool members are busy (man I love having passenger-status and apachetop with Puppet now), after a member has fulfilled about 20 client runs, it gets automatically restarted, instantly reducing memory usage. As my puppet servers are all virtualized, there's a particularly noticeable hit if I start to swap which has a snowball effect. The pool members start to hit swap and load increases as they're unable to fulfill requests as quickly, which increases memory usage, etc etc. Obviously picking a number for MaxRequests is going to depend upon your server, the available memory, the number of members in the pool, the requests per client run, etc etc etc. the 'passenger-status' tool is incredibly useful here, as it lets you peek nicely into the current state of the pool. > >> * PassengerStatThrottleRate 600 >> I haven't noticed this make a *huge* difference, but logically we >> don't need to stat for the relevant files at all really. > > I think it's best to actually disable RackAutoDetect & > RailsAutoDetect, but I'm not sure if disabling them will avoid the > stats. It doesn't appear to, but the stat throttle rate only appears to make a significant difference if you're already swapped, which from my experience means you're in trouble already. > >> * PassengerHighPerformance >> Turning this on appears to reduce performance for me. > > Interesting. From the docs I'm not seeing how this could decrease > performance. Anyway, hosting puppetmaster doesn't need any rewrites or > something, so turning it on/off shouldn't hurt operations. I've been really surprised by this, but using my own stress testing scripts and the puppet-test executable confirms this absolutely. Turning on high performance is about 2-5% slower. > >> * PassengerMaxRequests >> I'm trying to work out at the moment whether we're leaking memory at >> all with 0.24.8, but even if we're not, I can imagine this making a >> big difference for certain usage patterns. I'm thinking of say having >> a lot of different environments that all puppet regularly, but then an >> overnight period where only one or two environments are being used. If >> I understand how this works correctly, this should reduce memory >> usage. > > This probably depends heavily on your environment. On my setup the > puppetmaster processes stay between 200-300M VIRT, and don't grow > larger, so I haven't looked at this at all. > >> * PassengerPoolIdleTime >> The default is 300 seconds. I'm yet to look into this setting. > > I'm running with the default here, but still get long lived > puppetmaster processes. Probably they never get idle. > >> * RailsSpawnMethod >> * PassengerUseGlobalQueue > > Haven't touched these at all. > > Thanks for your feedback! > > Christian > > > > -- Nigel Kersten nig...@google.com System Administrator Google, Inc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
