losowe błędy bazy danych z Django 1.7, uwsgi i PostgreSQL

Question

Po uaktualnieniu mojego Django 1.6 aplikację Django 1.7 zacząłem się losowe błędy podczas pobierania danych z 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' 

Kiedy szybko otwarte 10 zakładki w przeglądarce, połowa kart ładuje się normalnie, połowa z nich otrzymuje błąd DB. Gdy odświeżam karty, w których wystąpiły błędy, ładują się normalnie.

Używam Django przez uwsgi i nginx, wersja psycopg2 to 2.5.4.

Ogólnie wygląda na to, że komunikacja z Postgres jest całkowicie zepsuta, a wyniki różnych zapytań mieszają się.

---

Edit:

Po kilku godzinach rozwiązywania problemów dowiedziałem się, co następuje:

Django 1.6 + uwsgi - działa
Django 1.7 + gunicorn - działa
Django 1.7 + uwsgi - nie robi działa, generuje błędy bazy danych. Tak więc wydaje się, że problem dotyczy właśnie kombinacji uwsgi i Django 1.7. Co jest dziwne, mam inny projekt Django 1.7 działający na tym samym serwerze z tymi samymi uwsgi i nie ma problemów.

Wszelkie pomysły?

(nie mam nic przeciwko przełączeniu na gunicorn, prawdopodobnie będzie musiał przejść w ten sposób, ale to wciąż interesujące, dlaczego tak się dzieje)

---

Aktualizacja 2: Dokładniejsza analiza pokazuje zupełnie szalone rzeczy dzieje wewnątrz Django, tak jak klucz podstawowy modelu jest zastąpiony bieżącym użytkownikiem id_sesji (to jest źródłem "nieprawidłowej literału dla int() z błędem base 10") i Django wysyłającym zapytania do DB "zapominając", aby określić klauzulę WHERE. Prawdopodobnie nazwałbym to jakąś korupcją pamięci.

---

Aktualizacja 3: Przełączyliśmy się z uwsgi na gunicorn i problemy już się skończyły. Wszystko działa świetnie. Prawdopodobnie wciąż szukam odpowiedniego rozwiązania.

Answer 1

Myślę, że powinienem załatwić sprawę: lazy-apps=true. Z dokumentacji uwsgi:

uWSGI próbuje (ab) użyć semantyki kopiowania przy zapisie wywołania fork(), gdy tylko jest to możliwe. Domyślnie rozwidla się po załadowaniu aplikacji, aby udostępnić jak najwięcej ich pamięci. Jeśli to zachowanie jest niepożądane z jakiegoś powodu, użyj opcji leniwych aplikacji. Spowoduje to, że uWSGI załaduje aplikacje po fork każdego pracownika(). Strzeż się, jak tam jest starszy opcje nazwane leniwy, że jest bardziej inwazyjna i bardzo zniechęcony (wciąż jest tu tylko dla wstecznej kompatybilności)

Jeśli nie przełączyć lazy-apps na robotnicy będą dzielić pamięć i najprawdopodobniej uszkodzony:

klucz podstawowy modelu zastąpiony przez identyfikator sesji bieżącego użytkownika.

Jeśli chodzi o połączenia i inne rzeczy, ustawienie lazy-apps jest niebezpieczne.

Wadą tego rozwiązania jest to, że każdy pracownik będzie miał pełną pulę połączeń (jeśli ma miejsce łączenie połączeń) i może się skończyć używanie wielu połączeń.

Nie jestem ekspertem od Pythona, ale myślę, że używam czegoś takiego jak gevent do obsługi puli połączeń w sposób scentralizowany. Możesz wtedy nawet nie potrzebować lazy-apps.