Unicornio! y PostgreSQL

Question

Estoy en el medio de actualizar una antigua aplicación Rails y PostgreSQL de 2.1 a Rails 3 (a través de un paso intermedio exitoso 2.3.11).

Finalmente, cuando obtuve todas las Rspecs funcionando sin problemas, instalé Mongrel 1.2.0.pre2 y lo inicié y ejecuté, todo está bien. Incluso el caso de prueba JMeter con 100 usuarios simultáneos pasó OK.

¡Pero cuando intenté lo mismo con Unicornio! servidor, funciona bien cuando lo uso yo mismo, pero cuando lo tengo bajo carga con JMeter, comienza a dar 100% de errores desde el momento en que JMeter intenta enviar un inicio de sesión. Al mismo tiempo, cuando compruebo alguna página específica, me da errores extraños como este:

undefined method `eq' for nil:NilClass 

En la terminal me sale el siguiente resultado (pero sólo un par de veces):

message type 0x43 arrived from server while idle 
message type 0x5a arrived from server while idle 
WARNING: there is already a transaction in progress 

EDIT: esto parece ser un problema con compartir PGconnect objeto, por lo que elimina algunos de texto anterior

encontré que PostgreSQL docs especifican que PGconn objeto no debe ser compartida entre hilos haciendo solicitudes concurrentes.

Is Unicorn! o AR mezclando solicitudes de diferentes subprocesos en el mismo objeto PGconn?

database.yml:

production: 
    adapter: postgresql 
    encoding: unicode 
    database: *** 
    username: *** 
    password: *** 
    host: 127.0.0.1 

que incluso trató de añadir este fue en vano:

allow_concurrency: true 

unicorn.conf:

worker_processes 8 
working_directory "/full/path/to/app" 
listen '/tmp/app.sock', :backlog => 512 
timeout 30 
pid "/full/path/to/app/tmp/pids/puppetmaster_unicorn.pid" 

preload_app true 
    if GC.respond_to?(:copy_on_write_friendly=) 
    GC.copy_on_write_friendly = true 
end 

Especificaciones:

• Rails 3.0.6 (debido a implementación env)
• Unicornio! 4.1.1
• Nginx 1.0.5
• pg joya 0.11.0
• PostgreSQL 9.0.4
• Mac OS X 10.7.2

Si rieles versión debería ser el culpable, por supuesto Puedo actualizar a lo último. Empecé con lo que tiene el proveedor de servicios.

Answer 1

Es fundamental no compartir conexiones de bases de datos entre procesos. Cuando ejecuta Rails con preload_app Rails establecerá la (s) conexión (es) AR antes de que el maestro de unicornio bifurque a los trabajadores. El ejemplo unicorn.conf.rb tiene una recomendación para desconectar la conexión AR en el gancho before_fork. AR restablecerá automáticamente una nueva conexión ya que cada trabajador lo requiere después de la bifurcación.

extracto de http://unicorn.bogomips.org/examples/unicorn.conf.rb:

before_fork do |server, worker| 
    # the following is highly recomended for Rails + "preload_app true" 
    # as there's no need for the master process to hold a connection 
    defined?(ActiveRecord::Base) and 
    ActiveRecord::Base.connection.disconnect! 
    # ... 
end