☰

ответ восходящего потока буферизуется во временном файле

tag-icon • tag-icon nginx reverse-proxy buffer
ответ восходящего потока буферизуется во временном файле

У меня есть довольно большое и медленное (сложные данные, сложный фронтенд) веб-приложение, встроенное RoRи обслуживаемое Pumaкак nginxобратный прокси. Глядя в nginxжурнал ошибок, я вижу довольно много записей, таких как:

2014/04/08 09:46:08 [warn] 20058#0: *819237 an upstream response is buffered to a temporary file 
    /var/lib/nginx/proxy/8/47/0000038478 while reading upstream, 
    client: 5.144.169.242, server: engagement-console.foo.it, 
    request: "GET /elements/pending?customer_id=2&page=2 HTTP/1.0", 
    upstream: "http://unix:///home/deployer/apps/conversationflow/shared/sockets/puma.sock:/elements/pending?customer_id=2&page=2", 
    host: "ec.reputationmonitor.it", 
    referrer: "http://ec.foo.it/elements/pending?customer_id=2&page=3"

Мне довольно любопытно, поскольку маловероятно, что страница останется одинаковой для разных пользователей и разных взаимодействий с ними, и я не думаю, что буферизация ответа на диске необходима/полезна.

Я знаю о proxy_max_temp_file_sizeвозможности установки его в 0, но мне кажется, что это немного неудобно (мой прокси-сервер пытается буферизировать данные, но у него нет файла, куда можно было бы их буферизовать... как это может быть быстрее?).

У меня есть вопросы:

  1. Как убрать [warn] и избежать буферизации ответов? Лучше отключить proxy_bufferingили установить proxy_max_temp_file_sizeна 0? Почему?

  2. Если nginxбуферизует ответ: когда он передает буферизованный ответ, кому и почему?

  3. Почему nginxвключается proxy_bufferingпо умолчанию, а затем [предупреждает] вас, если на самом деле буферизует ответ?

  4. Когда ответ активирует эту опцию? Когда требуется > несколько секунд (сколько?) для обслуживания ответа? Это можно настроить?

TIA, нгв.

решение1

  1. Как убрать [warn] и избежать буферизации ответов? Лучше отключить proxy_buffering или установить proxy_max_temp_file_size на 0? Почему?

Вам следует установить proxy_max_temp_file_sizeзначение 0, чтобы удалить его. Директива proxy_bufferingне связана напрямую с предупреждением. Вы можете отключить ее, чтобы остановить буферизацию вообще, но это не рекомендуется делать в целом (если только это не нужно длякомета).

  1. Если nginx буферизует ответ, когда он передает буферизованный ответ, кому и почему?

Он обслуживает ответ немедленно, но клиент обычно имеет гораздо более медленное соединение и не может потреблять данные ответа так же быстро, как их производит ваше приложение. Nginx пытается буферизировать весь ответ, чтобы освободить ваше приложение как можно скорее.

Смотрите также:http://aosabook.org/en/nginx.html

  1. Почему nginx включает proxy_buffering по умолчанию, а затем [предупреждает] вас, если он действительно буферизует ответ?

Как я уже упоминал, proxy_bufferingнапрямую не связан с предупреждением. Он обычно нужен для оптимизированных операций прокси, и его отключение ухудшает производительность и пропускную способность.

Nginx предупреждает только тогда, когда ответ не помещается в настроенные буферы памяти. Вы можете игнорировать предупреждение, если вас это устраивает.

  1. Когда ответ активирует эту опцию? Когда требуется > нескольких секунд (сколько?) для обслуживания ответа? Это можно настроить?

Срабатывает при заполнении буферов памяти. Пожалуйста, посмотрите документацию, там весь механизм объяснен:http://nginx.org/r/proxy_max_temp_file_size

Возможно, вам захочется увеличить буферы памяти.

решение2

Следующая конфигурация отлично работает на моем сервере.

proxy_buffers 16 16k;  
proxy_buffer_size 16k;

решение3

Команда nginx sendfile может помочь в этом для статического контента.

https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/

Включение sendfile:

По умолчанию NGINX сам обрабатывает передачу файлов и копирует файл в буфер перед отправкой. Включение директивы sendfile устраняет этап копирования данных в буфер и позволяет напрямую копировать данные из одного файлового дескриптора в другой. Чтобы предотвратить полное заполнение рабочего процесса одним быстрым соединением, можно использовать директиву sendfile_max_chunk, чтобы ограничить объем данных, передаваемых за один вызов sendfile() (в этом примере до 1 МБ):

location /mp3 {
    sendfile           on;
    sendfile_max_chunk 1m;
    #...
}

решение4

Добавьте их в nginx.conf или контекст файла конфигурации виртуального хоста (http,сервер,расположение):

proxy_max_temp_file_size 10240m;
proxy_buffers 240 240k;
proxy_busy_buffers_size 240k;
proxy_buffer_size 240k;

Вы можете задать значения в зависимости от ситуации, но они должны быть сбалансированы друг с другом (не используйте разные числа для директив буфера).

У меня та же проблема, и я тестирую эти конфигурации для скрипта с тяжелыми и длительными процессами ввода-вывода, SQL и PHP, и все работает нормально.

Связанный контент