Das Problem war letztendlich die Verzweigung von uwsgi.
Wenn Sie mit mehreren Prozessen mit einem Masterprozess arbeiten, initialisiert uwsgi die Anwendung im Masterprozess und kopiert dann die Anwendung auf jeden Arbeitsprozess. Das Problem ist, wenn Sie beim Initialisieren Ihrer Anwendung eine Datenbankverbindung öffnen, haben Sie dann mehrere Prozesse, die sich dieselbe Verbindung teilen, was den obigen Fehler verursacht.
Die Lösung besteht darin, lazy zu setzen Konfigurationsoption für uwsgi, die ein vollständiges Laden der Anwendung in jedem Prozess erzwingt:
lazy
Legen Sie den faulen Modus fest (laden Sie Apps in Worker statt in Master).
Diese Option kann Auswirkungen auf die Speichernutzung haben, da die Copy-on-Write-Semantik nicht verwendet werden kann. Wenn Lazy aktiviert ist, werden nur Worker durch die Reload-Signale von uWSGI neu geladen; Der Meister wird am Leben bleiben. Daher werden uWSGI-Konfigurationsänderungen beim Neuladen durch den Master nicht übernommen.
Es gibt auch lazy-apps Möglichkeit:
lazy-apps
Laden Sie Apps in jeden Worker anstelle des Masters.
Diese Option kann Auswirkungen auf die Speichernutzung haben, da die Copy-on-Write-Semantik nicht verwendet werden kann. Im Gegensatz zu Lazy wirkt sich dies nur auf die Art und Weise aus, wie Anwendungen geladen werden, nicht auf das Verhalten von Master beim Neuladen.
Diese uwsgi-Konfiguration hat bei mir funktioniert:
[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
