Problém skončil tím, že se uwsgi rozdělil.
Při práci s více procesy s hlavním procesem uwsgi inicializuje aplikaci v hlavním procesu a poté zkopíruje aplikaci do každého pracovního procesu. Problém je, že pokud při inicializaci aplikace otevřete připojení k databázi, máte několik procesů sdílejících stejné připojení, což způsobuje výše uvedenou chybu.
Řešením je nastavit lazy konfigurační volba pro uwsgi, která vynutí úplné načtení aplikace v každém procesu:
lazyNastavte líný režim (načítání aplikací do pracovníků namísto hlavního).
Tato možnost může mít dopad na využití paměti, protože nelze použít sémantiku Copy-on-Write. Když je povoleno líné, pouze pracovníci budou znovu načteni pomocí signálů opětovného načtení uWSGI; mistr zůstane naživu. Změny konfigurace uWSGI jako takové nejsou při opětovném načtení masterem zachyceny.
K dispozici je také lazy-apps možnost:
lazy-appsNačtěte aplikace do každého pracovníka namísto hlavního.
Tato možnost může mít dopad na využití paměti, protože nelze použít sémantiku Copy-on-Write. Na rozdíl od lazy to ovlivní pouze způsob načítání aplikací, nikoli chování mastera při opětovném načítání.
Tato konfigurace uwsgi mi nakonec fungovala:
[uwsgi]
socket = /tmp/my_app.sock
logto = /var/log/my_app.log
plugins = python3
virtualenv = /path/to/my/venv
pythonpath = /path/to/my/app
wsgi-file = /path/to/my/app/application.py
callable = app
max-requests = 1000
chmod-socket = 666
chown-socket = www-data:www-data
master = true
processes = 2
no-orphans = true
log-date = true
uid = www-data
gid = www-data
# the fix
lazy = true
lazy-apps = true