2011-10-14 14 views
26

Django registra las operaciones de SQL en un búfer interno (ya sea que se registre en un archivo o no) cuando settings.DEBUG = True. Debido a que tengo un proceso de larga ejecución que realiza muchas operaciones DB, esto hace que mis instancias de modo de desarrollo del programa crezcan en consumo de memoria muy rápidamente.apague el registro de SQL mientras mantiene los ajustes. ¿ERROR?

Me gustaría deshabilitar el mecanismo interno de registro de SQL a la vez que dejé ajustes. ENCENDIDO ENCENDIDO para mi desarrollo: ¿es esto posible?

Django versión 1.3.0.

Respuesta

23

Cuando settings.DEBUG es True, Django utiliza CursorDebugWrapper en lugar de CursorWrapper. Esto es lo que agrega las consultas a connection.queries y consume memoria. Me mono-parchear el envoltorio de conexión para utilizar siempre CursorWrapper:

from django.conf import settings 
from django.db.backends import BaseDatabaseWrapper 
from django.db.backends.util import CursorWrapper 

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

deshabilitar el registro al igual que otros sugieren que no se solucionará el problema, porque CursorDebugWrapper aún almacena las consultas en connection.queries incluso si el registro está apagado.

+11

¿A dónde va esto? Si agrego esto a settings.py obtengo el siguiente 'ImportError: la configuración no se puede importar porque la variable de entorno DJANGO_SETTINGS_MODULE no está definida. Cuando intento ejecutar' from django.db.backends import BaseDatabaseWrapper'. – Nathan

38

Sí, puede silenciar el registro de sql al asignar un 'controlador nulo' al registrador llamado 'django.db.backends'. Supongo que usa django's new dict-based logging setup? Si es así, este fragmento debería hacer más fácil:

... 
    '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', 
      }, 
    ... 

Actualización: vistazo a la respuesta de Brian, también. Entendí que "registrar" significaba el registro irritante de cada declaración sql. Brian habla sobre el registro de la memoria interna de cada consulta (y supongo que es :-) derecho

+0

gran respuesta, esto es mucho más fácil y soluciona el problema más común de los archivos de registro en DEPURACIÓN = modo verdadero que se obstruye con las declaraciones de SQL. – RichVel

+0

La versión de Django que estoy usando (1.9) - en lugar de 'manejadores': ['null'] Reemplacé con None para 'handlers': Ninguna – jonprasetyo

+2

en versiones de Django> = 1.9, 'django.utils.log.NullHandler' ya no existe. Use 'logging.NullHandler' en su lugar. – lsh

4

Esto funcionó para mí (al menos para Django 1.3.1):

from django.db import connection 
connection.use_debug_cursor = False 

he encontrado que la variable inspeccionar el código fuente de Django (no está documentado), las líneas relevantes se encuentran en django/db/backends/__init__.py (BaseDatabaseWrapper clase):

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 
3

Si todavía está interesado en la localización de las operaciones de SQL para propósitos de depuración, puede listar connection.queries también limpia periódicamente para reclamar mem ory:

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 = [] 
Cuestiones relacionadas