Что вызывает тайм-аут шлюза 504 в Google App Engine примерно каждые 10 минут?
Я только что перенес наш рабочий веб-сайт на Google App Engine вчера вечером, и теперь приложение начинает давать таймаут 504 Gateway Timeout примерно через 10-15 минут бездействия. Но я несколько месяцев запускал тестовую версию нового сайта в GAE в другом проекте, и у него никогда не было этой проблемы. Я не понимаю, что происходит.
Ниже приведен график панели управления GAE, который показывает, что почти все запросы возвращались как ошибки 5XX до 7 утра. Я не был уверен, что происходит, поэтому просто решил повторно развернуть приложение, чтобы посмотреть, заставит ли это снова работать ... и по какой-то причине мне показалось, что это так.
После того, как я повторно- развернут, сайт снова начал отвечать. Я ненадолго щелкнул, исправил ошибку, повторно развернул ... все было хорошо.
Затем в 7:20 все запросы снова превратились в ошибку 504 Gateway Timeout.
Я видел его в 7:40, повторно развернутый без каких-либо изменений, он снова заработал и снова работает.
Что происходит?
p.s. Я знаю, что динамический экземпляр gae будет бездействовать и потребует времени для повторного запуска, но это не то, что происходит. Я вижу эту задержку в моем проекте разработчика gae, но страница появляется примерно через 10 секунд. В моем производственном gae мой браузер просто вращается целую минуту, а затем выдает ошибку 504 и продолжает делать это до тех пор, пока я не разверну заново.
• Отсутствует заголовок? (Или ... Задача не загружается из слогана)
1 | Как указано, вы используете какую-либо форму RAID?
перекрытие точек может вызвать ошибку
- Объект не указан как есть У вас запущена тестовая продукция
Обновлена ваша продукция: gcs_bucket
Это может быть связано с тем, что ваше приложение масштабируется до 0 экземпляров, это приводит к тому, что новый запрос вызывает холодную загрузку, чтобы избежать этой проблемы, вы можете настроить прогрев request для повышения скорости отклика
Например:
automatic_scaling:
target_cpu_utilization: 0.68
min_instances: 1
max_instances: 10
min_idle_instances:1
С этой конфигурацией вы можете гарантировать по крайней мере 1 экземпляр, готовый для входящих запросов, и избежать масштабирования до 0.
Обычно, когда развертывание готово 1 или 2 экземпляра раскручиваются, но без трафика приложение может масштабироваться до 0.
Согласно OP:
У него было слишком много вызовов syslog() или error_log() за слишком короткое время, и это вызвало проблему с серверной частью, из-за которой приложение зависало и интерфейсный шлюз попытается связаться с серверным экземпляром, но экземпляр не работает, поэтому шлюз в конечном итоге истечет время ожидания.
Исправление заключается в удалении вызовов для ведения журнала.