Version 1.1.0 with single threaded puma results in "all pooled connections were in use" #883
Comments
|
The following change is simple enough where it allows me to keep my single thread settings and it works. Just a curious case of unexpected breakage with my current setup that hasn't been a problem for some time. Something just feels like this is holding onto some connection it shouldn't, but I'm very much not an expert in this area. diff --git a/config/database.yml b/config/database.yml
index b9f9f5fe5..552814532 100644
--- a/config/database.yml
+++ b/config/database.yml
@@ -1,7 +1,7 @@
default: &default
adapter: postgresql
encoding: utf8
- pool: <%= ENV.fetch('RAILS_MAX_THREADS', 5) %>
+ pool: <%= ENV.fetch('RAILS_MAX_THREADS', 5).to_i * 2 %>
development:
primary: &primary |
Can you add |
|
I have a second app that works just fine with a similar setup so I am trying to find what the difference is between the two apps. While I am digging here are the logs in case something jumps out. Here's the log up to the handling of the request: Isolated trace calls related to puma pulled from the logs attached. We were upgrading to the latest flipper and just tried to backtrack to which version broke for us. Here are the files relative to the caller trace on our side just in case they are helpful. # config/initializers/flipper.rb
require 'flipper'
require 'flipper/adapters/active_record'
Flipper.configure do |config|
config.adapter { Flipper::Adapters::ActiveRecord.new }
end
Flipper::UI.configure do |config|
config.application_href = "/admin"
config.cloud_recommendation = false
config.confirm_fully_enable = true
config.confirm_disable = true
config.banner_text = Rails.env.titleize
config.banner_class = Rails.env.production? ? "danger" : "warning"
config.descriptions_source = lambda do |_keys|
YAML.load_file(Rails.root.join("config/flipper_descriptions.yml"))
end
config.show_feature_description_in_list = true
end
# Groups
Flipper.register(:staff, &:staff?)
Flipper.register(:sellers) do |actor|
actor.thing.is_a? Seller
end
Flipper.register(:buyers) do |actor|
actor.thing.is_a? Buyer
end
Rails.application.configure do
config.flipper.preload = lambda { |request|
["/assets", "/status"].none? { |path| request.path.start_with?(path) }
}
# This is not recommended, but we currently need to add groups to deal with the amount of actors
# we have.
config.flipper.actor_limit = false
end# config/routes.rb
...
draw(:developer_routes)# config/environment.rb
# Load the Rails application.
require_relative "application"
# Initialize the Rails application.
Rails.application.initialize!# config/puma.rb
# Puma can serve each request in a thread from an internal thread pool.
# The `threads` method setting takes two numbers: a minimum and maximum.
# Any libraries that use thread pools should be configured to match
# the maximum value specified for Puma. Default is set to 5 threads for minimum
# and maximum; this matches the default thread size of Active Record.
#
max_threads_count = ENV.fetch('RAILS_MAX_THREADS') { 5 }
min_threads_count = ENV.fetch('RAILS_MIN_THREADS') { max_threads_count }
threads min_threads_count, max_threads_count
# Specifies the `port` that Puma will listen on to receive requests; default is 3000.
#
port ENV.fetch('PORT') { 3000 }
# Specifies the `environment` that Puma will run in.
#
environment ENV.fetch('RAILS_ENV') { 'development' }
if ENV['WEB_CONCURRENCY'].to_i.positive?
# Specifies the number of `workers` to boot in clustered mode.
# Workers are forked web server processes. If using threads and workers together
# the concurrency of the application would be max `threads` * `workers`.
# Workers do not work on JRuby or Windows (both of which do not support
# processes).
workers ENV['WEB_CONCURRENCY']
# Use the `preload_app!` method when specifying a `workers` number.
# This directive tells Puma to first boot the application and load code
# before forking the application. This takes advantage of Copy On Write
# process behavior so workers use less memory.
preload_app!
# If you are preloading your application and using Active Record, it's
# recommended that you close any connections to the database before workers
# are forked to prevent connection leakage.
before_fork do
ActiveRecord::Base.connection_pool.disconnect! if defined?(ActiveRecord)
end
# The code in the `on_worker_boot` will be called if you are using
# clustered mode by specifying a number of `workers`. After each worker
# process is booted, this block will be run. If you are using the `preload_app!`
# option, you will want to use this block to reconnect to any threads
# or connections that may have been created at application boot, as Ruby
# cannot share connections between processes.
#
on_worker_boot do
ActiveRecord::Base.establish_connection if defined?(ActiveRecord)
end
end
# Allow puma to be restarted by `rails restart` command.
plugin :tmp_restart# config.ru
# This file is used by Rack-based servers to start the application.
require_relative 'config/environment'
run Rails.application
Rails.application.load_server |
|
What happens if you change |
|
Yup. That's what was causing it. Thanks a ton. Looks like we had a refactor that took out some basic auth from the routing and this was not changed over to |
|
Awesome! So glad it was simple. Sorry it took so long.
…On Tue, Oct 29, 2024 at 7:13 PM Frank West ***@***.***> wrote:
Yup. That's what was causing it. Thanks a ton. Looks like we had a
refactor that took out some basic auth from the routing and this was not
changed over to Flipper, but leaving it out entirely works as well.
—
Reply to this email directly, view it on GitHub
<#883 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAB2ZDNNN6RVKRMH4VPNLZ6AJBDAVCNFSM6AAAAABOME4DM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBVGQ4TANZRG4>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The newer
VALUE_TO_TEXT_WARNINGcheck is causing the issue here after some digging. I'm unsure how to resolve this issue while keeping a single threaded puma instance running. Appreciate any insight you might have. I can currently run with multiple threads, but I like running single threaded for easier debugging in my puma.ruby: 3.2.5
rails: 7.0.8.4
Locally I run puma in single mode with a single thread:
The output I end up with after upgrading to 1.1.0 is as follows:
Changing my puma config to two threads results in the application working just fine:
This pointed me to look at the new migration check.
I was able to comment out the
warn VALUE_TO_TEXT_WARNINGin the initializer and the app boots up just fine.The app boots up and works fine without migration check in the initializer and in single threaded mode.
The text was updated successfully, but these errors were encountered: