 Рассчитать cache_dir и cache_mem s SQUID,  mrrc, 05-Мрт-05, 10:47 [смотреть все]Почитал материалы и темы, описывающие принципы вычисления L1 L2 в cache_dir, а также выделение cache_mem под это дело. Особой ясности в цифрах все же нет, поэтому лучше выслушать мнения по проблеме.Появляется шлюз на базе FreeBSD 4.11-STABLE с CELERON-2000, IDE 80.0GB и 1GB DDR RAM (SWAP предполагаю сделать 2GB), Squid-2.5.STABLE7 (пока нужна именно эта версия). Нагрузка на прокси будет средняя с последующим постепенным возрастанием. Хотел выделить под кэш Squid-а порядка 50GB (51200MB), хотя судя из просмотренного материала по данной теме для нормальной работы такого кэша потребуется >600-800MB оперативной памяти. Ресурсы машины, в общем-то, позволяют это сделать, но не будет ли все-таки Squid тормозить? Может быть, стоит уменьшить кэш для увеличения производительности системы в целом? Если нет, то как правильно вычислить L1 L2 в cache_dir для кэша в 50GB? И сколько все же отдать памяти в cache_mem, учитывая то, что это значение в памяти реально будет в 2-3 раза больше указанного. |
- Рассчитать cache_dir и cache_mem s SQUID, Андрей Слободяник, 12:14 , 05-Мрт-05 (1)
Я скажу свое субъективное "имхо", а пусть гуру поправят.
Есть L1 директорий. В каждой - L2 поддиректорий. В каждой из поддиректорий снова по L2 файлов. Итого: L1*L2*L2 объектов. Для стандартных 16 256 получаем: 16*256*256=1048576 "мегабайт" объектов. Средний размер объектов - эмпирические 13 кбайт.Однако большой кеш делать не стоит, всё равно там будут лежать старые объекты, под которые хоть дискового места не жалко, но расходуется оперативка на их индекс, поиск и т.д. Опять же эмпирически вроде рекомендуется делать размер кеша равным недельному трафику. cache_mem отвечает за хранение закешированных объектов в оперативке. В большинстве случаев этот параметр можно ставить весьма малым, учитывая что в большинстве случаев объект берется всё-таки из _дискового_ кеша, а не из _оперативного_. Вообще же, ещё зависит от деятельности юзеров: если они (гипотетически) каждый раз лазят на всё новые страницы - сквид вообще не нужен, а если все в инет-клубе дружно рубятся в combats.ru (как у меня), то при 4Гб кеша и 32M cache_mema получается средний Request Hit Ratio - 60.0 %, Byte Hit Ratio - 30 %. Мониторить хорошо MRTG через snmp, настройки - здесь же, на опен.нете. Касательно swap-а и политики его использования - я так и не понял. На мой взгляд, при современных объемах RAMa - 512-1024Gb его лучше не использовать - зачем лишние дисковые тормоза? Но если не включать совсем, то при неправильном расходе памяти, может что-то не загрузиться/выгрузиться, что на сервере весьма некстати.
- Рассчитать cache_dir и cache_mem s SQUID, mrrc, 11:56 , 11-Мрт-05 (3)
>Я скажу свое субъективное "имхо", а пусть гуру поправят.
>Есть L1 директорий. В каждой - L2 поддиректорий. В каждой из поддиректорий
>снова по L2 файлов. Итого: L1*L2*L2 объектов. Для стандартных 16 256
>получаем: 16*256*256=1048576 "мегабайт" объектов. Средний размер объектов - эмпирические 13 кбайт.
>
>
>Однако большой кеш делать не стоит, всё равно там будут лежать старые
>объекты, под которые хоть дискового места не жалко, но расходуется оперативка
>на их индекс, поиск и т.д. Опять же эмпирически вроде рекомендуется
>делать размер кеша равным недельному трафику.
Пардон, но выслушав несколько мнений по этому поводу для меня так ничего и не прояснилось.
В кэш в 50Gb я конечно размахнулся, надобность в таком объеме действительна сомнительна в силу описанных и понимаемых причин, а вот как рассчитать все же L1 для каждого случая так и не понятно. Значение L2 остается неприкасаемо, как правило, и равно всегда значению 256.
Одни рассчитывают исходя из некого среднего размера объекта в кэше и еще чего-то, что является числом 416, подходящее ко всем случаям: L1 = cache_dir_size / 416
L2 = 256 Для 20 гигов - cache_dir aufs /var/spool/squid 20000 49 256 Кто-то так:
- "При среднем размере хранимого объекта в 12Kбайт количество файлов для кеша в 50 GB получается 4.2 млн. Я обычно рассчитываю L1 при количестве файлов в каталоге 256 и L2 = 256. Т.е. L1 для 50 GB получается равным 63. Можно просто извлечь кубический корень из числа объектов в кэше." И главное, L1 при каждом варианте расчета получается разным.
- Рассчитать cache_dir и cache_mem s SQUID, Андрей Слободяник, 12:43 , 11-Мрт-05 (4)
>>Я скажу свое субъективное "имхо", а пусть гуру поправят.
>>Есть L1 директорий. В каждой - L2 поддиректорий. В каждой из поддиректорий
>>снова по L2 файлов. Итого: L1*L2*L2 объектов. Для стандартных 16 256
>>получаем: 16*256*256=1048576 "мегабайт" объектов. Средний размер объектов - эмпирические 13 кбайт. >сомнительна в силу описанных и понимаемых причин, а вот как рассчитать
>все же L1 для каждого случая так и не понятно. Значение
>L2 остается неприкасаемо, как правило, и равно всегда значению 256. Далось тебе это L1 :-) Вообще, L1 и L2 придуманы для того, чтобы миллион объектов (файлов) держать не в одном каталоге, т.е. чтобы была "нормальная" структура файловой системы. Оставь 16 256 - это как раз (смотри выше) на миллион объектов, с учётом среднего размера (13к) хорошо для кеша меньше 13 Гб. Итого - смело пиши: cache_dir ufs /var/cache/squid 4096 16 256
- Рассчитать cache_dir и cache_mem s SQUID, mrrc, 20:58 , 11-Мрт-05 (5)
>
>Далось тебе это L1 :-) Вообще, L1 и L2 придуманы для того,
>чтобы миллион объектов (файлов) держать не в одном каталоге, т.е. чтобы
>была "нормальная" структура файловой системы. Оставь 16 256 - это как
>раз (смотри выше) на миллион объектов, с учётом среднего размера (13к)
>хорошо для кеша меньше 13 Гб. Итого - смело пиши: cache_dir
>ufs /var/cache/squid 4096 16 256Нет, 4Gb меня не устроят, пользователей будет несколько сотен и все завернуты на Squid, 20-30Gb выделяю под это дело.
Для чего нужны L1 и L2 понятно, но все-таки должны они как-то рассчитываться в зависимости от выделяемого объема под кэш. Неужели сами разработчики не реализовали механизм просчета данных значений пользователями.
- Рассчитать cache_dir и cache_mem s SQUID, ipmanyak, 13:17 , 05-Мрт-05 (2)
более 2 гигов думаю нет смысла делать кэш, будет заниматься перебором больших индексов, трафик может и скэкономишь, но скорость доступа будет явно низковата. расчет памяти в ОЗУ смотри здесь http://www.squid-cache.org/Doc/FAQ/FAQ-8.html#ss8.11в целом примерно так - 10 мег на каждый гиг КЭШа + cache_mem + 10-20MB
cache_mem на твое усмотрение, раз оперативы много, можно поставить например 128 мег, в процессе эксплутацаии подкрректируешь нужные параметры, перидоически анализируй
http://www.squid-cache.org/Doc/FAQ/FAQ-8.html#ss8.5
- Рассчитать cache_dir и cache_mem s SQUID, tremor, 09:44 , 14-Май-09 (6)
А есть ли смысл делать 2 кэша? Например у меня половина траффика уходит на e1.ru, гигабайтами прет с него трафф, остальная половина с других сайтов, везде по мелочи. Много разных сайтов. Дак вот e1.ru постоянно держать бы в кеше, но если кэш один, то он будет постоянно перетираться "свободными радикалами" - разными сайтами, день ото дня. Если его сделать гига 2-4, то на e1.ru конечно хватит, но все равно, как я понимаю, эти ежедневно-новые сайты, будут "гадить" в кэш. Так что гиг бы на е1 и еще гиг на все остальное? Ну как есть смысл в моих размышлениях? (имею 70 юзеров, месячный трафф около 20 ГБ)
- Рассчитать cache_dir и cache_mem s SQUID, Hayk Hayrapetan, 12:50 , 10-Окт-09 (7) –1
>А есть ли смысл делать 2 кэша? Например у меня половина траффика
>уходит на e1.ru, гигабайтами прет с него трафф, остальная половина с
>других сайтов, везде по мелочи. Много разных сайтов. Дак вот e1.ru
>постоянно держать бы в кеше, но если кэш один, то он
>будет постоянно перетираться "свободными радикалами" - разными сайтами, день ото дня.
>Если его сделать гига 2-4, то на e1.ru конечно хватит, но
>все равно, как я понимаю, эти ежедневно-новые сайты, будут "гадить" в
>кэш. Так что гиг бы на е1 и еще гиг на
>все остальное? Ну как есть смысл в моих размышлениях? (имею 70
>юзеров, месячный трафф около 20 ГБ) i tak, nikto normalno nichego ne skazal , s chem i pozdravlyayu vas!!!!!!!
|
Версия для распечатки
