Re: помогите понять логику кеширования и буферизации

[Trurl McByte]

30 января 2013 г., 11:30 пользователь teo <nginx-forum at nginx.us> написал:

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

Вообще-то это в документации есть.


> ...
> >
> > я всего лишь пытался показать, что параметр proxy_max_temp_file_size
> > никакой роли не играет.
>
> И я о том же. Он вообще не для кеша.
>

Так и я не про кеш. Я про temp folder.


>
> >Даже в кеш этот файл попасть не должен был,
> > потому
> > как  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.
>
> Т.е. вы путаете размер всего кеша и размер конкретного файла в нем.
> И логика убирания файлов из кеша - не тех, что превышают ваш размер, а тех,
> кто наиболее редко использовался.
>
И никто не гарантирует в какой момент это станет происходить. Потому что
> найти файл подлежащий удалению - в момент приема текущего запроса - это
> слишком накладно. Поэтому есть фоновый процесс, который "медленно
> спускается
> с горы и проверяет каждый -файл-".
> Т.ч. при огромном кеше вообще непонятно за какое время он сделает полный
> цикл. А у него есть еще ограничения по цпу одной итерации и время паузы.
>
>
Я не путаю. Я просто говорю про общую логику, а не про логику nginx.
Согласитесь, что не логично пихать в кеш то, что немедленно оттуда должно
быть выкинуто.


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

В этом же треде мне недавно доказывали обратное:

> Размер keys_zone соотносится с размером кеша только опосредованно
> (т.к. ограничивает максимальное число элементов, которое может
> храниться в кеше).

И в документации:

> Кроме того, все активные ключи и информация о данных хранятся в зоне
разделяемой памяти, *имя* и *размер* которой задаются параметром keys_zone.

Видимо, таки баг где-то. Или в nginx, или в документации.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130130/e8a53018/attachment.html>