

When using multiple processes each process will contain its own pool so as long as no worker process has more than ENV then this setting should be adequate. If you are using the Puma web server we recommend setting the pool value to equal ENV. The initializer method can cause confusion over what is happening and is the source of numerous support tickets.
Run rails unicorn https code#
Using an initializer requires duplicating code if you are using a forking webserver such as Unicorn or Puma (in hybrid mode). If you are already using an initializer, you should switch over to the database.yml method as soon as possible. _configurationĬonfig = ENV || ENV || 5ĪctiveRecord::Base.establish_connection(config) # Establish connection is not needed for Rails 5.2+ _initialize doĪctiveRecord::nnection_pool.disconnect!Ĭonfig = ActiveRecord::nfigurations || # Use config/database.yml method if you are using Rails 4.1+ # config/initializers/database_connection.rb

Otherwise if you are using an older version of Rails you will need to use an initializer. When your Rails application boots, it will execute the code in your initializer and establish the connection with your customizations.įor Rails 4.1+ you can set these values directly in your config/database.yml production: Threaded serversįor servers that achieve concurrency via threads we recommend using an initializer to configure your database pool. While the means are similar, the location of your connect setup can vary for threaded vs. To avoid this error you can change the size of your connection pool manually by customizing your connection settings. The max pool size is currently 5 consider increasing it

It may look something like this: ActiveRecord::ConnectionTimeoutError - could not obtain a database connection within 5 seconds. When it cannot get a connection, a timeout error will be thrown. If you try to use more connections than are available, Active Record will block and wait for a connection from the pool. The default maximum size of the database connection pool is 5. Active Record limits the total number of connections per application through a database setting pool this is the maximum size of the connections your app can have to the database. Connection poolīy default Rails (Active Record) will only create a connection when a new thread or process attempts to talk to the database through a SQL query. To accommodate this, Active Record provides a connection pool that can hold several connections at a time. Each thread or process requires a different connection to the database. I'm not seeing anything interesting in the debug output, but can post that if it helps.When increasing concurrency by using a multi-threaded web server like Puma, or multi-process web server like Unicorn, you must be aware of the number of connections your app holds to the database and how many connections the database can accept. With the -d debug flag for unicorn, I get lots of warnings and exceptions related to certain gems, in either production or development mode. I am using RVM so that could be an issue, but unicorn does run in development - and all the required gems are installed. It also doesn't matter whether I run the above as root or as a normal user. I, INFO - : worker=0 readyĪs I said, if I change to development mode then it works normally. $ bundle exec unicorn -E production -p 9092 The only output should be to stdout/stderr, and nothing is shown there either. So, I tried to reduce the situation to its essentials, and just running and accessing unicorn_rails directly gives the same exact problem. Nor is there any useful info in /var/log/apache2. So, of course I try to look in the logs to see what the issue is. But as soon as I throw the -E production switch, I get the error in the browser that "We're sorry, but something went wrong." In development mode locally, and on the linode, it works as expected. I have a small Rails 3.2 app that I am trying to get running under unicorn proxied to an Apache vhost on a Linode server.
