우리 애플리케이션의 구성에서 nginx는 gunicorn.
우리 애플리케이션은 일반적으로 작은 응답으로 프런트엔드 요청에 응답하지만 일부 엔드포인트는 메모리 페이지(4K)보다 큰 응답을 생성합니다.
이런 일이 발생하면 nginx는 다음 경고를 기록합니다.
an upstream response is buffered to a temporary file
/path/to/nginx/proxy_temp/4/86/0000000864 while reading upstream,
client: 1.2.3.4, server: api.ourdomain.com, request: "GET /pdf/..."
nginx 로그는 결국 이 경고로 가득 차게 됩니다. 제가 아는 한, 로그에서 이 경고를 사라지게 하는 유일한 해결책은 다음과 같습니다.나쁜 해결책:
nginx를 0으로 설정할 수 있습니다
proxy_max_temp_file_size. 기본적으로 대규모 응답의 버퍼링을 비활성화합니다. 이렇게 하면 파일에 대한 버퍼링이 중지됩니다. 그러나 이는 또한 큰 응답을 생성하는 엔드포인트(예: 1-2MB 응답을 생성하는 PDF 생성 응답)의 경우 느리게 소비하는 클라이언트가 해당 gunicorn 작업자를 지연시킬 수 있음을 의미합니다... 실제로 N명의 Gunicorn 작업자라면 느린 네트워크 연결 뒤에서 PDF를 생성하는 N개의 클라이언트만 필요하며 우리 애플리케이션은 다운될 것입니다...proxy_buffer_size4K 이상(즉, 하나의 메모리 페이지)으로 늘릴 수 있습니다 . 나는 이것이 nginx 성능에 심각한 영향을 미칠 것이라고 확신합니다. 우리 응답의 70%가 실제로 4K에 적합하며 nginx가 할당하도록 강제할 것입니다. 무엇을? 가끔씩 발생하는 PDF 생성 요청에 대비하기 위해 각 버퍼에 2MB의 버퍼가 필요합니까? 편집하다: 사실 이것은 전혀 옵션이 아닙니다. Michael(아래)은 허용되는 값은 4K와 8K뿐이라고 언급했습니다.끌 수도 있지만
proxy_buffering이는 첫 번째 해결 방법만큼 나쁩니다(느린 클라이언트 => 사망).
본질적으로 nginx는 우리가 원하는 것에 대한 로그를 넘치게 합니다. 즉, 응답이 클 때 파일에 대한 임시 버퍼링입니다.
우리는 단지 이것이 실제로 경고가 아닌 것으로 "표시"하여 로그가 범람하는 것을 막고 싶을 뿐입니다. (이것이 왜 경고인지는 잘 모르겠습니다. 어떤 "나쁜 것"에 대해 경고하는 것입니까?)
님의 소스 코드를 편집하고 다시 컴파일하는 것 외에 nginx제가 놓친 다른 해결 방법이 있나요?
답변1
이는 Nginx의 error_log 지시어에 대한 로그 수준의 결과입니다.
https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
error_log logs/error.log warn;
경고, 오류 위험, 경고 및 응급 수준의 메시지가 기록됩니다.
오류 로그의 기본 설정은 전역적으로 작동합니다. 이를 재정의하려면 기본(최상위) 구성 컨텍스트에 error_log 지시문을 배치하세요. 기본 컨텍스트의 설정은 항상 다른 구성 수준에 의해 상속됩니다. error_log 지시문은 http, 스트림, 서버 및 위치 수준에서도 지정할 수 있으며 상위 수준에서 상속된 설정을 재정의합니다.
버퍼링에 대한 해당 줄은 경고 수준에 있습니다.
[warn] 30055#0: *1428 an upstream response is buffered to a temporary file
따라서 오류 로그 수준이 경고로 설정되어 있지 않은지 확인하면(즉, 기본값으로 두거나 낮추면 해당 경고가 더 이상 표시되지 않습니다.) 아래 해결 방법 중 하나를 사용하면 이를 억제할 수 있습니다.
기본값('error' 수준 이상)으로 둡니다.
error_log logs/error.log;
같은 것:
error_log logs/error.log error;
error임계값을 , 최대 crit, alert및 까지 늘릴 수도 있습니다 emerg.