отключите ведение журнала SQL при сохранении настроек.ОТЛАДКА?

ProgramBox

отключите ведение журнала SQL при сохранении настроек.ОТЛАДКА?

Post author:admin
Запись опубликована:8 марта, 2023
Post category:Вопросы по программированию

#sql #django #logging

#sql #django #ведение журнала

Вопрос:

Django записывает операции SQL во внутренний буфер (независимо от того, записывается ли запись в файл или нет) при настройке.DEBUG=True . Поскольку у меня длительный процесс, который выполняет много операций с БД, это приводит к тому, что мои экземпляры программы в режиме разработки очень быстро увеличивают потребление памяти.

Я хотел бы отключить внутренний механизм ведения журнала SQL, оставив настройки.ОТЛАДКА включена для моей разработки: возможно ли это?

Версия Django 1.3.0.

Ответ №1:

Да, вы можете отключить ведение журнала sql, назначив «нулевой обработчик» регистратору с именем «django.db.backends». Я предполагаю, что вы используете новую настройку ведения журнала django на основе dict? Если это так, этот фрагмент должен упростить:

     ...
    'handlers': {
        'null': {
            'level': 'DEBUG',
            'class':'logging.NullHandler',
            },
    ...
    'loggers': {
        ... your regular logger 'root' or '' ....
        'django.db.backends': {
            'handlers': ['null'],  # Quiet by default!
            'propagate': False,
            'level':'DEBUG',
            },
    ...

Обновление: посмотрите также на ответ Брайана. Я понял, что «ведение журнала» означает раздражающее ведение журнала каждого оператора sql. Брайан говорит о регистрации каждого запроса во внутренней памяти (и я думаю, он прав 🙂

1. отличный ответ, это намного проще и устраняет наиболее распространенную проблему, связанную с тем, что файлы журналов в режиме DEBUG = True забиты операторами SQL.

2. Версия Django, которую я использую (1.9) — вместо «обработчиков»: [‘null’] Я заменил на None, поэтому «обработчики»: Нет

3. в версиях Django> = 1.9 django.utils.log.NullHandler больше не существует. Используйте logging.NullHandler вместо этого.

Ответ №2:

Когда настройки.Значение DEBUG верно, Django использует CursorDebugWrapper вместо CursorWrapper . Это то, что добавляет запросы к соединению.запрашивает и потребляет память. Я бы исправил оболочку соединения, чтобы всегда использовать CursorWrapper:

 from django.conf import settings
from django.db.backends.base.base import BaseDatabaseWrapper
from django.db.backends.utils import CursorWrapper

if settings.DEBUG:
    BaseDatabaseWrapper.make_debug_cursor = lambda self, cursor: CursorWrapper(cursor, self)

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

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

1. Куда это ведет? Если я добавлю это ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined. в settings.py При попытке выполнить я получаю следующее from django.db.backends import BaseDatabaseWrapper .

2. В последних версиях Django пути импорта изменились: from django.db.backends.base.base import BaseDatabaseWrapper и from django.db.backends.utils import CursorWrapper

3. У меня тот же вопрос, что и у @Nathan. Где должна быть размещена эта конфигурация? Кроме того, как сказал bbmhmmad, для последних версий он кажется устаревшим.

Ответ №3:

Это сработало для меня (по крайней мере, для Django 1.3.1):

 from django.db import connection
connection.use_debug_cursor = False

Я обнаружил, что переменная проверяет исходный код Django (это не задокументировано), соответствующие строки находятся в django/db/backends/__init__.py ( BaseDatabaseWrapper class):

 def cursor(self):
    if (self.use_debug_cursor or
        (self.use_debug_cursor is None and settings.DEBUG)):
        cursor = self.make_debug_cursor(self._cursor())
    else:
        cursor = util.CursorWrapper(self._cursor(), self)
    return cursor

Ответ №4:

Если вы все еще заинтересованы в отслеживании операций SQL для целей отладки, вы также можете очистить соединение.запросы периодически отображаются для освобождения памяти:

 from django.db import connection

for i in range(start, count, size):
    objects = MyModel.objects.order_by('pk').all()[i:i   size]
    ...
    print connection.queries
    connection.queries = []

Ответ №5:

Django 3.0.7

Изменить

 def queries_logged(self):
    self.force_debug_cursor or settings.DEBUG

Для

 def queries_logged(self):
    return False

в django/db/backends/base/db.py