New Relic support #128

Closed
fbjork opened this Issue Jul 31, 2012 · 60 comments

Comments

Projects
None yet

fbjork commented Jul 31, 2012

Does Puma work with New Relic out of the box? I cannot get it to report data from my app.

rafaelss commented Aug 2, 2012

after almost a whole day trying to figure this out, I got this working.
newrelic gem doesn't recognize puma as a dispatcher, so you need to configure it manually. you can do that by adding dispatcher: puma to newrelic.yml or setting NEWRELIC_DISPATCHER env variable, like NEWRELIC_DISPATCHER=puma rails s puma.

kostia commented Aug 9, 2012

In my case the environment variable helped. But I had to add following initializer config/initializers/newrelic.rb:

if defined?(NewRelic) && defined?(Puma)
  NewRelic::Agent.after_fork force_reconnect: true
end

I also had to put gem 'newrelic_rpm'outside of the group :production section, for otherwise the assets wont compile...

I can't get this to work with any of these approaches

kostia commented Aug 25, 2012

@davidray

  1. Rails-Version?
  2. RPM-Version?
  3. Puma-Version?

Please try following:

  1. Add NEWRELIC_DISPATCHER=puma to /etc/environment
  2. Add the above Initializer
  3. Move gem 'newrelic_rpm outside of the group production
  4. Add dispatcher: 'puma' to config/newrelic.yml
  5. Restart, reload everything...

#1 and #4 fixed it - I already had the other two things in place. I did #1 a bit differently though - I set the value in my command to start up puma (we use foreman to manage it) and it's all fixed. Thanks!

Had the same issue. It really only works for me if the env variable NEWRELIC_DISPATCHER=puma is set...
It would be nice if a "dispatcher: puma" line in rewrelic.yml would suffice.

Not sure why it doesn't work without the env var!?

Owner

evanphx commented Sep 2, 2012

I'm currently debugging this and plan to make some adjustments so it works out of the box. Should be out soon.

Contributor

jpascal commented Sep 3, 2012

+1 NewRelic work with NEWRELIC_DISPATCHER=puma.

Even with the ENV variable or dispatcher: key in my newrelic.yml file, as well as the after_fork block in an initializer, I can't get the newrelic_rpm agent to report data. Any status on this?

There has been a report that manually including NEWRELIC_DISPATCHER=puma in the actual start-up script of puma as opposed to an environment variable was required, in one instance

tscolari commented Oct 8, 2012

I got this error message when using the above initializer:

Plugin not initialized

I was trying to deploy with capistrano (it was from running assets precompile rake task)

@rengland-newrelic I've tried all "solutions" listed in this thread: the environment variable, setting it manually in the start-up script, including dispatcher: puma in newrelic.yml. None of them have worked.

EDIT: false alarm. it looks like setting the environment variable in my startup script did work. I'm reporting data. Cool.

Contributor

ehlertij commented Oct 11, 2012

Adding ENV['NEWRELIC_DISPATCHER'] = 'puma' to my config/boot.rb and dispatcher: 'puma' to config/newrelic.yml did the trick for me.

Rails 3.2.8, Puma 1.6.3

evanphx closed this in 2280b68 Oct 20, 2012

This doesn't work out the box for me with puma 2.0.0.b4, rails 3.2.11 and ruby 2.0.0.rc1
Works with Ruby 1.9.3 but not Ruby 2.0.0.

Here's the stack trace
https://gist.github.com/4592477

No longer working under ruby 2.0.0

@concept47 based on that stack trace, it's likely a bug in the Ruby agent rather than in puma. We're taking a look.

@davidcelis ... you're absolutely right, I ran it by newrelic and its an issue with ruby 2.0.0 and their newrelic agent

mpoisot commented Mar 29, 2013

Looks like New Relic Agent 3.5.8.72 added support for Ruby 2.0.0. Agent 3.6.0.78 added support for "thread safety" and specifically mentions Puma. I'm still on Ruby 1.9.3 so I can't confirm anything.

Unfortunately looks like I still have to set NEWRELIC_DISPATCHER=puma.

https://newrelic.com/docs/releases/ruby

I can confirm it works now.
Frickin awesome!!!

samg commented Apr 16, 2013

I wanted to let you all know I've just pushed a beta version of newrelic_rpm which should work in puma without needing to set NEWRELIC_DISPATCHER variables or other shenanigans.

More specifically, I've simplified the logic that controls when the agent attempts to start, and switched to blacklisting environments (e.g. rails console, irb, certain rake tasks) instead of trying to detect if the agent is in a "supported environment".

I'd be very interested in getting some feedback on whether this works for your puma apps and simplifies their deployment.
https://rubygems.org/gems/newrelic_rpm/versions/3.6.1.85.beta

Thanks!

Contributor

jjb commented May 24, 2013

@samg it's working for my app when running in a webserver, but seems to not be detected during asset compilation when deploying to heroku. "No known dispatcher detected"

samg commented May 25, 2013

@jjb - thanks for the update. I sounds like that's the intended behavior. The recent change I described makes it so the agent will start up even if it doesn't detect a "known dispatcher" as long as it's in a monitored environment. It will still log the message you described. I haven't added any specific code to detect puma. I've just made it so we don't need to detect every web server out there in order to start.

Thanks!

Using Ruby 2.0.0-p247, Rails 4.0.0 and newrelic_rpm (3.6.5.130)

I've added dispatcher: 'puma' to the newrelic.yml file and added ENV['NEWRELIC_DISPATCHER'] = 'puma' to the boot.rb file and the newrelic log file on the server reports:

[07/11/13 14:32:44 +0000 domain.com (12336)] INFO : Installing Sidekiq instrumentation
[07/11/13 14:32:44 +0000 domain.com (12336)] INFO : Installing Net instrumentation
[07/11/13 14:32:44 +0000 domain.com (12336)] INFO : Installing Dalli Memcache instrumentation
[07/11/13 14:32:44 +0000 domain.com (12336)] INFO : Installing Rails 4 Controller instrumentation
[07/11/13 14:32:45 +0000 domain.com (12336)] INFO : Installing ActiveRecord 4 instrumentation
[07/11/13 14:32:45 +0000 domain.com (12336)] INFO : Installing Rails4 Error instrumentation
[07/11/13 14:32:45 +0000 domain.com (12336)] INFO : Installing Rails 4 view instrumentation
[07/11/13 14:32:45 +0000 domain.com (12336)] INFO : Finished instrumentation
[07/11/13 14:32:45 +0000 domain.com (12336)] INFO : Reporting to: https://rpm.newrelic.com/accounts/xxx/applications/xxx
[07/11/13 14:32:47 +0000 domain.com (12336)] INFO : Installing Sinatra instrumentation

Still not seeing anything for the application even after another cap deploy. Production mode does have monitor_mode: true set in the yml file.

Getting this without tampering anything, but no report in newrelic_rpm (3.6.5.130), Rails 3-2-stable, Ruby 2.0.0-p247
Same config worked out of the box with Rainbows!:

INFO : Starting the New Relic agent in "staging" environment.
INFO : To prevent agent startup add a NEWRELIC_ENABLE=false environment variable or modify the "staging" section of your newrelic.yml.
INFO : Reading configuration from config/newrelic.yml
INFO : Enabling the Request Sampler.
INFO : Environment: staging
INFO : Dispatcher: puma
INFO : Application: Myapp (Staging)
INFO : Installing ActiveRecord instrumentation
INFO : Installing Sidekiq instrumentation
INFO : Installing Sinatra instrumentation
INFO : Installing Net instrumentation
INFO : Installing middleware-based Excon instrumentation
INFO : Installing Dalli Memcache instrumentation
INFO : Installing Rails 3 Controller instrumentation
INFO : Installing Rails 3.1/3.2 view instrumentation
INFO : Installing Rails3 Error instrumentation
INFO : Finished instrumentation
INFO : Reporting to: https://rpm.newrelic.com/accounts/xxxx/applications/xxx

I'm having the same problem as @pawel2105
Ruby 2.0.0 p247, rails 3.2.12, puma 2.3.2

new relic log looks like this

[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Environment: production
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Dispatcher: puma
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Application: xxxxx
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Installing Net instrumentation
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Installing ActiveRecord instrumentation
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Installing Rails 3 Controller instrumentation
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Installing Rails 3.1/3.2 view instrumentation
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Installing Rails3 Error instrumentation
[07/13/13 22:15:29 +0000 xxx (27173)] INFO : Finished instrumentation
[07/13/13 22:15:30 +0000 xxx (27173)] INFO : Reporting to: https://rpm.newrelic.com/accounts/xxxx/applications/xxxx

but I'm getting no data to newrelic whatsoever

When I downgrade to puma 2.0.1, it works just fine.

I'm seeing the same thing. Using Ruby 2.0.0-p247, Rails 4.0.0 and newrelic_rpm (3.6.5.130). In New Relic, there is no data except for it detecting a single instance pegged at 100MB. I'm running 4 workers.

I see lot of this in the puma err log:

==> rails/log/puma.err.log <==
The following keys are invalid: :newrelic_trace_data

might be a hint.

Also at the same time:

==> rails/log/newrelic_agent.log <==
[07/15/13 15:45:26 +0000 staging (19945)] ERROR : Caught exception in trace_method_execution footer.
[07/15/13 15:45:26 +0000 staging (19945)] ERROR : RuntimeError: unbalanced pop from blame stack, got net_http, expected method_tracer

Hey all. I'm an engineer on the Ruby agent team at New Relic and I'm looking into this today.

Can those who are seeing the issue confirm whether they're using clustered mode with multiple workers? If so, we've encountered an issue with that recently. While we're getting a fix ready, you can work around it by:

Adding :require => false to your gem 'newrelic_rpm' line in your Gemfile

In your puma configuration file, add a block like this:

on_worker_boot do
  require 'newrelic_rpm'
  NewRelic::Agent.manual_start
end

If anyone is not running in clustered mode but has problems with recent versions, I'm especially interested to hear about that too.

rafbm commented Jul 16, 2013

Thank you so much @jasonrclark for this timely intervention. Just switched to clustered mode and was experiencing this issue. Everything just works when following your instructions!

@jasonrclark Hi but I don't use a puma config file, instead I issue this command via Capistrano:

run "cd #{current_path} && #{fetch(:puma_cmd)} -t 1:16 -q -d -e #{puma_env} -b '#{fetch(:puma_socket)}' -S #{fetch(:puma_state)} --control 'tcp://127.0.0.1:9998'", :pty => false

I did add require: false to the Gemfile. I added this to my deploy.rb file:

after 'puma:restart', 'new_relic:start'

namespace :new_relic do
desc 'Manually start New Relic'
  task :start, :roles => :app do
    run "cd #{deploy_to}/current && /usr/bin/env rake new_relic:start_monitoring RAILS_ENV=production"
  end
end

I also created lib/tasks/start_new_relic.rake:

require 'newrelic_rpm'

namespace :new_relic do
  desc "start recording application stats for New Relic"
  task :start_monitoring => :environment  do
    NewRelic::Agent.manual_start
  end
end

Now the NewRelic log file displays:

INFO : Reporting to: https://rpm.newrelic.com/accounts/xxx/applications/xxx
INFO : Installing Sinatra instrumentation
INFO : Installing Sidekiq instrumentation
INFO : Installing Net instrumentation
INFO : Installing Dalli Memcache instrumentation
INFO : Installing Rails 4 Controller instrumentation
INFO : Installing ActiveRecord 4 instrumentation
INFO : Installing Rails4 Error instrumentation
INFO : Installing Rails 4 view instrumentation
INFO : Finished instrumentation

Whereas last time it only got up to installing Sinatra instrumentation.

Unfortunately no app server stats still.

@pawel2105 Yeah, that doesn't look like the same clustered mode issue other folks have seen. What version of puma are you running?

It would help on my end if you opened a support case. You can reference my comment here and ask them to escalate the ticket directly to me. That'll let me look more closely at what's happening on our end.

I appreciate your help, and will definitely report back here any additional information so others can benefit.

exviva commented Jul 17, 2013

I think the problem has to do with the --preload option - when I removed it, everything started working as expected again. This seems to make sense - when using preload, the agent is attached to the master process, which never receives any requests.

Can you guys confirm that you've been using --preload?

preload and cluster, yes.

grk commented Jul 18, 2013

@jasonrclark I described my issue in #335. puma 2.3.2, newrelic_rpm 3.6.5.130, no data when using daemonize, but not clustered mode.

@grk Hadn't heard about that case, but I'll see whether the fixes I'm doing for clustered mode will get it fixed. Based on how your workaround was structured, I'm hopeful what I'm working on might be applicable there too. Thanks for mentioning it!

We've released version 3.6.6.147 of newrelic_rpm which now supports Puma cluster mode. Anyone following the instructions from my comment #128 (comment) should be able to upgrade and remove both the :require => false and the on_worker_boot workaround code.

If this new version doesn't work with cluster mode, or you were having different symptoms that I missed, please feel free to comment here or enter a support ticket referencing this thread and we'll take a closer look.

On Puma 2.4.0 this is now fixed

👍

ayrton commented Aug 27, 2013

Today I've switched to Puma coming from Passenger and I noticed that I no longer see any data flowing in newrelic.

I currently see the following in my newrelic logs:

[08/27/13 21:00:20 +0200 staging01 (2058)] INFO : Installing Puma cluster mode support
[08/27/13 21:00:20 +0200 staging01 (2058)] ERROR : Error while installing puma instrumentation:
[08/27/13 21:00:20 +0200 staging01 (2058)] ERROR : NoMethodError: undefined method `cli_config' for Puma:Module

This was before and after I've set dispatcher: 'puma' in my newrelic config file, after some googling I couldn't find anything related but this issue.

I'm using puma 2.5.1 and newrelic_rpm 3.6.6.147

Finally, my puma config file:

#!/usr/bin/env puma

# Set the environment in which the rack's app will run. The value must be a string.

environment 'staging'

# Daemonize the server into the background. Highly suggest that
# this be combined with “pidfile” and “stdout_redirect”.

daemonize

# Bind the server to “url”. “tcp://”, “unix://” and “ssl://” are the only accepted protocols.

bind 'tcp://0.0.0.0:9292

Any ideas @jasonrclark?

you might have to specify 1 worker in the puma startup command, to get it to work

@ayrton The log message you're seeing is coming from a known bug that will be fixed in the upcoming 3.6.7 release (commit's already visible at newrelic/rpm@dc09a06).

Additionally, as @concept47 indicated you might need to set things up per #335. newrelic_rpm still doesn't properly support daemonize mode for Puma, and on that thread you can find instructions for working around that. I haven't checked it yet, but that workaround might avoid the cli_config failure, but that crash will definitely be addressed in the next release either way.

Definitely let us know if that doesn't get things working for you, and I'll be updating here when we do have a fix to properly start the agent when daemonized.

Hello, I tried #335 this solution - set workers to 1 and new relic started to receive data. Only one problem. I set 3 workers and in new relic I see only 1 instance.

Ondrej

@ondrejbartas Glad that seems to have gotten some part of it working for you.

Where are you seeing just one instance listed? We have a couple possible ways you could see that in the UI, so I want to be able to check where you're actually looking.

@jasonrclark I was too rush. Because of 1 puma worker could manage all request, no other workers register in new relic web ui:
screen shot 2013-09-10 at 11 28 12
But after longer time all instances are shown correctly.

Thanks

@ondrejbartas Glad to hear it cleared up eventually. Thanks for the image as well. I hadn't thought that data could potentially lag in that part of the UI, but good to know.

haggen commented Sep 11, 2013

Why is it NEWRELIC_DISPATCHER and all other variables NEW_RELIC_... ? This really kills discoverability and leads to mistakes.

By the way, dispatcher: puma and environment variable didn't work here.

Update.

Darn it! My mistake. I was using shotgun not puma to launch my Sinatra app in development.

@haggen Yeah, shotgun isn't going to work out--it's a known limit we've got.

On the environment variables, you're totally right. More recent agent versions actually support NEWRELIC or NEW_RELIC as prefixes for any the keys because it was so common for to mix them up. We're trying to consistently only document them as NEW_RELIC, but it should still be happy with the other.

mrbrdo commented Sep 19, 2013

@jasonrclark is it normal for newrelic to be detecting unicorn when running on puma?

[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Puma cluster mode support
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Sidekiq instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing deferred Rack instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing ActiveRecord 4 instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Net instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Unicorn instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Detected Unicorn, please see additional documentation: https://newrelic.com/docs/troubleshooting/im-using-unicorn-and-i-dont-see-any-data
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Rails4 Error instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Rails 4 Controller instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Installing Rails 4 view instrumentation
[09/20/13 01:45:14 +0200 distro (14810)] INFO : Finished instrumentation

I did previously have unicorn in my Gemfile, additionally to puma, but I've now removed it in hopes of solving this--didn't seem to help. It seems to work fine though (reporting data and all). As you can see I'm using clustered mode (8 workers). Also, I think I had to add NEW_RELIC_DISPATCHER to make it work (I also added dispatcher to newrelic.yml), before that it did not send any data (but it did start judging from log). Newest stable puma and newrelic_rpm.

@mrbrdo All of that seems odd to me. That Unicorn detection should be relatively harmless if the server isn't running, but I don't see why it would get found without the unicorn gem installed.

Dispatcher setting should never be required past the 3.6.1 version of newrelic_rpm, so that's odd in itself.

Any chance you could email me your Gemfile and puma configs? jclark [at] newrelic [dot] com

mrbrdo commented Sep 20, 2013

Hm, today I restarted puma on the server just in case and now it's not detecting unicorn anymore. I think I did a stop & start yesterday too, but maybe I just did a restart, not sure. Anyway it seems newrelic was then detecting unicorn because the gem was present (even though puma was present too).

Before I added the environment variable, I didn't get any data in newrelic (but logs were showing that newrelic did start).

ponny commented Nov 29, 2013

What exactly do I need to do now? I've added ENV['NEWRELIC_DISPATCHER'] = 'puma' to boot.rb and dispatcher: puma to my newrelic.yml.

Is there anything else I need to do? I'm getting practically no data (just a cpm count - everything else is zero).

Update: Puma 1.6.3 Ruby 1.9.3 Rails 4.0.1 w/ Resque Sinatra app

haggen commented Nov 29, 2013

Hey @ponny how is your launch script, I mean what do you use to boot up the server ? Also, do you know the version of your new_relic Gem ?

seuros commented Nov 29, 2013

@ponny New Relic gem work out of the box with puma.

ponny commented Nov 29, 2013

Hi @haggen I use some jungle scripts from the puma project. New relic gem v 3.6.9.171

@seuros Except when it doesn't ;-)

madwork commented Nov 30, 2013

@ponny newrelic agent v3.6.9.171 don't work (no auto_instrument) with daemonize option (#335) in single mode (workers 0), I did not test in cluster mode.

I use upstart to daemonize puma and newrelic agent works as expected.

ponny commented Dec 1, 2013

@madwork So what exactly do I need to do to fix it? I don't see how switching to upstart would make a difference.

madwork commented Dec 2, 2013

@ponny Set daemonize option to false will fix the newrelic agent issue, but puma will not start as a daemon, so to fix this behavior, I use upstart to daemonize puma (and start/stop/monitor puma process).
I made a gist for this issue: http://git.io/UjuxwQ

@ponny If you set the daemonize option true in your puma configuration, newrelic_rpm as of 3.6.9.171 doesn't detect properly. We're working on a fix, but don't have it ready yet.

@madwork's suggestion or something similar should fix things. As long as Puma doesn't daemonize itself, you should be fine--another process managing Puma can daemonize/background all it wants, as long as Puma itself isn't calling Process.daemon.

An alternative some people have had success with is setting workers 1 in your puma configuration, but that requires Puma 2 and you said you're using 1.6.3, so that's probably not an easy option.

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Jan 2, 2014

@jeroenj jeroenj [live] Set puma_cmd in capistrano to use the config and start one thr…
…ead with one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
f3814c6

Setting workers to 1 worked for me as well and -w 2 works too.
newrelic_rpm-3.7.1.182
puma-2.6.0

puma -t 8:50 -e production -b unix:///tmp/utro.0.sock -w 1 -d && puma -t 8:50 -e production -b unix:///tmp/utro.1.sock -w 1 -d

but this also works
puma -t 8:50 -e production -b unix:///tmp/utro.0.sock -w 2 -d

nTraum commented Mar 22, 2014

Can confirm that setting workers > 0 fixes the issue.

bundle show | egrep \(relic\|puma\)
  * capistrano-newrelic (0.0.8)
  * capistrano3-puma (0.2.2)
  * newrelic_rpm (3.7.3.204)
  * puma (2.8.1)

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Apr 15, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
2e23af2

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Apr 15, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
8778583

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue May 10, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
073fd26

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue May 16, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
178f8d0

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue May 19, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
0df1259

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue May 27, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
6686790

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Jun 9, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
c7bb373

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Jul 16, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
da5683e

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Aug 20, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
4710766

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Sep 26, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
f6f27a9

@jeroenj jeroenj added a commit to jeroenj/stringer that referenced this issue Sep 26, 2014

@jeroenj jeroenj Set puma_cmd in capistrano to use the config and start one thread wit…
…h one worker.

The thread/worker config is a workaround for newrelic:
puma/puma#128
da4350b

@Tomohiro Tomohiro added a commit to Tomohiro/plate that referenced this issue Feb 23, 2015

@Tomohiro Tomohiro Manual start the New Relic agent on Puma cluster
noto.io — Puma + New Relic
http://noto.io/post/67556490184/puma-new-relic

New Relic support - Issue #128 - puma/puma
puma/puma#128 (comment)
0a5a072

@dentarg dentarg added a commit to Starkast/wikimum that referenced this issue Dec 6, 2015

@dentarg dentarg Start New Relic agent after fork/thread start c96477f

@michaelpreston michaelpreston added a commit to onthebeach/new_relic_test_app that referenced this issue Nov 28, 2016

@michaelpreston michaelpreston Try not preloading app b93f7f4

@michaelpreston michaelpreston added a commit to onthebeach/new_relic_test_app that referenced this issue Nov 28, 2016

@michaelpreston michaelpreston Try starting new relic on worker boot 7397aa6

@michaelpreston michaelpreston added a commit to onthebeach/new_relic_test_app that referenced this issue Nov 29, 2016

@michaelpreston michaelpreston Try setting up new relic after worker boot
As seen in issue puma/puma#128
08e1ef4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment