28 января 2013 г., 14:09 пользователь Maxim Dounin <mdounin@xxxxxxxxxx> написал:
On Mon, Jan 28, 2013 at 01:22:52PM +0200, Trurl McByte wrote:
> 28 января 2013 г., 11:25 пользователь Maxim Dounin <mdounin@xxxxxxxxxx>написал:
>
> > 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;
Причем пробег кеш-менеджера в таком состоянии может и вычистить все (совсем, все файлы, не взирая на размер), если нагрузки нет. А может и не тронуть. Пока суммарный размер не превысит 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 для того же, но, почему-то, работает не адекватно.