Heroku H13 ошибка с пассажиром - PullRequest
Новая
       28

Heroku H13 ошибка с пассажиром

0 голосов
/ 03 мая 2018

Я получаю постоянные ошибки H13 в Heroku, когда динамо отключается из-за автоматического масштабирования. Ошибка H13 означает, что соединение было закрыто до получения ответа.

Из журналов видно, что Heroku отправляет SIGTERM при уменьшении динамограммы, а пассажир немедленно закрывает все запросы, которые еще не завершили обработку: 

May 03 08:38:24 myapp app/web.4:  App 175 stdout: Started POST "/exams/3167060/tick?elapsed_time=1" for 108.162.237.61 at 2018-05-03 12:38:23 +0000 
May 03 08:38:24 myapp app/web.4:  App 175 stdout: Processing by ExamsController#tick as HTML 
May 03 08:38:24 myapp app/web.4:  App 175 stdout:   Parameters: {"elapsed_time"=>"1", "id"=>"3167060"} 
May 03 08:38:24 myapp app/web.4:  Stopping web server... done 
May 03 08:38:24 myapp heroku/router:  at=info method=POST path="/exams/3167120/tick?elapsed_time=1" host=www.myapp.com request_id=d81b4dc5-2a5a-44a4-96c6-61b7ea6d28f3 fwd="206.221.128.1,162.158.63.225" dyno=web.4 connect=1ms service=37ms status=200 bytes=954 protocol=https 
May 03 08:38:24 myapp heroku/web.4:  Stopping all processes with SIGTERM 
May 03 08:38:24 myapp heroku/router:  at=error code=H13 desc="Connection closed without response" method=POST path="/exams/3167060/tick?elapsed_time=1" host=www.myapp.com request_id=28c2f413-847c-4d11-bce9-5be7186cfbd8 fwd="152.27.48.186,108.162.237.61" dyno=web.4 connect=1ms service=53ms status=503 bytes=0 protocol=https 
May 03 08:38:24 myapp heroku/web.4:  Process exited with status 2

Мой Procfile пассажирский конфиг выглядит следующим образом, и я не установил ничего, связанного с таймаутом: 

web: bundle exec passenger start -p $PORT --max-pool-size $MAX_POOL_SIZE --min-instances $MIN_INSTANCES --nginx-config-template config/nginx.conf.erb

За 24 часа я вижу около 16 ошибок H13 из-за SIGTERM из-за события уменьшения масштаба dyno. Я могу подтвердить масштабирование динамометрического стенда до H13 на моей информационной панели показателей Heroku. Служба поддержки Heroku сообщает мне, что по умолчанию пассажир разрешает 30 секунд (хотя я не уверен, говорят ли они об их собственной ошибке H12, которая будет выдана через 30 секунд, но я не вижу здесь H12).

Разве Пассажир не должен предоставлять некоторое время по умолчанию для завершения процессов после SIGTERM и постепенного выключения? Возможно, в моем конфиге что-то не хватает?

1 Ответ

0 голосов
/ 10 мая 2018

В жизненном цикле HTTP-запроса-ответа есть три этапа, в которые может поступить SIGTERM:

  1. Запрос по-прежнему передается на сервер (в этом случае запрос не был полностью получен, а некоторые данные отсутствуют).

  2. Запрос обрабатывается.

  3. Ответ передается клиенту.

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

(этап 1):

Я почти уверен, что ни один сервер не защитит запрос, который все еще передается в потоковом режиме (это может подвергнуть сервер медленным атакам клиентов во время процесса выключения).

(этап 2):

Во время обработки запроса сам сервер - это тот клиент, которого ждет клиент. Все серверы (AFAIK) ждут завершения ответа (или тайм-аута), прежде чем продолжить процедуру завершения работы.

(этап 3):

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

Йод позволяет в течение 10 секунд на этом этапе, который жестко закодирован. Я не смог найти ни одного параметра конфигурации для Пассажира , поэтому, возможно, это также жестко запрограммированная вещь (или, возможно, он не существует).

Подводя итог: я хотел бы рассмотреть возможность тестирования нескольких серверов с использованием медленного клиента и проверки последовательности их выключения.

Какой бы сервер вы ни выбрали, некоторые клиенты могут по-прежнему испытывать внезапные отключения.

Возможно, это не то, что вы можете контролировать или решить, но это то, что вы можете проверить и минимизировать.

Разве Пассажир не должен предоставлять некоторое время по умолчанию для завершения процессов после SIGTERM и постепенного выключения?

Это зависит от Пассажира и не является обязательным.

Кроме того, нет возможности управлять такой настройкой в ​​ документации . Это может быть значительное отсутствие (убедительный признак того, что пассажир не поддерживает эту функцию).

Возможно, в моем конфиге что-то отсутствует,

Конфигурация nginx не контролирует конфигурацию Passenger. Они связаны в определенной степени, но они не одинаковы.

AFAIK, нет возможности управлять этой опцией отключения.

...