Bad Gateway 502 - Google App Engine - [CRITICAL] РАБОЧИЙ ТАЙМ-АУТ

Я работал над развертыванием своего веб-приложения через Google App Engine, когда обнаружил ошибку 502 Bad Gateway Error (Nginx). После запуска gcloud app logs read я обнаружил, что ошибка:

2020-05-12 00:15:59 по умолчанию [20200511t163633] GET / input / summary 200

2020-05-12 00:16:38 по умолчанию [20200511t163633] [2020-05-12 00:16:38 +0000] [1] [КРИТИЧЕСКИЙ] ВРЕМЯ АУТА РАБОТНИКА (pid: 9)

2020-05-12 00:16:38 по умолчанию [20200511t163633] [2020-05-12 00:16:38 +0000] [9] [ИНФОРМАЦИЯ] Сотрудник завершает работу (pid: 9)

2020-05-12 00:16:38 по умолчанию [20200511t163633] [2020-05-12 00:16:38 +0000] [15] [ИНФОРМАЦИЯ] Загрузка рабочего с pid: 15

2020-05-12 00:16:38 по умолчанию [20200511t163633] POST / ввод / сводка 502

Для тех, кому интересно, мой app.yaml выглядит так:

    runtime: custom
    env: flex
    
    runtime_config:
      python_version: 3
    
    resources:
      cpu: 4
      memory_gb: 16
      disk_size_gb: 25
    
    readiness_check:
      app_start_timeout_sec: 900

Мой Dockerfile выглядит так:

FROM gcr.io/google-appengine/python

RUN virtualenv /env -p python3.7

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

ADD requirements.txt /app/requirements.txt
RUN pip3 install -r /app/requirements.txt

ADD . /app

RUN apt-get update \
    && apt-get install tesseract-ocr -y

EXPOSE 8080
ENTRYPOINT ["gunicorn", "--bind=0.0.0.0:8080", "main:app"]

Я запускаю приложение через:

    if __name__ == '__main__':
        app.run(debug=True, host='0.0.0.0', port=8080)

Кажется, что на localhost все работает нормально, но проблемы возникают при развертывании в Google App Engine. Кто-нибудь знает, в чем может быть корень проблемы? Заранее спасибо!


person Samrat Sahoo    schedule 11.05.2020    source источник
comment
По умолчанию Gunicorn использует синхронизирующих воркеров, и каждый воркер может обрабатывать только один запрос за раз. По умолчанию Gunicorn использует только одного из этих рабочих. Я бы посоветовал проверить документацию Google с рекомендуемой конфигурацией пулемета . Сообщите мне, работает ли это для вас.   -  person tzovourn    schedule 12.05.2020


Ответы (1)


Не удается развернуть? Или развертывание прошло успешно, но сервер не запускается?

Если его не удается развернуть, возможно, у вас истечет 10-минутный тайм-аут, в течение которого задания развертывания должны завершиться. Вы можете увеличить это число, установив локальную конфигурацию gcloud.

gcloud config set app/cloud_build_timeout 1200s

person Alex    schedule 11.05.2020
comment
Развертывает нормально. Его специфическая функциональность в веб-приложении, которая приводит к сбою - person Samrat Sahoo; 11.05.2020
comment
О, я вижу. эти люди, кажется, смягчают проблему, увеличивая тайм-аут Gunicorn, передавая ему arg --timeout 90 stackoverflow.com/questions/10855197/ другое предложение от этого потока - передать gunicorn --log-level=DEBUG, чтобы попытаться получить трассировку стека. Я заметил, что вы установили app_start_timeout_sec: 900 Что это подсказало? - person Alex; 11.05.2020
comment
Я не уверен насчет app_start_timeout_sec: 900; он использовался для исправления некоторых ошибок развертывания, которые у меня были. Я просто помню, что это должно было быть между 300 и 1800. Для --timeout 90 я бы добавил точку входа в app.yaml или она войдет в файл Dockerfile? Если в Dockerfile, как именно его отформатировать (я новичок в Dockerfiles)? - person Samrat Sahoo; 11.05.2020
comment
похоже, вы добавили его в эту строку ENTRYPOINT ["gunicorn", "--bind=0.0.0.0:8080", "main:app", "--timeout=90", "--log-level=DEBUG"] - person Alex; 11.05.2020
comment
или, может быть, вот так (я тоже не очень хорошо знаком с dockerfiles) ENTRYPOINT ["gunicorn", "--bind=0.0.0.0:8080", "main:app", "--timeout 90", "--log-level debug"] - person Alex; 11.05.2020
comment
К сожалению, проблема сохраняется даже после этих изменений. Я начинаю думать, что это проблема с использованием ОЗУ, потому что две функции, в которых возникает эта ошибка, являются процессами с максимальной интенсивностью ОЗУ. Есть предположения? - person Samrat Sahoo; 12.05.2020
comment
because the 2 features this error occurs on подождите, есть еще логи? В каких случаях возникает эта ошибка, а в каких - нет? Если проблема заключалась в оперативной памяти, вы должны были увидеть ошибку типа "нехватка памяти" вместо WORKER TIMEOUT. Какой тайм-аут, сколько секунд? и какое действие вызывает этот таймаут? - person Alex; 12.05.2020
comment
журналы для двух функций говорят то же самое, за исключением журналов GET и POST (первый и последний журналы), но этого следовало ожидать. Сама по себе ошибка такая же. Что касается тайм-аута, можно ли его где-нибудь найти? Если вы не имеете в виду то, что я установил в файле докеров - 90 секунд. Действие, вызывающее тайм-аут в этом случае, - это нажатие кнопки для выполнения некоторого распознавания текста на изображении. - person Samrat Sahoo; 12.05.2020
comment
время с момента, когда ваша служба получит запрос от нажатия вашей кнопки, до момента, когда WORKER TIMEOUT будет напечатан. Если вы поместите оператор журнала прямо в начало обработчика запроса, вы можете просто вычислить временные метки операторов журнала. - person Alex; 12.05.2020
comment
Время ожидания истекает примерно через 39 секунд - person Samrat Sahoo; 12.05.2020