Django 구덩이 밟 기 시리즈 (1): 네트워크 요청 시간 초과
최근 작업 중 에 이상 한 문제 가 발생 했 습 니 다. 어떤 논리 에 가끔 이상 이 생 길 수 있 지만 하필 이면 error log 가 보이 지 않 습 니 다.
코드 를 보 니 네트워크 요청 의 논리 가 있 습 니 다.
resp = urlopen(url)
중요 한 인자 인 timeout 을 무시 합 니 다. urlopen 은 socket defaulttimout 를 기본적으로 읽 습 니 다.socket 도 설정 되 어 있 지 않 으 면 오류 가 발생 할 때 까지 기 다 려 달라 고 요청 합 니 다.
>> socket.getdefaulttimeout()
>> None
소홀 한 것 같 습 니 다. 이상 한 점 은 요청 이 잘못 되 었 다 는 것 을 볼 수 없다 는 것 입 니 다!!오류 신고 가 없 으 면 오류 로 그 를 볼 수 없고 오류 로그 가 없 으 면 자동 으로 신고 할 수 없어 이 문제 가 드러나 지 않 았 다.
로 그 를 계속 연구 하 다가 뒤쪽 에서 이상 을 발 견 했 습 니 다. 네트워크 요청 을 한 log 와 30s 차이 가 났 습 니 다.
[2017-01-04 12:00:54 +0000] [1260] [CRITICAL] WORKER TIMEOUT (pid:19348)
[2017-01-04 12:00:54 +0000] [19348] [INFO] Worker exiting (pid: 19348)
[2017-01-04 12:00:54 +0000] [19417] [INFO] Booting worker with pid: 19417
네, gunicorn worker 가 시간 을 초과 하여 재 개 되 었 습 니 다.
원인: gunicorn worker 기본 Timeout 은 30 초 입 니 다. 네트워크 가 30 초 이상 막 히 면 worker 는 자동 으로 다시 시작 합 니 다. 그러면 네트워크 시간 초과 오류 가 영원히 보이 지 않 습 니 다.
해결 방법:
1. gunicorn 기본 시간 초과 수정 (시작 매개 변수 에 추가, 필요 에 따라 수정)
--timeout 60
2. 비 비동기 네트워크 요청 은 timeout 인 자 를 추가 해 야 하 며, gunicorn worker 시간 초과 와 같 을 수 없습니다.
요약: 모든 view 작업 시간 에 관심 을 가 져 야 합 니 다. 시간 이 오래 걸 리 는 임 무 는 비동기 임 무 를 수행 하 는 것 을 권장 합 니 다 (예 를 들 어 Celery 사용).
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.