Errore di rotaie ricorrenti su Heroku/Unicorn - 'esecuzione scaduta', un ActionView :: Template :: Errore

La mia domanda è simile alla seguente, ma sta accadendo in circostanze leggermente diverse.Errore di rotaie ricorrenti su Heroku/Unicorn - 'esecuzione scaduta', un ActionView :: Template :: Errore

Rails: execution expired on time_zone_select

La mia configurazione è:

Rails 3.2.13
Unicorn 4.6.2
Mongoid 3.0.22
ciclomotore 1.4.2

In esecuzione su Heroku Cedar. MongoDB è ospitato su MongoLab.

Gli errori arrivano in lotti e vengono spesso risolti da un riavvio del processo Heroku. Il primo è in genere quello riportato di seguito:

An ActionView::Template::Error occurred in [controller]#[action]: 

execution expired 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read'

Il seguente è il bit superiore della traccia dello stack. Felice di aggiungere altro se necessario!

vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `block in read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:118:in `handle_socket_errors' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:177:in `read_data' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:99:in `block in read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:202:in `with_connection' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:97:in `read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/protocol/query.rb:163:in `receive_replies' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:135:in `block in receive_replies' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:134:in `map' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:134:in `receive_replies' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:553:in `block (2 levels) in flush' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:129:in `ensure_connected' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:551:in `block in flush' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:566:in `logging' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:550:in `flush' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:539:in `process' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:349:in `query' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:138:in `block in load_docs' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/session/context.rb:105:in `block in with_node' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cluster.rb:250:in `with_secondary' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/session/context.rb:104:in `with_node' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:137:in `load_docs' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:25:in `each' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/query.rb:76:in `each' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/query.rb:76:in `each' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:132:in `block in each' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:556:in `selecting' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:131:in `each' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual.rb:18:in `each'

Rack :: Timeout è impostato per 10 secondi (credo che è stato suggerito da uno dei tutorial di caching che ho letto) - se la risposta è quello di aumentare il timeout, va bene. Ma mi chiedo se questo non è un problema di query lenta? Il comportamento sembra indicare che è solo uno dei processi Unicorn a essere bloccato (ecco perché un riavvio di ps sembra curarlo).

Ogni pensiero o consiglio sarebbe molto apprezzato!

fonte

2013-05-24 nlh

sto vedendo questo stesso problema/stacktrace su EC2 con uno stack molto simile. – nont

Questa non è una soluzione al problema, ma una soluzione leggera (e non necessariamente una buona) - Ho eliminato Unicorn per Puma e ho fatto un salto fino a 2 Dynos su Heroku e il problema si è ridotto di un fattore LARGE. Ma non è ancora risolto e sto ricevendo ancora una manciata di errori di "Execution Expired" al giorno (che è in calo da una manciata all'ora). Il mio istinto sta dicendo che si tratta di un problema Mongo/MongoLab: una lenta risposta alle query o l'interruzione di connessioni aperte con un database non locale. – nlh

Aggiornamento n. 2: Sta ancora succedendo molto, anche con 2 dynos e puma invece di Unicorn. Sospiro. – nlh

Suggerirei che questo è un problema con il file o il sistema di rete di heroku. Il metodo di lettura modped chiama 'Kernel :: select. Selezionare se stesso è una chiamata di blocco del sistema che attenderà che gli oggetti IO diventino leggibili. In questo caso è la porta TCP che rende la connessione esterna a MongoLab. Potrebbe esserci un numero qualsiasi di ragioni per cui la porta TCP non è leggibile. Mi vengono in mente problemi di rete e file. Dubito che sia una query di lunga durata in quanto il socket sarebbe leggibile durante l'esecuzione della query lì per select non bloccherebbe l'esecuzione dello script. Se il problema persiste, prenderei in considerazione la possibilità di spostarmi da heroku o forse da un database esterno su una rete diversa. AWS è sempre una buona scelta in quanto hanno una latenza molto bassa tra i boxen (scatole). HTH

fonte

2013-08-22 06:10:29 Stewart

provare a impostare la versione rubino al 1.9.3 nel vostro Gemfile, poi Fascio, commit e distribuire di nuovo

fonte

2015-07-18 03:24:17 Maysam

Errore di rotaie ricorrenti su Heroku/Unicorn - 'esecuzione scaduta', un ActionView :: Template :: Errore

risposta

Problemi correlati