On May 15, 2013, at 3:22 AM, boss at airbladesoftware.com (Andrew Stewart) wrote:
> On Wed, May 15, 2013, at 11:57 AM, Eric Wong wrote: >> Andrew Stewart <boss at airbladesoftware.com> wrote: >>> On Wed, May 15, 2013, at 11:28 AM, Eric Wong wrote: >>>> If you're using preload_app, I suspect it's some background thread >>>> or hook causing it. Otherwise, can you reproduce this with a barebones >>>> application? > > I wonder whether New Relic could be doing this. I don't really know how > New Relic works but the language in its configuration file suggests it > polls each app process in the background. > > It would be interesting to hear what other New Relic users observe > happening to their master process's memory footprint. > This being software, anything is possible, but I strongly suspect that New Relic is not the cause here. The New Relic Ruby agent works by spawning a background thread in each instrumented process that periodically sends the data collected during request processing back to New Relic's servers. In the case of unicorn, it actually doesn't even spawn the background thread until we're in a callback that gets called inside each of the unicorn worker processes after the master has forked them off. That is to say, there is no New Relic-spawned background thread in the unicorn master process. FWIW, my suggestions would be to either slowly whittle down a repro case by removing gems and parts of your application that you suspect might be related until you hit one that makes the problem disappear, or to use a tool like heap_dump (https://github.com/Vasfed/heap_dump) or hack something together manually using ObjectSpace.count_objects to see if there's a particular kind of Object that's accumulating in your unicorn master process. Ben _______________________________________________ Unicorn mailing list - mongrel-unicorn@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
