<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">29 января 2013 г., 23:18 пользователь teo <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":fx">Я выкинул не непонятное, а то, что не имело отношение к делу.<br>
Еще раз перечитал - интересно каким образом можно восстановить какую именно<br>
директорию вы там сканируете если пути относительные?<br></div></blockquote><div><br>по длине имени самого файла. В temp они короче.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":fx">
Пути во временной директории - ровно такие же, как и в том месте, куда они<br>
потом должны попасть - ну может быть сгенерены для другого ключа, хотя<br>
врядли.<br>
Если файл пишется во временную директорию, указанную при описании кеша -<br>
значит решение о помещении его в кеш уже принято, и не важно в данном случае<br></div></blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":fx">
- временная это директория или уже реальная. Хотя да, различие есть т.к.<br>
"расти" файл может только во временной директории - так что вы приводили<br>
сканирование именно временной директории. Только сути это не меняет.<br></div></blockquote><div><br></div><div>я всего лишь пытался показать, что параметр proxy_max_temp_file_size никакой роли не играет. Даже в кеш этот файл попасть не должен был, потому как  max_size=5m. Но этот параметр тоже работает только задним числом и то не всегда. При скачивании очень больших файлов оные остаются в кеше очень на долго (не взирая на все ограничения), поскольку пока первый запросивший его стянет по своим медленным каналам - к тому времени появится еще один желающий стянуть тот же файл. В результате размер temp+кеша гарантировано больше proxy_max_temp_file_size+max_size, иногда в тысячи раз и  до переполнения диска. То есть использование nginx на продакшене на сайтах с геобалансингом и большим количеством крупного контента сопряжено с серьезными рисками.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":fx">
Я честно пытался 2ды объяснить - видимо не судьба. Остается уже спросить - а<br>
если вообще при описании локейшена не будет задано никаких кешей?<br>
То имеет ли смысл указание этого параметра или без кеша оно не имеет смысла?<br></div></blockquote><div><br>Если бы он работал как вы описали - то да, имело бы смысл. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":fx">Можете ответить на этот вопрос сами себе - мне это уже не интересно.<br>
По-моему пора прекратить препирательства - я рад что вы нашли способ как<br>
побороть nginx в вашем случае.</div></blockquote></div><br></div><div class="gmail_extra">Нормальный софт не надо бороть.<br></div><div class="gmail_extra"><br></div></div>