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

Trurl McByte trurl at mcbyte.net
Mon Jan 28 11:22:52 UTC 2013


28 января 2013 г., 11:25 пользователь Maxim Dounin <mdounin at mdounin.ru>написал:

> On Mon, Jan 28, 2013 at 03:34:00AM -0500, Trurl wrote:
>
> > Не могу ничего понять из документации.
> >
> > Допустим у меня вот такой набор:
> >    proxy_temp_path /var/lib/nginx/proxy 1 1;
> >     proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1
> > keys_zone=main_cache:256m inactive=42h max_size=5m;
> >     proxy_buffer_size   8k;
> >     proxy_buffers       32 8k;
> >     proxy_busy_buffers_size 64k;
> >     proxy_max_temp_file_size 0;
> > # ( рекомендовали тут так для ограничения дискового пространства,
> > используемого nginx - если что в корне не верно - поправте меня)
> >
> > И при таком наборе nginx все равно запихал в кеш файл размером 249M,
> выкинув
> > всю мелочь и остался доволен.
> > Что я делаю не так? Как ограничить максимальный размер кешируемого файла?
>
> Сейчас - никак.  Ну то есть с бекенда можно явно запретить
> кеширование, либо же через proxy_no_cache.  Какой-либо директивы
> "не кешировать файлы более N" - нет.
>

У меня бекендов много разных, там и апачи, и nginx (прочие удалось заменить
на nginx), в зависимости от целей. А proxy_no_cache не шибко применишь,
если размер файла заранее не известен.


>
> [...]
>
> > > Специальный процесс “cache manager” следит за максимальным размером
> кэша,
> > заданным параметром
> > > max_size, и при превышении его размеров удаляет наименее востребованные
> > данные.
> > Это я вообще не понял. Общий размер кеша, на практике, ничего общего с
> > max_size не имеет, зато подозрительно совпадает с размером, заданным в
> > keys_zone, который, вроде бы должен задавать размер разделяемой памяти.
>
> Размер кеша может превышать установленный максимальный размер
> (max_size), если cache manger ещё не успел его уменьшить,
> либо он не может это сделать из-за того, что элементы кеша
> используются рабочими процессами.
>

Я это учитываю, разовые превышения не в счет. Я про то что _суммарный_
размер кеша в долгосрочной перспективе и с приличной нагрузкой
устаканивается в точно в размер keys_zone (!), хотя в документации об этом
вообще ничего нет. При этом max_size вообще ни на что не влияет.


>
> При max_size=5m и характерном размере файлов 249m - ничего
> удивительного, что наблюдаемая реальность мало совпадает с
> желаемой.
>

Не понял про "характерный", на тесте только один такой файл был, при его
протаскивании из кеша выкидывается почти все (остается файликов на сумму
дополняющую до 256m). Если файл крупнее 256m - то он не кешируется.
Невзирая на то, что "Сейчас - никак". Но меня такое ограничение не очень
устраивает.


>
> > Размер proxy_temp_path вообще не понятно как лимитируется. На практике -
> > достижением 100% забитости диска, после чего все помирает.
>
> Совсем в теории - там может быть максимум worker_processes *
> worker_connections * proxy_max_temp_file_size в отсутствии кеша, и
> то же с заменой proxy_max_temp_file_size на максимальный размер
> ответа, возвращаемого бекендом, если кеш включён.
>

по такой логике при proxy_max_temp_file_size 0; вообще ничего не должно
заполняться, а у меня до 50 гигов набегает.


>
> На практике - под proxy_temp_path просто следует отводить
> достаточно места.


Вот только суммарный контент у меня измеряется в террабайтах. А кол-во
коннектов до 20к на каждый сервер. На тестовом канал 200мбит. Что будет
когда я его поставлю на продакшен, где отдельный гигабит на каждый сервер -
я себе плохо представляю. Видимо там так и останется сквид, у которого со
всем этим проблем нет. Зато у него со стабильностью проблемы...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130128/87042717/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru