Частый SystemExit в Ruby при выполнении HTTP-вызовов

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

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

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:в вызове' /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 timeout ' /usr/local/lib/ruby/ 1.8/timeout.rb:76:in 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 readuntil ' /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 request ' /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 start ' /usr/local/lib/ruby/ 1.8/net/http.rb:379:in get_response '

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

Я также посмотрю Пассажир. Это намного проще, чем традиционное решение Apache/nginx + Mongrel.