36👍
Celery doesn’t have a memory leak, it’s how Django works:
When DEBUG is enabled Django appends every executed SQL statement to django.db.connection.queries
, this will grow unbounded in a long running process environment.
I guess you could use a hack like:
if "celeryd" in sys.argv:
DEBUG = False
6👍
The hack from @asksol didn’t do it for me, I had to do
if "celery" in sys.argv[0]:
DEBUG = False
Because sys.argv is something like ['/path/to/celery', 'worker', '-A', 'app']
Im using python 3.6 and celery 4
- Group models in django admin
- Django: set cookie on test client?
- Provide tab title with reportlab generated pdf
- Installing Django with pip
1👍
Building off of asksol’s answer (https://stackoverflow.com/a/4806384/3009897) in light of sww314’s comment on that answer, that the indicated method does not work in Celery 4.x, one can instead rely on the inspect module to determine the execution stack that the DEBUG setting is being accessed in.
For my purposes, the following change worked:
if DEBUG and 'celery' in inspect.stack()[-1][1]:
DEBUG = False
This assumes that the outermost invocation frame will include the string ‘celery’ in the associated filepath. (The check for DEBUG is a stab at ensuring that if this is left in place for production (where DEBUG = False should be set), the inspect shouldn’t take place.)
- Store browser tab specific data
- Django test: TransactionManagementError: You can't execute queries until the end of the 'atomic' block
- Using Django Login Required Mixin