lỗi cơ sở dữ liệu ngẫu nhiên với Django 1,7, uwsgi và PostgreSQL

Question

Sau khi nâng cấp ứng dụng Django 1,6 của tôi để Django 1,7 Tôi bắt đầu để có được sai số ngẫu nhiên trong khi lấy dữ liệu từ 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' 

Khi tôi nhanh chóng mở 10 tab trong trình duyệt, một nửa số tab tải bình thường, một nửa trong số đó nhận được lỗi DB. Khi tôi làm mới các tab có lỗi xảy ra, chúng sẽ tải bình thường.

Tôi đang chạy Django qua uwsgi và nginx, phiên bản psycopg2 là 2.5.4.

Nhìn chung, có vẻ như giao tiếp bằng cách nào đó với Postgres hoàn toàn bị hỏng và kết quả của các truy vấn khác nhau bị lẫn lộn.

---

Edit:

Sau vài giờ xử lý sự cố tôi phát hiện ra những điều sau đây:

Django 1.6 + uwsgi - công trình
Django 1,7 + gunicorn - công trình
Django 1,7 + uwsgi - doesn 't làm việc, ném lỗi cơ sở dữ liệu. Vì vậy, vấn đề có vẻ là với sự kết hợp đặc biệt uwsgi và Django 1,7. Đó là lạ, tôi có một dự án Django 1,7 chạy trên cùng một máy chủ với cùng một uwsgi và nó không có vấn đề.

Bất kỳ ý tưởng nào?

(tôi không thực sự quan tâm chuyển đổi sang gunicorn, có lẽ sẽ phải đi theo con đường này, nhưng nó vẫn còn thú vị tại sao điều này xảy ra)

---

Cập nhật 2: kiểm tra chặt chẽ hơn cho thấy điều hoàn toàn điên rồ xảy ra bên trong Django, giống như khóa chính của mô hình được thay thế bằng session_id của người dùng hiện tại (đó là nguồn "lỗi không hợp lệ cho int() với lỗi cơ sở 10") và truy vấn phát hành của Django đối với DB "quên" để chỉ định mệnh đề WHERE. Tôi có lẽ sẽ gọi đó là một tham nhũng của một số loại.

---

Cập nhật 3: Chúng tôi chuyển từ uwsgi để gunicorn và những vấn đề hiện nay đã mất hết. Mọi thứ đều hoạt động tốt. Tôi có lẽ vẫn đang tìm kiếm một giải pháp thích hợp mặc dù.

Answer 1

Tôi nghĩ rằng lazy-apps=true nên thực hiện thủ thuật. Từ tài liệu uwsgi:

uWSGI cố gắng (ab) sử dụng ngữ nghĩa Sao chép ghi của nĩa() bất cứ khi nào có thể. Theo mặc định nó sẽ ngã ba sau khi đã tải các ứng dụng của bạn để chia sẻ càng nhiều bộ nhớ của họ càng tốt. Nếu hành vi này là không mong muốn vì một số lý do, hãy sử dụng tùy chọn ứng dụng lười biếng. Điều này sẽ hướng dẫn uWSGI tải các ứng dụng sau mỗi ngã ba của nhân viên(). Hãy coi chừng như có một lựa chọn lớn tuổi tên là lười biếng đó là cách xâm lấn hơn và nản chí cao (nó vẫn còn ở đây chỉ để tương thích ngược)

Nếu bạn không chuyển lazy-apps trên, người lao động sẽ chia sẻ bộ nhớ, và nhiều khả năng tham nhũng:

khóa chính của mô hình được thay thế bằng session_id của người dùng hiện tại.

Khi nói đến kết nối và nội dung, không đặt lazy-apps là nguy hiểm.

Hạn chế là mỗi nhân viên sẽ có một hồ bơi kết nối đầy đủ (nếu kết nối tổng hợp đang diễn ra), và bạn có thể sẽ sử dụng rất nhiều kết nối.

Tôi không phải là chuyên gia về python, nhưng tôi nghĩ sử dụng thứ gì đó như gevent để xử lý kết nối tổng hợp theo cách tập trung. Bạn thậm chí có thể không cần lazy-apps.