2013-10-10 3 views
0

현재 django + uwsgi + nginx 설치 프로그램을 사용하여 웹 응용 프로그램을 서버에 설치합니다. 장황한 python 코드로 인해 죽는다면 현재 프로세스 재 구축에 문제가 있습니다.uwsgi 프로세스가 다시 생성되지 않습니다.

나는 가난한 코더로 인해 많은 일이 발생합니다. 나는 uwsgi가 단지 죽은 과정을 부활시킬 것이라고 생각했습니다. 다음과 같이

내 구성 파일은 다음과 같습니다 내 UWSGI 파일 :

[uwsgi] 
# variables 
projectname = testapp 
base = /home/ubuntu/testapp 
# config 
protocol = uwsgi 
pythonpath = %(base)/src/%(projectname) 
module = %(projectname).wsgi 
socket = /tmp/%(projectname).sock 
logto = %(base)/logs/uwsgi.log 

chmod-socket = 777 
processes = 2 
master = 1 
harakiri-verbose = true 

내 nginx를 파일 :

server { 
    listen 80; 
    server_name mytestserver; 
    location/{ 
    include uwsgi_params; 
    uwsgi_read_timeout 300; 
    uwsgi_pass unix:///tmp/testapp.sock; 

    } 
    access_log /home/ubuntu/testapp/logs/access.log; 
    error_log /home/ubuntu/testapp/logs/error.log; 
} 

나는의 nginx와 uwsgi 모두있는 init.d 파일을했다. 황제 모드로 내 uwsgi를 관리합니다. 내가 (그것의/etc/uwsgi/하인에 심볼릭 링크) 내 uwsgi.ini 파일을 보관 폴더로 포인트

다음과 같이 내 UWSGI 로그는 다음과 같습니다 는 PID 번호를 참고 : 나는 12363 및 12365, 프로세스 시작 , 내 장고 코드 Why die here now에서 인쇄 메시지를 얻은 다음 프로세스 12363 만 남았습니다. 그러면 프로세스가 종료됩니다. 내 웹 응용 프로그램은 아무것도로드를 거부

[pid: 12365|app: 0|req: 85/174] 123.123.123.123() {32 vars in 414 bytes} [Thu Oct 10 02:31:58 2013] POST /test1=> generated 9 bytes in 4 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0) 

[pid: 12365|app: 0|req: 86/175] 123.123.123.123() {32 vars in 414 bytes} [Thu Oct 10 02:31:58 2013] POST /test1 => generated 9 bytes in 3 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0) 

[pid: 12363|app: 0|req: 87/176] 123.123.123.123() {32 vars in 414 bytes} [Thu Oct 10 02:31:59 2013] POST /test1 => generated 9 bytes in 4 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0) 
why break here now? 

[pid: 12363|app: 0|req: 88/177] 123.123.123.123() {32 vars in 414 bytes} [Thu Oct 10 02:32:02 2013] POST /test1 => generated 9 bytes in 5 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0) 

[pid: 12363|app: 0|req: 89/178] 123.123.123.123() {32 vars in 414 bytes} [Thu Oct 10 02:32:02 2013] POST /test1 => generated 9 bytes in 7 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0) 

I uwsgi 황제 비록 하인을 리스폰 것 (그 부분은 의미가 있습니다)하지만 신하는 죽지 않았어? 나는 모든 것을 재시작 할 수 있으며, 모든 것이 잘 돌아 간다. 그러면 죽을 것이다.

답변

1

프로세스가 종료되면 로그에서 해당 프로세스의 종료에 대한 메시지가 표시됩니다. 프로세스가 단순히 멈추지 않는다고 확신합니까? 당신은 harakiri verbose를 가능하게했지만 harakiri가 아니기 때문에 멈추어진 요청을 모니터하지 않을 것입니다.

+0

흥미 롭습니다. 그래서 나는 uwsgi.ini에서 harakiri = 10을 설정했고, 다시 부활합니다 (제 생각에). 나는 지금 죽어서 다시 respawning 것을 본다. 나는 많은 "HARAKIRI : - wchan> sk_wait_data"를 얻는다. 이것은 타임 아웃 메시지이다. 그들은 내게 "/usr/lib/libpython2.7.so.1.0(+0x5c86d) [0x7f495638486d] /usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7f4956469053] /usr/lib/libpython2.7.so.1.0 (+ 0x12539f) [0x7f495644d39f] *** 백 트레이스 ***의 끝 *** 등 등 어떻게 그 감각을 만들까요? – user1639926

+0

상단 줄은 프로세스가 차단 된 syscall입니다. 로그에서 프로세스가 소켓 (아마도 느린 쿼리 또는 원격 서버에 대한 api http 트랜잭션)에서 기다리고있는 것처럼 보입니다. python tracebacker도 활성화하여 (uWSGI docs 확인) harakiri 중에 추적을 얻을 수 있습니다. 소켓 통신이있는 곳이 여러 곳이라면 부서진 지역을 찾는 것이 유용 할 수 있습니다. – roberto

관련 문제