<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1">
</HEAD>
<BODY>
В Втр, 22/12/2009 в 19:12 +0300, Sergey Shepelev пишет:
<BLOCKQUOTE TYPE=CITE>
<PRE>
> Сегодня возникла одна проблема, которая поставила передо мной вопрос, как
> работает сохранение ответа 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 <A HREF="http://upstr">http://upstr</A>_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.
proxy_buffering off;
</PRE>
</BLOCKQUOTE>
Смысл тогда держать nginx? <BR>
Если бы у меня была возможность разделить зоны вхостов на статические и динамические я бы просто статику прописал в отдачу на прямую nginx'ом и эту тему не поднимал бы. <BR>
<BR>
Меня больше интересыет логика работы nginx'а при проксировании запроса с установленным content-range. Зная ее можно будет планировать обход подобных проблемных мест.
</BODY>
</HTML>