Django Запрос БД становится «Нет», как показано с DEBUG = True внутри долго выполняющейся команды управления - PullRequest
0 голосов
/ 29 мая 2020

Я использую Django 2.2 в нескольких режимах, один из которых - это длительная команда управления, которая выполняется под Supervisord для обработки входящих сообщений Slack. Это отлично сработало после нескольких недель тестирования. Однако сегодня я стал свидетелем чего-то тревожного, чего не могу объяснить.

Я запускаю все это в ТЕСТОВОЙ среде, поэтому у меня DEBUG установлено на True, а также увеличились уровни отладки моего регистратора. Благодаря этому я могу видеть каждый запрос к БД и иметь хорошее представление о том, где возникла проблема.

Задача работала нормально около 17 часов, что является ничем по сравнению с тем, как долго она успешно выполнялась в прошлое (много дней). Произошло то, что фактический запрос, который должен был отправить go в БД, стал пустым или пустым. В журнале БД он отображается как «Нет». Запрос представляет собой простой фильтр объектов:

if not bool(SlackChannel.objects.filter(id=event['channel'])):
    return

Вот то, что он начал показывать:

2020-05-29 10:58:36,001 DEBUG utils (0.000) None; args=('SKFHJ7H5S6',)

который, когда все хорошо, должен выглядеть примерно так:

2020-05-29 10:58:36,001 DEBUG utils (0.000) SELECT `item`.`id`, `item`.`name`, `item`.`info` FROM `item` WHERE `item`.`id` = 'SKFHJ7H5S6'; args=('SKFHJ7H5S6',)

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

Также примечание ... У меня есть 2 потока в этой задаче. Запросы продолжали нормально работать в другом потоке (хотя эти запросы относятся к совершенно другим объектам) даже после того, как поток с этой проблемой начал проявляться. Кроме того, другие Django задачи, которые у меня есть + веб-сервер, все продолжали нормально работать.

Что могло вызвать это?

1 Ответ

0 голосов
/ 02 июля 2020

После некоторых встреч с разработчиком Slack Client API и некоторого дополнительного тестирования я пришел к выводу, что существует очень высокая вероятность того, что это вызвано плохим взаимодействием между Slack Client и Django. Возможно, это связано с asyn c, так как Django 2.2 не поддерживает asyn c, хотя я запускаю Slack Client в «режиме syn c».

Разработчик Slack Client посоветовал решить, как отделить обработку сообщений Django от приема сообщений с помощью Q, с чем я согласен. Однако, имея уже реализованный другой подход, более быстрое решение, которое, кажется, работает> 99% времени, заключалось в том, чтобы Supervisord автоматически перезапускал процесс на ежечасной основе. Если вы собираетесь строить решение с этими двумя модулями с нуля, вам следует рассмотреть подход Q.

...