There is some standart stack to run django in production. For python 2, it is nginx + gunicorn or uwsgi + monkey patching libs, such as gevent or eventlet. Generally, I prefer gunicorn + eventlet, but when you switch (or start) django project on latest python 3.5, eventlet can do some bad magic. And you can switch to a new built-in mechanism, called aiohttp. Based on gunicorn docs, you need simply switch worker to gaiohttp and that’s all.

Then, something bad happens.

Answer is very simple: you write some memoryleaking code gaiohttp ignores max_requests option. In other words, workers won’t be killed after max_requests count. After some search on internet, there is an article from asyncio contributor about copy-n-pasting worker from aiohttp repo to gunicorn. Aiohttp docs says that you should use aiohttp.worker.GunicornWebWorker, but when you switch setting there will be error.

[5898] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "./gunicorn/arbiter.py", line 557, in spawn_worker
    worker.init_process()
  File "./aiohttp/worker.py", line 37, in init_process
    super().init_process()
  File "./gunicorn/workers/base.py", line 132, in init_process
    self.run()
  File "./aiohttp/worker.py", line 40, in run
    self.loop.run_until_complete(self.wsgi.startup())
AttributeError:
    'WSGIHandler' object has no attribute 'startup'

So aiohttp.worker.GunicornWebWorker differs from standart wsgi app for django. Luckily, python community has two packages to overcome these difficulties: aiohttp-wsgi and aiodjango, add them to your requirements.txt. After this modify your wsgi.py according to docs:

import os

from django.core.wsgi import get_wsgi_application

from aiodjango import get_aio_application


os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'settings')

# Build WSGI application
# Any WSGI middleware would be added here
application = get_wsgi_application()

# Build aiohttp application
app = get_aio_application(application)

That’s all folks.