<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">28 января 2013 г., 14:09 пользователь Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Mon, Jan 28, <a href="tel:2013" value="+9722013">2013</a> at 01:22:52PM +0200, Trurl McByte wrote:<br>
<br>
> 28 января <a href="tel:2013" value="+9722013">2013</a> г., 11:25 пользователь Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>написал:<br>
><br>
> > On Mon, Jan 28, <a href="tel:2013" value="+9722013">2013</a> at 03:34:00AM -0500, Trurl wrote:<br>
> ><br>
> > > Не могу ничего понять из документации.<br>
> > ><br>
> > > Допустим у меня вот такой набор:<br>
> > > proxy_temp_path /var/lib/nginx/proxy 1 1;<br>
> > > proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1<br>
> > > keys_zone=main_cache:256m inactive=42h max_size=5m;<br>
> > > proxy_buffer_size 8k;<br>
> > > proxy_buffers 32 8k;<br>
> > > proxy_busy_buffers_size 64k;<br>
> > > proxy_max_temp_file_size 0;<br>
> > > # ( рекомендовали тут так для ограничения дискового пространства,<br>
> > > используемого nginx - если что в корне не верно - поправте меня)<br>
> > ><br>
> > > И при таком наборе nginx все равно запихал в кеш файл размером 249M,<br>
> > выкинув<br>
> > > всю мелочь и остался доволен.<br>
> > > Что я делаю не так? Как ограничить максимальный размер кешируемого файла?<br>
> ><br>
> > Сейчас - никак. Ну то есть с бекенда можно явно запретить<br>
> > кеширование, либо же через proxy_no_cache. Какой-либо директивы<br>
> > "не кешировать файлы более N" - нет.<br>
> ><br>
><br>
> У меня бекендов много разных, там и апачи, и nginx (прочие удалось заменить<br>
> на nginx), в зависимости от целей. А proxy_no_cache не шибко применишь,<br>
> если размер файла заранее не известен.<br>
<br>
</div>Это всё понятно, потому и было написано, что сейчас - никак. Если<br>
бекенд не выдаёт информации, явно запрещающей или позволяющей<br>
запретить кеширование, то универсально работающего способа - нет.<br></blockquote><div><br></div><div>А на бекэнде (nginx на файлере) есть _дешовый_ способ выставить хидеры в зависимости от размеров файла? Именно дешовый, потому как юзать перл и прочее на файлере - плохая идея.<br>
</div>И какие? <br>То ли X-Accel-Buffering (по идее при отключенном буфере кеширования нет, да и 80% такого контента - видео/аудио)<br>То ли X-Accel-Expires (а оно точно не будет все равно кешировать и тут же экспайрить? И в temp пихать не будет?)<br>
</div><div class="gmail_quote">Ну и X-Accel-Limit-Rate заодно...<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > > > Специальный процесс “cache manager” следит за максимальным размером<br>
> > кэша,<br>
> > > заданным параметром<br>
> > > > max_size, и при превышении его размеров удаляет наименее востребованные<br>
> > > данные.<br>
> > > Это я вообще не понял. Общий размер кеша, на практике, ничего общего с<br>
> > > max_size не имеет, зато подозрительно совпадает с размером, заданным в<br>
> > > keys_zone, который, вроде бы должен задавать размер разделяемой памяти.<br>
> ><br>
> > Размер кеша может превышать установленный максимальный размер<br>
> > (max_size), если cache manger ещё не успел его уменьшить,<br>
> > либо он не может это сделать из-за того, что элементы кеша<br>
> > используются рабочими процессами.<br>
> ><br>
><br>
> Я это учитываю, разовые превышения не в счет. Я про то что _суммарный_<br>
> размер кеша в долгосрочной перспективе и с приличной нагрузкой<br>
> устаканивается в точно в размер keys_zone (!), хотя в документации об этом<br>
> вообще ничего нет. При этом max_size вообще ни на что не влияет.<br>
<br>
</div>Размер keys_zone соотносится с размером кеша только опосредованно<br>
(т.к. ограничивает максимальное число элементов, которое может<br>
храниться в кеше).<br></blockquote><div><br></div><div>В том-то и дело что наблюдается совершенно другая зависимость...<br></div><div>при <br>proxy_cache_path /var/lib/nginx/proxy/cache levels=1:1 keys_zone=main_cache:256m inactive=42h max_size=5m;</div>
<div><br></div><div>кеш выглядит так<br>du -bc */*/* | sort -rn | head -15<br>264365155 total<br>259844420 5/f/583c124c9e5cac01c97bcb0d9c56b6f5<br>1968962 d/f/8a473cf7ea9e00771de9cca58b6c8dfd<br>271317 3/3/b14c4ca7615e5f316b612e6105d72733<br>
202668 2/d/58af6126b8b936f3bc0c1fe861d5c8d2<br>149240 0/9/2810fe7c50e3bf30847db46fc27fb790<br>78200 9/2/b21a65e9c49fcd37abeb1f90d56dea29<br>72009 e/5/34156b0979c7364e57d6dedbd091265e<br>63667 0/a/908042c8c483a45e5254bfd8559008a0<br>
62044 7/6/040ea3ec37b3a834ad7a80b06e60fd67<br>54475 0/d/1ecc6a6a03fb044944aeb36abc0658d0<br>54004 8/d/80a9dbbecacc2fc574f23dd46c8227d8<br>53300 1/f/dcfbb766776d9d8d29c29b20ab068ef1<br>51410 2/3/fe6eff5160d14633ab6fa06325230832<br>
48559 5/6/91ccd7a9bc98a1eab14d1322cc735f65<br></div><div></div><div><br></div><div>Причем пробег кеш-менеджера в таком состоянии может и вычистить все (совсем, все файлы, не взирая на размер), если нагрузки нет. А может и не тронуть. Пока суммарный размер не превысит keys_zone - в этом случае выкинет лишнее. Или все. В общем как бог на душу положит.<br>
</div><div>Вот keys_zone он строго не дает превышать, проверено на другом, сильно нагруженном сервере и вообще такой странный набор я прописывал по совету кого-то тут. Я и подумал, что это известная недокументированная фитча.<br>
</div><br><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Если max_size не учитывается - то скорее всего вы правите не тот<br>
конфиг, либо не перезагружаете его.<br></blockquote><div><br>Ну я не настолько заработался еще...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Сразу обращаю внимание: при изменении некоторых параметров кеша<br>
(путь, levels) nginx может отказаться перезагружать конфиг на<br>
лету, написав об этом в error log. В таком случае нужно либо<br>
перезапустить nginx, либо провести процедуру обновления<br>
исполняемого файла.<br></blockquote><div><br></div><div>я после перехода на systemd вообще стал жутко недоверчивый и в случаях экспериментов с любыми конфигами без полной остановки и ps ax | grep {procname} не обхожусь<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > При max_size=5m и характерном размере файлов 249m - ничего<br>
> > удивительного, что наблюдаемая реальность мало совпадает с<br>
> > желаемой.<br>
> ><br>
><br>
> Не понял про "характерный", на тесте только один такой файл был, при его<br>
> протаскивании из кеша выкидывается почти все (остается файликов на сумму<br>
> дополняющую до 256m). Если файл крупнее 256m - то он не кешируется.<br>
> Невзирая на то, что "Сейчас - никак". Но меня такое ограничение не очень<br>
> устраивает.<br>
<br>
</div>Судя по всему, 256m - это то, во что у вас установлен параметр<br>
max_size. При превышении max_size - из кеша начинают выкидываться<br>
старые ответы, и ответ больше max_size - будет практически сразу<br>
выкинут. Но это не то же самое, что "не будет закеширован".<br></blockquote><div><br>Я же написал - max_size=5m<br></div><div>Файл не выкинут в течении получаса.<br></div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > > Размер proxy_temp_path вообще не понятно как лимитируется. На практике -<br>
> > > достижением 100% забитости диска, после чего все помирает.<br>
> ><br>
> > Совсем в теории - там может быть максимум worker_processes *<br>
> > worker_connections * proxy_max_temp_file_size в отсутствии кеша, и<br>
> > то же с заменой proxy_max_temp_file_size на максимальный размер<br>
> > ответа, возвращаемого бекендом, если кеш включён.<br>
> ><br>
><br>
> по такой логике при proxy_max_temp_file_size 0; вообще ничего не должно<br>
> заполняться, а у меня до 50 гигов набегает.<br>
<br>
</div>При выключенном кеше - так и есть. При включённом - от<br>
proxy_max_temp_file_size ничего не зависит, перечитайте ещё раз<br>
написанное выше.<br>
<div class="im"><br>
> > На практике - под proxy_temp_path просто следует отводить<br>
> > достаточно места.<br>
><br>
><br>
> Вот только суммарный контент у меня измеряется в террабайтах. А кол-во<br>
> коннектов до 20к на каждый сервер. На тестовом канал 200мбит. Что будет<br>
> когда я его поставлю на продакшен, где отдельный гигабит на каждый сервер -<br>
> я себе плохо представляю. Видимо там так и останется сквид, у которого со<br>
> всем этим проблем нет. Зато у него со стабильностью проблемы...<br>
<br>
</div>Арифметика простая: 20k соединений - это 20k * (максимальный<br>
размер кешируемого файла) в proxy_temp_path максимум, в худшем<br>
случае.<br>
<br>
Пытаться кешировать в таких условиях blue ray диски - таки да,<br>
некомфортно, согласен. Но это скорее способ отстрелить себе ногу,<br>
чем практика.</blockquote></div><br>у нас эксклюзивные (то есть свои) видео и аудио. Да и всякие инсталлеры модов тоже жирные бывают. Типа HiRes тесктур для Скайрима (5GB файлик).<br><br></div><div class="gmail_extra">У сквида есть maximum_object_size_in_memory и maximum_object_size для такого случая.<br>
</div><div class="gmail_extra">А в nginx вроде бы есть связка proxy_buffer_size+proxy_buffers+proxy_max_temp_file_size для того же, но, почему-то, работает не адекватно.</div><div class="gmail_extra"><br></div></div>