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

Mon Jan 28 13:36:50 UTC 2013

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

> On Mon, Jan 28, 2013 at 01:22:52PM +0200, Trurl McByte wrote:
>
> > 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 не шибко применишь,
> > если размер файла заранее не известен.
>
> Это всё понятно, потому и было написано, что сейчас - никак.  Если
> бекенд не выдаёт информации, явно запрещающей или позволяющей
> запретить кеширование, то универсально работающего способа - нет.
>

А на бекэнде (nginx на файлере)  есть _дешовый_ способ выставить хидеры в
зависимости от размеров файла? Именно дешовый, потому как юзать перл и
прочее на файлере - плохая идея.
И какие?
То ли X-Accel-Buffering (по идее при отключенном буфере кеширования нет, да
и 80% такого контента - видео/аудио)
То ли X-Accel-Expires (а оно точно не будет все равно кешировать и тут же
экспайрить? И в temp пихать не будет?)
Ну и X-Accel-Limit-Rate заодно...

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

В том-то и дело что наблюдается совершенно другая зависимость...
при
proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1
keys_zone=main_cache:256m inactive=42h max_size=5m;

кеш выглядит так
du -bc */*/* | sort -rn | head -15
264365155       total
259844420       5/f/583c124c9e5cac01c97bcb0d9c56b6f5
1968962 d/f/8a473cf7ea9e00771de9cca58b6c8dfd
271317  3/3/b14c4ca7615e5f316b612e6105d72733
202668  2/d/58af6126b8b936f3bc0c1fe861d5c8d2
149240  0/9/2810fe7c50e3bf30847db46fc27fb790
78200   9/2/b21a65e9c49fcd37abeb1f90d56dea29
72009   e/5/34156b0979c7364e57d6dedbd091265e
63667   0/a/908042c8c483a45e5254bfd8559008a0
62044   7/6/040ea3ec37b3a834ad7a80b06e60fd67
54475   0/d/1ecc6a6a03fb044944aeb36abc0658d0
54004   8/d/80a9dbbecacc2fc574f23dd46c8227d8
53300   1/f/dcfbb766776d9d8d29c29b20ab068ef1
51410   2/3/fe6eff5160d14633ab6fa06325230832
48559   5/6/91ccd7a9bc98a1eab14d1322cc735f65

Причем пробег кеш-менеджера в таком состоянии может и вычистить все
(совсем, все файлы, не взирая на размер), если нагрузки нет. А может и не
тронуть. Пока суммарный размер не превысит keys_zone - в этом случае
выкинет лишнее. Или все. В общем как бог на душу положит.
Вот keys_zone он строго не дает превышать, проверено на другом, сильно
нагруженном сервере и вообще такой странный набор я прописывал по совету
кого-то тут. Я и подумал, что это известная недокументированная фитча.

> Если max_size не учитывается - то скорее всего вы правите не тот
> конфиг, либо не перезагружаете его.
>

Ну я не настолько заработался еще...

>
> Сразу обращаю внимание: при изменении некоторых параметров кеша
> (путь, levels) nginx может отказаться перезагружать конфиг на
> лету, написав об этом в error log.  В таком случае нужно либо
> перезапустить nginx, либо провести процедуру обновления
> исполняемого файла.
>

я после перехода на systemd вообще стал жутко недоверчивый и в случаях
экспериментов с любыми конфигами без полной остановки и ps ax | grep
{procname} не обхожусь

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

Я же написал - max_size=5m
Файл не выкинут в течении получаса.

> > > > Размер 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_max_temp_file_size ничего не зависит, перечитайте ещё раз
> написанное выше.
>
> > > На практике - под proxy_temp_path просто следует отводить
> > > достаточно места.
> >
> >
> > Вот только суммарный контент у меня измеряется в террабайтах. А кол-во
> > коннектов до 20к на каждый сервер. На тестовом канал 200мбит. Что будет
> > когда я его поставлю на продакшен, где отдельный гигабит на каждый
> сервер -
> > я себе плохо представляю. Видимо там так и останется сквид, у которого со
> > всем этим проблем нет. Зато у него со стабильностью проблемы...
>
> Арифметика простая: 20k соединений - это 20k * (максимальный
> размер кешируемого файла) в proxy_temp_path максимум, в худшем
> случае.
>
> Пытаться кешировать в таких условиях blue ray диски - таки да,
> некомфортно, согласен.  Но это скорее способ отстрелить себе ногу,
> чем практика.

у нас эксклюзивные (то есть свои) видео и аудио. Да и всякие инсталлеры
модов тоже жирные бывают. Типа HiRes тесктур для Скайрима (5GB файлик).

У сквида есть maximum_object_size_in_memory и maximum_object_size для
такого случая.
А в nginx  вроде бы есть связка
proxy_buffer_size+proxy_buffers+proxy_max_temp_file_size для того же, но,
почему-то, работает не адекватно.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130128/cc083823/attachment-0001.html>