Приложение Django на движке приложений Google периодически падает, но журналы регистрации не показывают причину сбоя
У меня есть приложение Django 4.0, работающее на google app engine, и по большей части оно работает нормально. Однако у меня есть определенная страница, которая, похоже, приводит к краху приложения после того, как я загружаю страницу несколько раз. На моем ноутбуке я не вижу такого поведения, поэтому я пытаюсь отладить, что идет не так, когда приложение работает на GAE, но у меня нет достаточного представления о том, что происходит. Просмотр журналов не говорит мне ничего интересного, только то, что рабочие отключаются, а затем перезапускаются:
gcloud app logs tail -s default
2022-01-26 16:02:38 default[fixeddev] 2022-01-26 08:02:38,933 common.views INFO Application started
2022-01-26 16:03:40 default[fixeddev] "GET /organization/clean_up_issues/ HTTP/1.1" 200
2022-01-26 16:03:56 default[fixeddev] "GET /organization/clean_up_issues/ HTTP/1.1" 200
2022-01-26 16:04:10 default[fixeddev] "GET /organization/clean_up_issues/ HTTP/1.1" 500
2022-01-26 16:04:15 default[fixeddev] [2022-01-26 16:04:15 +0000] [12] [INFO] Handling signal: term
2022-01-26 16:04:15 default[fixeddev] [2022-01-26 08:04:15 -0800] [22] [INFO] Worker exiting (pid: 22)
2022-01-26 16:04:15 default[fixeddev] [2022-01-26 08:04:15 -0800] [25] [INFO] Worker exiting (pid: 25)
2022-01-26 16:04:15 default[fixeddev] [2022-01-26 08:04:15 -0800] [27] [INFO] Worker exiting (pid: 27)
2022-01-26 16:09:49 default[fixeddev] "GET /_ah/start HTTP/1.1" 200
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [10] [INFO] Starting gunicorn 20.1.0
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [10] [INFO] Listening at: http://0.0.0.0:8081 (10)
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [10] [INFO] Using worker: gthread
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [21] [INFO] Booting worker with pid: 21
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [24] [INFO] Booting worker with pid: 24
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [25] [INFO] Booting worker with pid: 25
2022-01-26 16:09:49 default[fixeddev] [2022-01-26 16:09:49 +0000] [26] [INFO] Booting worker with pid: 26
2022-01-26 16:09:50 default[fixeddev] OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k
2022-01-26 16:09:50 default[fixeddev] OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k
2022-01-26 16:09:50 default[fixeddev] OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k
2022-01-26 16:09:50 default[fixeddev] OpenBLAS WARNING - could not determine the L2 cache size on this system, assuming 256k
2022-01-26 16:09:53 default[fixeddev] 2022-01-26 08:09:53,151 common.views INFO Application started
Куда мне обратиться, чтобы получить больше информации о том, что на самом деле происходит во время этих сбоев? Я относительно новичок в GAE и чувствую, что отлаживаю вслепую, поскольку не могу воспроизвести эту проблему на локальной машине разработчиков, и никакие исключения не регистрируются. Каждый сбой просто выдает 500.
Не связанный с бонусным раундом вопрос: кто-нибудь знает, как справиться с предупреждениями OpenBLAS? Это реальная проблема или просто неприятность, которую я не могу подавить?
Код ошибки движка приложения 500 (Internal Server Error), почти всегда означает, что ваш код python бросил нерукопожатное исключение, которое было поймано средой выполнения.
Зайдите на приборную панель App Engine и посмотрите ошибки - ошибка клиента, ошибка сервера.
Из сообщения об ошибке, которое вы получили, следует, что ваше приложение использует больше памяти, чем может обработать ваш экземпляр. Это вызывает ошибку, связанную с нехваткой памяти.
Единственная ошибка, которую вы получите:
2022-01-26 16:09:50 default[fixeddev] OpenBLAS WARNING - не удалось определить размер кэша L2 в этой системе, предполагается 256k
.
Ваше приложение может оставаться работоспособным. Я рекомендую вам изменить класс instance class, чтобы иметь больше доступной памяти и избежать ошибки.