Приложение AppEngine nodejs время от времени отправляет сообщение 502 и перезапускается - PullRequest
Новая
       5

Приложение AppEngine nodejs время от времени отправляет сообщение 502 и перезапускается

1 голос
/ 18 июня 2020

У нас есть приложение nodejs, которое успешно развертывается в стандартной среде. Что-то происходит примерно через два часа (или раньше, в зависимости от трафика c): наши последующие клиенты начинают получать пачку из 502 ответов, а затем служба стабилизируется. Мы думаем, что это происходит, по крайней мере, несколько месяцев.

При исследовании причины ошибок 502 я вижу, что:

  • Нет журналов необработанных исключений / отклонений обещаний для указывает, что приложение узла разбилось
  • I console.log при получении SIGTERM, и это тоже не отображается в журналах
  • Журналы сопроводительного файла nginx включают следующее : 
2020/06/16 23:11:11 [error] 35#35: *1149 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 169.254.1.1, server: _, request: "POST /api/redacted HTTP/1.1", upstream: "http://127.0.0.1:8081/api/redacted", host: "redacted.appspot.com""

Я предполагаю, что 502-е поступают из nginx, потому что исходящий поток исчез. Есть ли другие объяснения, которые мне следует изучить?

Если GAE намеренно заменяет мои контейнеры приложений, не должен ли этот процесс предотвращать эти типы 502?

Следует ли мне ожидать, что что-то другое, кроме SIGTERM, быть отправлено средой, когда приложение / контейнер заменяется?

Обновление № 1 (2020-06-22)

Я исследовал и нашел доказательства того, что мы могли превышать квоту памяти, поэтому я изменил наш instance_class с F1 на F2. Пока я пишу это, наши экземпляры используют ~ 200 МБ памяти (у F2 доступно 512 МБ). Кроме того, я использую переключатель --max-old-space-size, чтобы установить использование памяти узлов на 496M.

502-е все еще происходят.

Я подозреваю, что 502-е происходят из-за завершающих экземпляров автомасштабирования . Наше приложение никогда не получает SIGTERM (даже во время развертывания). Это означает, что я не могу корректно закрыть HTTP-соединения keepalive и могу объяснить, почему nginx вызывает сброс соединения одноранговым узлом.

Обновление № 2 (2020-06-24)

Наша служба просто стандартный тип REST, без тяжелых циклов.

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

Вот наш app.yaml: 

service: redacted
runtime: nodejs12
instance_class: F2
handlers:
  - url: /.*
    secure: always
    redirect_http_response_code: 301
    script: auto

Ответы [ 2 ]

0 голосов
/ 04 июля 2020

У нас была очень похожая проблема с нашим приложением Node.js, развернутым на App Engine Flexible.

В нашем случае мы в конечном итоге определили, что у нас нехватка памяти, из-за которой сборщик Node.js мусора иногда отложить обработку запроса на сотни миллисекунд (иногда и больше). Это привело к тому, что наши URL-адреса проверки работоспособности время от времени истекали по таймауту, что побуждало GAE удалить экземпляр из активного пула.

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

Мы были удивлены, обнаружив, что может пройти две минуты или больше, прежде чем App Engine назначит трафик c вновь созданному экземпляру. Между тем временем, когда наши исходные экземпляры были объявлены неработоспособными, и когда новые экземпляры были подключены к сети, 502-е будут возвращены клиенту (предположительно nginx GAE).

Мы смогли просто стабилизировать среду добавив: 

automatic_scaling:
   min_num_instances: 4

К нашему app.yaml. Поскольку двух экземпляров обычно было достаточно для трафика c, обеспечение того, чтобы у нас всегда было четыре запущенных, по-видимому, позволяло использовать память на достаточно низком уровне, чтобы G C не останавливал обработку запроса, и даже если это произошло, у нас было достаточно избыточной емкости для обрабатывать один удаляемый экземпляр.

Параметры масштабирования для стандарта GAE немного отличаются.

Оглядываясь назад, мы могли видеть, что наши задержки / время отклика немного уменьшатся "нервничал" до того, как начались настоящие проблемы. Большинство ответов имели типичное время отклика ~ 30 мс, но все чаще мы наблюдали выбросы запросов в диапазоне x00 мс. Вы можете проверить свои журналы запросов, чтобы увидеть что-то подобное.

New Reli c s Node.js Данные виртуальной машины помогли обнаружить, что сборка мусора увеличивающееся количество времени.

0 голосов
/ 19 июня 2020

Обычно 502 сообщения являются ошибками на стороне nginx, как вы упомянули. Подробные журналы, связанные с этими ошибками, пока не отображаются в Cloud Logging.

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

Есть кое-что, на что стоит взглянуть:

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

Есть ли шанс поделиться этими метриками перед перезапуском мероприятие? Также было бы неплохо, если бы вы поделились своими ресурсами и масштабированием в app.yaml.

...