Apache không phản hồi + mod_wsgi sau khi cài đặt scipy

10

Tôi hiện đang chạy máy chủ Centos 6.4, với Apache 2.2.15 và mod_wsgi 3.2. Máy chủ đang lưu trữ một trang web dựa trên django (django 1.5.1, python 2.6.6). Mọi thứ đều chạy tốt cho đến khi tôi cài đặt scipy 0.12.0 qua pip. Bây giờ, khi tôi cố tải ứng dụng django, máy chủ không phản hồi và có vẻ như các tiến trình httpd con được sinh ra bị treo. Nhìn qua nhật ký của tôi (/ var / log / httpd / error_log, vhost error.log và nhật ký hệ thống của tôi) không có lỗi.

Nếu tôi tải các mô hình của mình, v.v. thông qua trình quản lý django, mọi thứ đều hoạt động tốt, điều đó khiến tôi tin rằng đó là sự cố mod_wsgi.

Bất kỳ suy nghĩ về làm thế nào để bắt đầu xử lý sự cố này?

apache-2.2 python mod-wsgi

— Đánh dấu
nguồn

22

Một số gói bên thứ ba dành cho Python sử dụng các mô-đun mở rộng C và bao gồm cả scipy và numpy, sẽ chỉ hoạt động trong trình thông dịch chính của Python và không thể được sử dụng trong các trình thông dịch phụ như mod_wsgi theo cách sử dụng theo mặc định. Kết quả có thể là bế tắc luồng, hành vi không chính xác hoặc xử lý sự cố. Đây là chi tiết trong:

http://code.google.com.vn/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Cách giải quyết là buộc ứng dụng WSGI chạy trong trình thông dịch chính của quy trình bằng cách sử dụng:

WSGIApplicationGroup %{GLOBAL}

Nếu chạy nhiều ứng dụng WSGI trên cùng một máy chủ, bạn sẽ muốn bắt đầu điều tra bằng chế độ daemon vì một số khung không cho phép nhiều phiên bản chạy trong cùng một trình thông dịch. Đây là trường hợp với Django. Do đó, sử dụng chế độ daemon để mỗi cái nằm trong tiến trình riêng của nó và buộc mỗi cái chạy trong trình thông dịch chính của các nhóm quy trình chế độ daemon tương ứng của chúng.

— Graham Dumpleton
nguồn

Xin chào Graham, bạn có thể cập nhật câu trả lời này trong bối cảnh các phiên bản mod-wsgi mới hơn không? Cụ thể, đây có phải là sự cố theo mặc định nếu tôi đã định cấu hình apache bằng mod_wsgi-express không? Trong httpd.conftệp được tạo , WSGIApplicationGroupkhông được sử dụng. Tuy nhiên, có application-group=${GLOBAL}trong <IfDefine ONE_PROCESS>và <IfDefine !ONE_PROCESS>khối. Tôi thấy một lệnh WSGIDaemonProcess trong httpd.conftệp được tạo . Điều đó có nghĩa là nó đã sử dụng chế độ daemon theo mặc định?

— Kal

Nếu bạn sử dụng mod_wsgi-express start-serverhoặc tích hợp Django cho mod_wsgi-express, nó sẽ chạy với chế độ daemon như mặc định và sử dụng trình thông dịch chính. Vì vậy, đây không phải là một vấn đề trong trường hợp đó. Nếu bạn cấu hình thủ công Apache, thì đó vẫn là một vấn đề. Phần ONE_PROCESSnày chỉ dành cho khi bạn buộc nó vào chế độ gỡ lỗi, trong trường hợp đó, nó chạy trong chế độ nhúng đơn. Nó vẫn chạy trong trình thông dịch chính mặc dù.

— Graham Dumpleton

Các application-grouptùy chọn trên WSGIScriptAliaslà một sự thay thế cho việc sử dụng WSGIApplicationGroup.

— Graham Dumpleton

3

Một giải pháp khác phù hợp với cách cấu hình WSGI của tôi là thay đổi WSGIScriptAliasdòng:

WSGIDaemonProcess website user=user group=group python-path=/path/to/venv/website:/path/to/venv/lib/python2.7/site-packages
WSGIScriptAlias /website /path/to/venv/website/wsgi.py process-group=website application-group=%{GLOBAL}

<Location /website>
        WSGIProcessGroup website
</Location>

<Directory /path/to/venv/website>
        WSGIScriptReloading On
        <Files wsgi.py>
                Allow from all
                Require all granted
        </Files>
</Directory>

lưu ý các thuộc tính

process-group=website application-group=%{GLOBAL}

thường không bắt buộc

— Nils Werner
nguồn

1

Bạn có thể bỏ chỉ thị WSGIScriptReloading khi mặc định đó bật và thường không bao giờ cần phải tắt. Do sử dụng tùy chọn nhóm quy trình cho WSGIScriptAlias, bạn cũng có thể bỏ chỉ thị WSGIProcessgroup.

— Graham Dumpleton