Сведения о вопросе

PASHA

16:03, 1st July, 2020

Теги

ruby-on-rails   ruby   crash    

Частые SystemExit в Ruby при совершении HTTP звонков

Просмотров: 451   Ответов: 4

У меня есть сайт Ruby on Rails, который делает HTTP вызовов к внешней веб-службе.

Примерно раз в день я получаю ошибку SystemExit (stacktrace ниже) email, когда вызов службы не удался. Если я затем попробую точно такой же запрос на моем сайте через несколько минут, он отлично работает. Это происходит с тех пор, как сайт вышел в эфир, и мне не удалось отследить, что вызывает его.

Ruby-это версия 1.8.6, а rails-версия 1.2.6.

У кого-нибудь еще есть эта проблема?

Это ошибка и stacktrace.

В SystemExit произошло /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in выход' /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in exit_now_handler' /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/inflector.rb:250:in to_proc' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in называть /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in rbuf_fill' /Таймаут usr/local/lib/ruby/1.8/timeout.rb:56:in' /Таймаут usr/local/lib/ruby/1.8/timeout.rb:76:in' /usr/local/lib/ruby/1.8/net/protocol.rb:132:in rbuf_fill' /Readuntil usr/local/lib/ruby/1.8/net/protocol.rb:116:in' / 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/lib/ruby/1.8/net/http.rb:2006:in read_new' / usr/local/lib/ruby/1.8/net/http.rb:1047:in запрос' /usr/local/lib/ruby/1.8/net/http.rb:945:in 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:in начало' /usr/local/lib/ruby/1.8/net/http.rb:379:in get_response'



  Сведения об ответе

pumpa

18:03, 1st July, 2020

Использование fcgi с Ruby, как известно, очень глючно.

Практически все переехали в Монгрел по этой причине, и я рекомендую вам сделать то же самое.


  Сведения об ответе

lats

18:03, 1st July, 2020

Прошло некоторое время с тех пор, как я использовал FCGI, но я думаю, что процесс FCGI может бросить SystemExit, если поток занимает слишком много времени. Это может быть веб-служба не отвечает или даже медленный запрос DNS. Некоторые результаты google показывают аналогичную ошибку с Python и FCGI, поэтому переход на mongrel был бы хорошей идеей. Этот пост -моя ссылка, которую я использовал для настройки mongrel,и я все еще ссылаюсь на нее.


  Сведения об ответе

qwerty101

18:03, 1st July, 2020

Я привык получать их все время на Apache1/fastcgi. я думаю, что это вызвано тем, что fastcgi зависает до того, как Ruby будет сделано.

Переход на дворняжку-это хороший первый шаг, но нужно сделать еще кое-что. Это плохая идея, чтобы отбирать из веб-сервисов на живых страницах, особенно из Rails. Rails не является потокобезопасным. Число параллельных подключений, которые вы можете поддерживать, равно числу дворняг (или пассажирских процессов) в вашем кластере.

Если у вас есть одна дворняга, и кто-то обращается к странице, которая вызывает веб-службу, которая занимает 10 секунд для тайм-аута, каждый запрос на ваш сайт будет тайм-аут в течение этого времени. Большинство балансировщиков нагрузки просто циклически проходят через ваши дворняги вслепую, поэтому, если у вас есть две дворняги, каждый второй запрос будет тайм-аут.

Все, что может быть непредсказуемо медленным, должно происходить в очереди заданий. Первое попадание в /slow/action добавляет задание в очередь, а /slow/action продолжает обновляться через обновление страницы или запросы через ajax, пока задание не будет завершено, а затем вы получите свои результаты из очереди заданий. В настоящее время существует несколько очередей заданий для Rails, но самая старая и, вероятно, наиболее широко используемая-это BackgroundRB .

Другая альтернатива, в зависимости от характера вашего приложения, заключается в отбраковке сервиса каждые N минут через cron, локальном кэшировании данных и считывании текущей страницы из кэша.


  Сведения об ответе

lats

18:03, 1st July, 2020

Я бы также взглянул на пассажира . Это намного проще сделать, чем традиционное решение Apache/nginx + Mongrel.


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться