SystemExit fréquent dans Ruby lors des appels HTTP

Question

J'ai un site Web Ruby on Rails qui effectue des appels HTTP vers un service Web externe.

Environ une fois par jour, je reçois un e-mail d'erreur SystemExit (stacktrace ci-dessous) indiquant qu'un appel au service a échoué.Si j'essaie ensuite exactement la même requête sur mon site quelques instants plus tard, cela fonctionne bien.Cela se produit depuis la mise en ligne du site et je n'ai pas eu de chance d'en déterminer la cause.

Ruby est la version 1.8.6 et Rails est la version 1.2.6.

Quelqu'un d'autre a ce problème?

Il s'agit de l'erreur et de la trace de la pile.

Un SystemExit s'est produit /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in exit '/usr/local/lib/rubiy/gems/1.8/gems/ rails-1.2.6 / lib / fcgi_handler.rb: 116: dans exit_now_handler '/usr/local/lib/ruby/gems/1.8/gems/activeupport-1.4.4/lib/active_seupport/inflector.rb:250:in to_proc '/usr/local/lib/rubiy/1.8/net/protocol.rb:133:in Call' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread '/ usr / local / lib / ruby ​​/ 1.8 / net / protoCol.rb: 133: dans rbuf_fill '/usr/local/lib/rubiy/1.8/timeout.rb:56:in timeout' /usr/local/lib/rubiy/1.8/timeout. RB: 76: dans Timeout '/usr/local/lib/ruby/1.8/net/protocol.rb:132:in rbuf_fill' /usr/local/lib/ruby/1.8/net/protoCol.rb:116:in Le lennuby/1.8/net/protocol.rb:116:in Le lennuby/1.8/net/protocol.rb:116:in Le lennulle '/usr/local/lib/ruby/1.8/net/protocol.rb:126:in readline' /usr/local/lib/ruby/1.8/net/http.rb:2017:in read_status_line '/ usr / local / local / lib / ruby ​​/ 1.8 / net / http.rb: 2006: dans read_new '/usr/local/lib/rubiy/1.8/net/http.rb:1047:in request' /usr/local/lib/ruby/1.8/ net / http.rb: 945: dans request_get '/usr/local/lib/ruby/1.8/net/http.rb:380:in get_response' /usr/local/lib/ruby/1.8/net/http.rb: 543: dans start '/usr/local/lib/ruby/1.8/net/http.rb:379:in get_response'

Answer 1

L'utilisation de fcgi avec Ruby est connue pour être très boguée.

Pratiquement tout le monde a déménagé Bâtard pour cette raison, et je vous recommande de faire de même.

Answer 2

Cela fait un moment que je n'ai pas utilisé FCGI mais je pense qu'un processus FCGI pourrait lancer un SystemExit si le thread prenait trop de temps.Cela peut être dû au fait que le service Web ne répond pas ou même à une requête DNS lente.Certains résultats Google montrent une erreur similaire avec Python et FCGI, donc passer à Mongrel serait une bonne idée. Ce post est ma référence que j'ai utilisée pour configurer Mongrel et j'y reviens toujours.

Answer 3

J'avais l'habitude de les obtenir tout le temps sur Apache1/fastcgi.Je pense que cela est dû au fait que fastcgi raccroche avant que Ruby ait terminé.

Passer au bâtard est une bonne première étape, mais il reste encore beaucoup à faire.C'est une mauvaise idée de supprimer les services Web des pages en direct, en particulier celles de Rails.Rails n'est pas thread-safe.Le nombre de connexions simultanées que vous pouvez prendre en charge est égal au nombre de bâtards (ou processus passagers) dans votre cluster.

Si vous avez un bâtard et que quelqu'un accède à une page qui appelle un service Web qui met 10 secondes à expirer, chaque demande adressée à votre site Web expirera pendant cette période.La plupart des équilibreurs de charge parcourent aveuglément vos bâtards, donc si vous avez deux bâtards, toutes les autres requêtes expireront.

Tout ce qui peut être d'une lenteur imprévisible doit se produire dans une file d'attente de tâches.Le premier coup sur /slow/action ajoute le travail à la file d'attente, et /slow/action continue de s'actualiser via des actualisations de page ou des requêtes via ajax jusqu'à ce que le travail soit terminé, puis vous obtenez vos résultats de la file d'attente des travaux.Il existe aujourd'hui quelques files d'attente pour Rails, mais la plus ancienne et probablement la plus utilisée est ContexteRB.

Une autre alternative, selon la nature de votre application, consiste à supprimer le service toutes les N minutes via cron, à mettre en cache les données localement et à lire votre page en direct à partir du cache.

Answer 4

Je jetterais également un oeil à Passager.C'est beaucoup plus facile à démarrer que la solution traditionnelle Apache/nginx + Mongrel.