2011-11-24 12 views
5

Sono nel bel mezzo dell'aggiornamento di una vecchia app Rails e PostgreSQL da 2.1 a Rails 3 (tramite un passaggio intermedio di successo 2.3.11).Unicorno! e PostgreSQL

Infine, quando ho eseguito senza problemi tutti gli Rspec, ho installato Mongrel 1.2.0.pre2 e l'ho installato e funzionante - tutto OK. Anche il caso di test JMeter con 100 utenti simultanei è passato OK.

Ma quando ho provato lo stesso con Unicorn! server, funziona bene quando lo sto usando da solo, ma quando lo prendo sotto carico con JMeter, inizia a dare il 100% di errori dal momento in cui JMeter prova a effettuare il login POST. Allo stesso tempo, quando posso controllare qualche pagina specifica, mi dà errori strani come questo:

undefined method `eq' for nil:NilClass 

Al terminale ottengo il seguente output (ma solo un paio di volte):

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: questo sembra essere un problema con condiviso PGconnect oggetto, così ho tolto un po 'di testo precedente

ho scoperto che PostgreSQL docs precisano che PGconn oggetto non deve essere condivisa tra i thread che fanno richieste simultanee.

È unicorno! o AR che mescola le richieste da diversi thread nello stesso oggetto PGconn?

database.yml:

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

ho anche cercato di aggiungere questo senza alcun risultato:

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 

Spec:

  • Rails 3.0.6 (a causa dell'implementazione)
  • Unicorno! 4.1.1
  • Nginx 1.0.5
  • pg gemma 0.11.0
  • PostgreSQL 9.0.4
  • Mac OS X 10.7.2

Se Rails versione dovrebbe essere il colpevole, naturalmente Posso eseguire l'aggiornamento all'ultima versione. Ho appena iniziato con ciò che il fornitore di servizi ha.

+0

Quanti lavoratori unicorno si crea in unicorn.rb? Che timeout? – stephenmurdoch

+0

Ho aggiornato la mia domanda con unicorn.conf – Laas

risposta

7

È fondamentale non condividere connessioni di database tra processi. Quando esegui Rails con Rails preload_app, stabilirai la/e connessione/i AR prima che il master unicorno investa i lavoratori. L'esempio unicorn.conf.rb ha un consiglio per disconnettere la connessione AR nell'hook before_fork. AR ristabilirà automaticamente una nuova connessione poiché ogni operatore lo richiede post-fork.

estratto da 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 
+0

Sì, l'ho scoperto anche io, con l'aiuto della mailing-list Unicorn, ma ho dimenticato di aggiornare la mia risposta. Ti premo punti per aver fatto questo per me. Grazie. – Laas