I am using rails 4 with puma as my web server. I am using postgres on heroku
I am getting error saying that prepared statement already 'a3' exist
This is my conf for puma
# REF https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server
workers Integer(ENV['WEB_CONCURRENCY'] || 2)
threads_count = Integer(ENV['MAX_THREADS'] || 5)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do
# Worker specific setup for Rails 4.1+
# See: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#on-worker-boot
ActiveRecord::Base.establish_connection
end
I think my config for ActiveRecord connection is causing a problem
This might help but I don't know how to do it for puma Postgres: prepared statement already exists
The rails issue linked from the question you referred to in your question has some suggestions.
The most popular seems to be removing the rack-timeout gem if it is included in your Gemfile. Does sound like a guaranteed solution but has helped someone people on that thread.
Related
I have setup my puma web server based on heroku manual: Deploying Rails Applications with the Puma Web Server
config/puma.rb:
workers Integer(ENV['WEB_CONCURRENCY'] || 2)
threads_count = Integer(ENV['RAILS_MAX_THREADS'] || 2)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do
ActiveRecord::Base.establish_connection
end
Procfile contains:
web: bundle exec puma -C config/puma.rb
Now when I try to access action which has sleep 10 which delays the response and then try to access some other action, my understanding was that Puma would handle these 2 requests concurrently (since I have 2 workers). But instead it waits for the first request which sleeps to finish then it proceeds to the second one. Am i missing something?
My setup is:
Ruby 2.2.4
Rails 4.2.0
EDIT:
Ok, so I found out that on Heroku, it works, so question is, why it doesn't work in development mode?
rails s does not use the Procfile, you may want to look at using a tool like foreman: https://github.com/ddollar/foreman
update: this was the solution:
config.allow_concurrency = true in the rails development config.
I've installed Ruby on Rails using RailsInstaller and also postgresql in Windows 8. I'm trying to run rails server using files for a pre existing app but I'm getting the error 'Worker mode not supported on JRuby or Windows'.
In my config/puma.rb file i've set workers to 0, then get an error about daemon mode not supported on windows. basically each time i change something i get more errors.
I've fixed up environment variables, gems, etc (like in other posts) such as this Cannot install Puma gem on Ruby on Rails. there any hope of running a pre-existing RoR app built in linux on a windows machine?
When I run rails server for the RoR 'blog' example it works fine, so I know that RoR is definitely working in windows!
This is my -'de-identified' config/puma.rb file. Is it because in windows I have no /var/app folder?? I've played around with directories etc to no avail.
`
#!/usr/bin/env puma
# start puma with:
# RAILS_ENV=production bundle exec puma -C ./config/puma.rb
workers 0
theident = 'nameofthing'
application_path = '/var/app/'+ theident + '.address.com.au/current'
railsenv = 'production'
directory application_path
environment railsenv
daemonize false
pidfile "#{application_path}/tmp/pids/puma-#{railsenv}.pid"
state_path "#{application_path}/tmp/pids/puma-#{railsenv}.state"
stdout_redirect"#{application_path}/log/puma-#{theident}.log"
threads 0, 16
bind "unix:///var/run/puma/" + theident + "_app.sock" `
I have changed those directories to the current path and now running 'rails server' starts going , but localhost:3000 is a page not working. I am getting errors around SIGUSR1 not working , SIGUSR2 not working ,etc
The "workers" method isn't supported for JRuby nor Windows, so the best solution would be to remove the line from puma.rb causing the error. In my case I removed;
workers Integer(ENV['WEB_CONCURRENCY'] || 2)
So remaining I have;
threads_count = Integer(ENV['RAILS_MAX_THREADS'] || 5)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do
# Worker specific setup for Rails 4.1+
# See: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#on-worker-boot
ActiveRecord::Base.establish_connection
end
It might be different for you, but the specific line will start with "workers"
I'm running the following puma config
threads_count = Integer(ENV["DB_POOL"] || ENV["MAX_THREADS"] || 15)
threads threads_count, threads_count
workers 3
preload_app!
rackup DefaultRackup
port ENV["PORT"] || 3000
environment ENV["RACK_ENV"] || "development"
on_worker_boot do
ActiveSupport.on_load(:active_record) do
ActiveRecord::Base.establish_connection
end
end
before_fork do
ActiveRecord::Base.connection_pool.disconnect!
end
It's great for production, but I don't want to spin up 3 workers or use webrick in development. I tried wrapping the worker specific code in an environment check, but that breaks the puma DSL. Any ideas for running puma in non-clustered mode in development?
Rails is not defined in puma config file, so Rails.env can't be used here, but RACK_ENV is ok.
workers(ENV["RACK_ENV"] == "production" ? 3 : 0)
I figure out a working solution before seeing scorix's answer which I accepted, but I ended up with a slightly different solution. This allows you to set the worker count, so I can run 1 in staging and 3 in production for example.
threads_count = Integer(ENV["DB_POOL"] || ENV["MAX_THREADS"] || 15)
threads threads_count, threads_count
rackup DefaultRackup
port ENV["PORT"] || 3000
environment ENV["RACK_ENV"] || "development"
if ENV["RACK_ENV"] == "production"
workers ENV.fetch("WEB_CONCURRENCY") { 3 }
preload_app!
ActiveSupport.on_load(:active_record) do
ActiveRecord::Base.establish_connection
end
before_fork do
ActiveRecord::Base.connection_pool.disconnect!
end
end
Check out the Configuration part on the docs.
What I did was set up the production config on config/puma/production.rb, so on production you would run puma with puma -C config/puma/production.rb (or however you run it on prod) and on development, rails server won't use that configuration
Why do I have 4 Puma workers if I've set WEB_CONCURRENCY=3 in my Heroku config?
In this question, I learned that New Relic calls Puma workers "app instances".
Here is my puma.rb configuration:
workers Integer(ENV['WEB_CONCURRENCY'] || 2)
threads_count = Integer(ENV['MAX_THREADS'] || 1)
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do
# Valid on Rails 4.1+ using the `config/database.yml` method of setting `pool` size
ActiveRecord::Base.establish_connection
end
Heroku config:
WEB_CONCURRENCY: 3
Puma has one master process.
It does not deal with request. It monitors and manages(restart or something) workers.
If you set 3 concurrency, there are 4 process. 3 workers(managing request) and 1 master precess(managing workers)
I am getting an application set up on Heroku for production and have a hunch that my app's memory profile is quite big. I'm looking for a gut-check / benchmarks to understand whether my app is 'bloated' or not optimized for performance. I'm currently running 1 web dyno on Heroku with HireFire spinning up workers as needed for background tasks.
Current configuration:
puma.rb:
workers Integer(ENV['WEB_CONCURRENCY'] || 2) #
threads_count = Integer(ENV['MAX_THREADS'] || 5
threads threads_count, threads_count
preload_app!
rackup DefaultRackup
port ENV['PORT'] || 3000
environment ENV['RACK_ENV'] || 'development'
on_worker_boot do
# Worker specific setup for Rails 4.1+
# See: https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#on-worker-boot
ActiveRecord::Base.establish_connection
end
Procfile:
web: bundle exec puma -C config/puma.rb
worker: bundle exec rake jobs:work
Other relevant info:
- Using a CDN for assets
- Non-production gems are placed in development or test groups
- No caching set up (yet)
- Hobby basic DB
- Stack: cedar-14
Current Status / Performance Data:
PumaAutoTune Gem:
PumaAutoTune (33445s): All is well puma.resource_ram_mb=500.58154296875
puma.current_cluster_size=2
source=web.1 dyno=heroku.xxxx
sample#load_avg_1m=0.31 sample#load_avg_5m=0.14 sample#load_avg_15m=0.12
sample#memory_total=411.41MB sample#memory_rss=402.52MB
sample#memory_cache=5.36MB sample#memory_swap=3.54MB
sample#memory_pgpgin=1189542pages sample#memory_pgpgout=1085125pages
New Relic shows the following:
Blitz test results:
I have noticed that there's a difference in # of instances reported by PumaAutoTune for cluster size vs # of instances reported by New Relic. I'm not sure if both terms refer to the same idea.
Switching to a VPS is on the table but I'm expecting a significant learning curve there as I'm self-taught and quite a novice at this, so it's not an ideal short-term solution.