Ошибка развертывания в App Engine Google Cloud - PullRequest
Новая
       41

Ошибка развертывания в App Engine Google Cloud

1 голос
/ 18 февраля 2020

Я развертываю свое nodejs приложение в облачном движке приложений Google, но оно выдает ошибку Этот запрос вызвал запуск нового процесса для вашего приложения и, таким образом, вызвал загрузку кода вашего приложения в первый раз , Таким образом, этот запрос может занять больше времени и использовать больше ресурсов ЦП, чем обычный запрос для вашего приложения. - при выполнении запроса.

Я также видел несколько ответов stackoverflow, но они не работали для меня.

my app.yaml имеют эту конфигурацию

время выполнения: nodejs10

Может кто-нибудь помочь мне из

Ответы [ 2 ]

1 голос
/ 18 февраля 2020

Уведомление «Запрос вызвал запуск нового процесса» обычно происходит, когда в приложении отсутствует запрос на разогрев.

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

Предупреждение. Устаревшие проверки работоспособности с использованием пути / _ah / health теперь устарели, и вам следует выполнить миграцию для использования разделенной работоспособности проверки.

Здесь вы можете найти Разделенные проверки здоровья для Nodejs

Проверка живучести

Проверка работоспособности подтверждает, что виртуальная машина и контейнер Docker работают. Экземпляры, которые считаются нездоровыми, перезапускаются. 

  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

Проверка готовности

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

  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Редактировать

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

App Engine пытается поддерживать ручное и базовое c масштабирование экземпляров в течение неопределенного времени. Однако в настоящее время нет гарантированного времени безотказной работы для экземпляров ручного и базового масштабирования c. Аппаратные и программные сбои, которые вызывают раннее завершение или частые перезапуски, могут произойти без предварительного предупреждения и могут занять значительное время для устранения; таким образом, вы должны сконструировать ваше приложение таким образом, чтобы оно выдерживало эти сбои.

Вот несколько хороших стратегий, позволяющих избежать простоев из-за перезапусков экземпляров:

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

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

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

Использовать очереди для выполнения асинхронного выполнения задачи.

Если вы настраиваете свои экземпляры на ручное масштабирование: используйте балансировку нагрузки между> несколькими экземплярами. Настройте больше экземпляров, чем требуется для обработки обычного трафика c. Запишите резервные логи c, которые используют кэшированные результаты, когда экземпляр ручного масштабирования недоступен.

Время работы экземпляра

1 голос
/ 18 февраля 2020

Вы можете добавить в свой app.yaml следующее: 

inbound_services:
- warmup

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

Кроме того, вы также можете добавить автоматические опции c масштабирования. Вы можете немного поиграть с ними, чтобы найти оптимальный вариант для вашего приложения. Особенно важны переменные, связанные с задержкой. Приятно отметить, что они могут быть установлены в стандартной среде GAE. 

automatic_scaling:
  min_idle_instances: automatic
  max_idle_instances: automatic
  min_pending_latency: automatic
  max_pending_latency: automatic

Дополнительные параметры масштабирования можно найти здесь .

...