ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





30 января 2013 г., 11:30 пользователь teo <nginx-forum@xxxxxxxx> написал:
Trurl Wrote:
-------------------------------------------------------
> 29 января 2013 г., 23:18 пользователь teo <nginx-forum@xxxxxxxx>
> написал:
>
> > Я выкинул не непонятное, а то, что не имело отношение к делу.
> > Еще раз перечитал - интересно каким образом можно восстановить какую
> именно
> > директорию вы там сканируете если пути относительные?
> >
>
> по длине имени самого файла. В 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, или в документации.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.