errori del database casuali con Django 1.7, uwsgi e PostgreSQL

Question

Dopo l'aggiornamento il mio Django 1.6 app per Django 1.7 Ho cominciato ad avere errori casuali durante il recupero dei dati da PostgreSQL:

DatabaseError: server sent data ("D" message) without prior row description ("T" message) 
lost synchronization with server: got message type "�", length -1244613424 

DatabaseError: lost synchronization with server: got message type "0", length 842674226 

ProgrammingError: no results to fetch 

ValueError: invalid literal for int() with base 10: 'feuj3f47jvsdv7tgnj43g63j' 

Quando ho subito aperto 10 schede nel browser, metà delle schede si caricano normalmente, metà di esse riceve un errore DB. Quando aggiorno le schede in cui si sono verificati gli errori, vengono caricati normalmente.

Sto eseguendo Django tramite uwsgi e nginx, la versione di psycopg2 è 2.5.4.

Nel complesso sembra che in qualche modo la comunicazione con Postgres sia completamente interrotta e che i risultati di diverse query si mischino.

---

Edit:

Dopo diverse ore di risoluzione dei problemi ho scoperto quanto segue:

Django 1.6 + uwsgi - Lavori
Django 1.7 + gunicorn - Lavori
Django 1.7 + uwsgi - doesn funziona, genera errori nel database. Quindi il problema sembra essere in particolare con uwsgi e combinazione Django 1.7. Il che è strano, ho un altro progetto Django 1.7 in esecuzione sullo stesso server con lo stesso uwsgi e non ha problemi.

Qualche idea?

(io in realtà non mi importa di passare a gunicorn, probabilmente dovrà andare in questo modo, ma è comunque interessante perché sta succedendo questo)

---

Aggiornamento 2: Un esame più attento mostra cose completamente folli accadono all'interno di Django, come la chiave primaria di un modello che viene sostituita con session_id dell'utente corrente (che è l'origine di "letterale non valido per int() con errore di base 10") e Django che invia query a DB "dimenticando" per specificare la clausola WHERE. Probabilmente lo chiamerei corruzione di memoria di qualche tipo.

---

Aggiornamento 3: Siamo passati da uwsgi a gunicorn e ora i problemi non ci sono più. Tutto funziona alla grande. Probabilmente sto ancora cercando una soluzione adeguata.

Answer 1

Penso che lazy-apps=true dovrebbe fare il trucco. Dalla documentazione uwsgi:

uWSGI tenta di (ab) utilizzare la semantica Copy On Write della chiamata a fork() quando possibile. Per impostazione predefinita, verrà biforco dopo aver caricato le tue applicazioni per condividere quanto più possibile della loro memoria. Se questo comportamento non è desiderabile per qualche motivo, utilizzare l'opzione lazy-apps. Questo istruirà uWSGI a caricare le applicazioni dopo il fork di ogni worker(). Attenzione in quanto v'è un vecchio opzioni con un nome pigro che è molto più invasivo e altamente scoraggiato (è ancora qui solo per la compatibilità a ritroso)

Se non si accende lazy-apps in poi, i lavoratori condivideranno la memoria, e molto probabilmente corrotto:

la chiave primaria di un modello viene sostituita con session_id dell'utente corrente.

Quando si tratta di connessioni e cose, non impostare lazy-apps è pericoloso.

Lo svantaggio è che ogni lavoratore avrà un pool di connessione completo (se il pool di connessioni è in corso) e si potrebbe finire con l'utilizzo di molte connessioni.

Non sono un esperto di Python, ma penso di usare qualcosa come gevent per gestire il pool di connessioni in modo centralizzato. Potresti anche non aver bisogno di lazy-apps.