Trurl Wrote:
-------------------------------------------------------
> 29 января 2013 г., 23:18 пользователь teo <nginx-forum@nginx.us>
> написал:
>
> > Я выкинул не непонятное, а то, что не имело отношение к делу.
> > Еще раз перечитал - интересно каким образом можно восстановить какую
> именно
> > директорию вы там сканируете если пути относительные?
> >
>
> по длине имени самого файла. В temp они короче.

Не имею таких наблюдений, поэтому ничего сказать не могу. Хотя это косвенно подтверждает что для укладки в темп nginx использует не такой ключ, как для самого кеша - его право.

> > Пути во временной директории - ровно такие же, как и в том месте,
> куда они
> > потом должны попасть - ну может быть сгенерены для другого ключа,
> хотя
> > врядли.
> > Если файл пишется во временную директорию, указанную при описании
> кеша -
> > значит решение о помещении его в кеш уже принято, и не важно в
> данном
> > случае
> >
> - временная это директория или уже реальная. Хотя да, различие есть
> т.к.
> > "расти" файл может только во временной директории - так что вы
> приводили
> > сканирование именно временной директории. Только сути это не
> меняет.
> >
>
> я всего лишь пытался показать, что параметр proxy_max_temp_file_size
> никакой роли не играет.

И я о том же. Он вообще не для кеша.

>Даже в кеш этот файл попасть не должен был,
> потому
> как max_size=5m.

Цитата:
The special process “cache manager” monitors the maximum cache size set by the max_size parameter; when this size is exceeded it removes the least recently used data.

Т.е. вы путаете размер всего кеша и размер конкретного файла в нем.
И логика убирания файлов из кеша - не тех, что превышают ваш размер, а тех, кто наиболее редко использовался.
И никто не гарантирует в какой момент это станет происходить. Потому что найти файл подлежащий удалению - в момент приема текущего запроса - это слишком накладно. Поэтому есть фоновый процесс, который "медленно спускается с горы и проверяет каждый -файл-".
Т.ч. при огромном кеше вообще непонятно за какое время он сделает полный цикл. А у него есть еще ограничения по цпу одной итерации и время паузы.


> Но этот параметр тоже работает только задним числом
> и то
> не всегда. При скачивании очень больших файлов оные остаются в кеше
> очень
> на долго (не взирая на все ограничения), поскольку пока первый
> запросивший
> его стянет по своим медленным каналам - к тому времени появится еще
> один
> желающий стянуть тот же файл. В результате размер temp+кеша
> гарантировано
> больше proxy_max_temp_file_size+max_size, иногда в тысячи раз и до
> переполнения диска. То есть использование nginx на продакшене на
> сайтах с
> геобалансингом и большим количеством крупного контента сопряжено с
> серьезными рисками.

И я не знаю почему вы пытаетесь соотносить это с proxy_max_temp_file_size+max_size?
Максимальный размер кеша задается в параметре keys_zone.
И на моем опыте это еще ни разу не превысило указанный размер. Правда это на последней стабильной версии.

>
>
> > Я честно пытался 2ды объяснить - видимо не судьба. Остается уже
> спросить -
> > а
> > если вообще при описании локейшена не будет задано никаких кешей?
> > То имеет ли смысл указание этого параметра или без кеша оно не
> имеет
> > смысла?
> >
>
> Если бы он работал как вы описали - то да, имело бы смысл.
>
>
> > Можете ответить на этот вопрос сами себе - мне это уже не
> интересно.
> > По-моему пора прекратить препирательства - я рад что вы нашли способ
> как
> > побороть nginx в вашем случае.
> >
>
> Нормальный софт не надо бороть.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru