proxy vs content-range

[SaveFrom.net]

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

У Вас же, вероятно, происходило следующее: пользователь запрашивал данные с
бэкэнда в 10 потоков, nginx на каждый поток тянул файл полностью(со
смещением) и сохранял в дисковый буфер. Рекомендую попробовать ограничить
дисковый буфер.

 Есть тонкость, которую следует иметь ввиду: очередное чтение из бекенда
будет только после полного освобождения полного буфера proxy. и надо
смотреть внимательно на таймауты настроенные в бекенде. e.g. если
proxy_buffers 2 64k; limit_rate 1k; - то в течении 64 секунд из бекенда
ничего читаться не будет, и таймаут на бекенде надо ставить больше 64
секунд. то же относится к просто медленным клиентам.

С уваженем, Антон

22 декабря 2009 г. 20:24 пользователь Bogun Dmitriy <
vugluskr at vugluskr.org.ua> написал:

>  В Втр, 22/12/2009 в 19:35 +0300, SaveFrom.net пишет:
>
>  Могу ошибаться, но на мой взгляд разумнее использовать
> proxy_max_temp_file_size
>
> Директива задаёт максимальный размер временного файла для проксированного
> ответа. "proxy_max_temp_file_size 0" запрещает создание файла.
>
>  А где про нее можно почитать?
> Что происходит если отдаваемое "тело" превышает этот размер? Ведь если там
> будет стоят n метров, nginx должен их выкачать, прежде чем сможет понять что
> "тело" больше чем proxy_max_temp_file_size.
>
>
>  22 декабря 2009 г. 18:38 пользователь Bogun Dmitriy <
> vugluskr at vugluskr.org.ua> написал:
>
>  Здравствуй, all.
>
> Сегодня возникла одна проблема, которая поставила передо мной вопрос, как
> работает сохранение ответа backend'а в proxy_temp_path в случае наличия в
> запросе content-range.
>
> Моя проблема заключалась в том, что файлик размером в ~4gb стала тянуть
> качалка в ~10 потоков, что привело к очень большой нагрузке на FS и
> окончанию на ней места. Причем место занимали файлы уже удаленные с FS но
> еще не закрытые nginx'ом.
>
> Конфиг вхоста:
>
> server {
>     listen      1.1.1.1;
>
>     server_name .vhost.dom;
>
>     client_max_body_size 200m;
>
>     access_log  /var/log/nginx/vhost-access.log generic;
>     error_log   /var/log/nginx/vhost-error.log info;
>
>     root /srv/vhost.dom/www/htdocs;
>
>     location / {
>         proxy_pass         http://upstr_vhost;
>         proxy_set_header   Host             $host;
>         proxy_set_header   X-Real-IP        $remote_addr;
>         proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
>     }
> }
>
>
> На upstream'е обыкновенный apache, который отдавал файл с ФС. Настроить
> отдачу напрямую не всегда возможно, т.к. за содержимое вхоста "отвечает"
> другой человек...
>
> Направьте в сторону информации о работе модуля proxy при наличии заголовка
> content-range.
>
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091223/af886db8/attachment.html>