Модели долго загружаются на движке приложения GCP и перезапускаются рабочие - PullRequest
Новая
       36

Модели долго загружаются на движке приложения GCP и перезапускаются рабочие

1 голос
/ 23 марта 2020

Таким образом, у меня была проблема с тем, что экземпляр движка приложения, который выполнял API flask, застрял во всех oop бесконечных перезапусках рабочих и все время не отвечал, что побудило движок приложения масштабироваться и добавить экземпляры (до 20!).

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

    A 2020-03-20T14:42:23Z [2020-03-20 14:42:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:2952)
    A 2020-03-20T14:42:23Z [2020-03-20 14:42:23 +0000] [2952] [INFO] Worker exiting (pid: 2952)
    A 2020-03-20T14:42:24Z [2020-03-20 14:42:24 +0000] [2975] [INFO] Booting worker with pid: 2975

Изменение этих настроек в app.yaml не имело никакого эффекта, так как они находятся на более высоком уровне: 

liveness_check:
  initial_delay_sec: 300
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 4
  success_threshold: 2
readiness_check:
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Ответы [ 2 ]

1 голос
/ 23 марта 2020

Вы должны установить --timeout 0 для бесконечных тайм-аутов.

Арбитр-арбитр запутывается, когда App Engine сокращает количество экземпляров и думает, что работники истекли.

У App Engine есть свой собственный супервизор, который контролирует тайм-ауты (с гораздо более длительным периодом тайм-аута), поэтому для Gunicorn нет необходимости обрабатывать тайм-ауты работников.

0 голосов
/ 23 марта 2020

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

Вот и вот. В моем файле app.yaml я добавил -t 75 и смог решить проблему. Оказывается, одной из старых моделей - большому наивному байесовскому классификатору - потребовалось около 50-х, чтобы равномерно загрузить.

Мой app.yaml:

entrypoint: gunicorn -b :$PORT main:app -t 75

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

...