mysql - seleccionar - ActiveRecord:: ConnectionTimeoutError: no se pudo obtener una conexión de base de datos en 5.000 segundos(esperó 5.000 segundos)

no se puede seleccionar base de datos wordpress

Question

Tengo una aplicación de rieles en producción que implementé algunos cambios el otro día. De repente, ahora ActiveRecord::ConnectionTimeoutError: could not obtain a database connection within 5.000 seconds (waited 5.000 seconds) el error ActiveRecord::ConnectionTimeoutError: could not obtain a database connection within 5.000 seconds (waited 5.000 seconds) varias veces al día y tuve que reiniciar puma para solucionar el problema.

Estoy completamente perplejo en cuanto a qué está causando esto. No cambié nada en mi servidor y los cambios que hice fueron bastante simples (agregar a una vista y agregar a un método de controlador).

No veo mucho de nada en los archivos de registro.

Estoy usando rails 4.1.4 y ruby ​​2.0.0p481

¿Alguna idea de por qué mis conexiones se están llenando? Mi grupo de conexiones está configurado en 10 y estoy usando la configuración predeterminada de puma.

Aquí hay un rastro de pila:

ActiveRecord::ConnectionTimeoutError (could not obtain a database connection within 5.000 seconds (waited 5.000 seconds)):
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:190:in `block in wait_poll''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:181:in `loop''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:181:in `wait_poll''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:136:in `block in poll''
/usr/local/rvm/rubies/ruby-2.0.0-p481/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:146:in `synchronize''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:134:in `poll''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:418:in `acquire_connection''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:351:in `block in checkout''
/usr/local/rvm/rubies/ruby-2.0.0-p481/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:350:in `checkout''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:265:in `block in connection''
/usr/local/rvm/rubies/ruby-2.0.0-p481/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:264:in `connection''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:541:in `retrieve_connection''
activerecord (4.1.4) lib/active_record/connection_handling.rb:113:in `retrieve_connection''
activerecord (4.1.4) lib/active_record/connection_handling.rb:87:in `connection''
activerecord (4.1.4) lib/active_record/query_cache.rb:51:in `restore_query_cache_settings''
activerecord (4.1.4) lib/active_record/query_cache.rb:43:in `rescue in call''
activerecord (4.1.4) lib/active_record/query_cache.rb:32:in `call''
activerecord (4.1.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:621:in `call''
actionpack (4.1.4) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call''
activesupport (4.1.4) lib/active_support/callbacks.rb:82:in `run_callbacks''
actionpack (4.1.4) lib/action_dispatch/middleware/callbacks.rb:27:in `call''
actionpack (4.1.4) lib/action_dispatch/middleware/remote_ip.rb:76:in `call''
airbrake (4.1.0) lib/airbrake/rails/middleware.rb:13:in `call''
actionpack (4.1.4) lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call''
actionpack (4.1.4) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call''
railties (4.1.4) lib/rails/rack/logger.rb:38:in `call_app''
railties (4.1.4) lib/rails/rack/logger.rb:20:in `block in call''
activesupport (4.1.4) lib/active_support/tagged_logging.rb:68:in `block in tagged''
activesupport (4.1.4) lib/active_support/tagged_logging.rb:26:in `tagged''
activesupport (4.1.4) lib/active_support/tagged_logging.rb:68:in `tagged''
railties (4.1.4) lib/rails/rack/logger.rb:20:in `call''
actionpack (4.1.4) lib/action_dispatch/middleware/request_id.rb:21:in `call''
rack (1.5.2) lib/rack/methodoverride.rb:21:in `call''
dragonfly (1.0.5) lib/dragonfly/cookie_monster.rb:9:in `call''
rack (1.5.2) lib/rack/runtime.rb:17:in `call''
activesupport (4.1.4) lib/active_support/cache/strategy/local_cache_middleware.rb:26:in `call''
rack (1.5.2) lib/rack/sendfile.rb:112:in `call''
airbrake (4.1.0) lib/airbrake/user_informer.rb:16:in `_call''
airbrake (4.1.0) lib/airbrake/user_informer.rb:12:in `call''
railties (4.1.4) lib/rails/engine.rb:514:in `call''
railties (4.1.4) lib/rails/application.rb:144:in `call''
railties (4.1.4) lib/rails/railtie.rb:194:in `public_send''
railties (4.1.4) lib/rails/railtie.rb:194:in `method_missing''
puma (2.9.0) lib/puma/configuration.rb:71:in `call''
puma (2.9.0) lib/puma/server.rb:490:in `handle_request''
puma (2.9.0) lib/puma/server.rb:361:in `process_client''
puma (2.9.0) lib/puma/server.rb:254:in `block in run''
puma (2.9.0) lib/puma/thread_pool.rb:92:in `call''
puma (2.9.0) lib/puma/thread_pool.rb:92:in `block in spawn_thread''

Puma init.d script

#!/bin/sh
# Starts and stops puma
#
case "$1" in
start)
su myuser -c "source /etc/profile && cd /var/www/myapp/current && rvm gemset use myapp && puma -d -e production -b unix:///var/www/myapp/myapp_app.sock -S /var/www/myapp/myapp_app.state"
;;
stop)
su myuser -c "source /etc/profile && cd /var/www/myapp/current && rvm gemset use myapp && RAILS_ENV=production bundle exec pumactl -S /var/www/myapp/myapp_app.state stop"
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac

EDITAR

Creo que finalmente reduje el problema para estar con la gema airbrake y usar el método de user_signed_in? current_user o user_signed_in? en application_controller.rb en a before_action .

Aquí está mi controlador de aplicación:

class ApplicationController < ActionController::Base
protect_from_forgery
before_filter :authenticate_user!, :get_new_messages
# Gets the unread messages for the logged in user
def get_new_messages
@num_new_messages = 0 # Initially set to 0 so login page, etc works
# If the user is signed in, fetch the new messages
if user_signed_in? # I also tried !current_user.nil?
@num_new_messages = Message.where(:created_for => current_user.id).where(:viewed => false).count
end
end
...
end

Si elimino el bloque if , no tengo problemas. Desde que introduje ese código, mi aplicación parece quedarse sin conexiones. Si dejo eso if bloque está en su lugar y elimino la gema airbrake, mi aplicación parece funcionar bien solo con las 5 conexiones predeterminadas establecidas en mi grupo en mi archivo database.yml .

EDITAR

Finalmente me doy cuenta de que si comento esta línea en mi archivo config/environments/production.rb config.exceptions_app = self.routes que no obtengo el error. Parece que las rutas personalizadas + diseñar en el controlador de la aplicación before_action son la causa. Creé un problema y un proyecto reproducible en github.

https://github.com/plataformatec/devise/issues/3422 https://github.com/toymachiner62/devise-connection-failure/blob/master/config/environments/production.rb#L84

Answer 1

Con la ayuda de los chicos del ingenio, creo que finalmente resolví este problema. Parecía que al usar páginas de error personalizadas con su propio controlador, no me estaba saltando el before_action get_new_messages . Entonces la solución más simple era agregar:

skip_before_filter :get_new_messages

a mi controlador de error personalizado.

Este problema explica en detalle la razón detrás de esto: https://github.com/plataformatec/devise/issues/3422

Answer 2

En última instancia, este problema todavía me atormentaba por otro año más o menos. Finalmente obtuve una buena solución al trabajar con los chicos Puma.

Actualiza tu puma a al menos 2.15.x

Answer 3

Tuve los mismos problemas causados ​​por demasiadas conexiones abiertas a la base de datos. Esto puede suceder cuando tiene consultas de bases de datos fuera de un controlador (en un modelo, programa de correo, generador de pdf, ...).

Podría arreglarlo envolviendo esas consultas en este bloque que cierra la conexión automáticamente.

ActiveRecord::Base.connection_pool.with_connection do
# your code
end

Dado que Puma funciona con múltiples subprocesos, el tamaño del grupo (como se menciona en eabraham) también puede ser una limitación. Intenta aumentarlo (un poco) ...

¡Espero que esto ayude!