UMGUM.COM (лучше) 

Squid3 + Cache ( Конфигурирование параметров оперативной и дисковой памяти Squid3. )

30 ноября 2011  (обновлено 31 января 2015)

OS: Debian GNU/Linux Squeeze.

Ранее мы договорились, что будем выносить логические блоки настроек в отдельные файлы. Сейчас этим и займёмся. В предыдущей заметке я порассуждал на тему распределения оперативной и дисковой памяти в Squid; теперь применим теорию к практике исходя из того, что мы имеем компьютер с 4GB оперативной памяти и двумя дисками неограниченного объёма:

# cat /etc/squid3/squid-ordinary-cache.conf


# Cache: begin

# Определяем объём оперативной памяти, которую мы готовы выделить Squid для хранения служебных данных. Весь выделенный объём памяти будет зарезервирован Squid на случай оперативной необходимости
#
memory_pools on
memory_pools_limit 256 MB

# Определяем объём оперативной памяти, доступной Squid для "быстрого кеширования", размещения в ней объектов кеширования. Этот параметр определяет именно размер "быстрого кеша", а не объём памяти, выделенный процессу Squid для его служебных нужд (индекс, буферы, delay_pools и тому подобное)
#
cache_mem 512 MB

# Указываем максимальный объём объекта, хранимого в оперативной памяти ("быстрый кеш"). Хранить будем объекты вроде файлов CSS, Java-скриптов и мелких картинок
#
maximum_object_size_in_memory 64 KB

# Укажем Squid фиксировать в журналах событий "cache.log" и "syslog" факт использования оперативной памяти свыше указанного лимита
#
high_memory_warning 3 GB

# Указываем тип, место, объём MB, количество разделов первого уровня и количество подразделов второго уровня директории кеширования
#
cache_dir ufs /var/spool/squid3/ordinary 30720 48 160
cache_dir ufs /mnt/squid/spool/ordinary 30720 48 160

# Учитывая то, что дисковый кеш рассредоточен по нескольким дискам, выбираем цикличный алгоритм распределения сохраняемых файлов (вначале на один диск, потом на другой, потом на следующий и так далее, по кругу); таким образом мы добьёмся большей производительности дисковой подсистемы
#
store_dir_select_algorithm round-robin

# Указываем максимальный объём объекта, подлежащего "дисковому кешированию" (будем сохранять дистрибутивы не особо крупного размера)
#
maximum_object_size 256 MB

# Указываем минимальный объём объекта, который может быть сохранён в "дисковом кеше" (выберем какое-нибудь значение, чтобы отсечь мусорные запросы, которые совершенно ни к чему записывать на диск или в память, обработка которых может забить оперативную память разросшимся индексом "кеша")
#
minimum_object_size 0,05 KB

# Указываем уровень заполнения дискового кеша в процентах, при достижении которого начинается ускоренный процесс удаления старых объектов; для большого кеша эти границы следует поднимать, так как 1% от 100GB - это 1GB:
#
cache_swap_high 99

# Указываем серверу не тратить ресурсы на удаление старых объектов, если объём дискового кеша не занят более, чем на указанный процент
#
cache_swap_low 95

# Указываем серверу продолжать загрузку объекта если она осуществлена более чем на указанный процент, даже если клиент её оборвал
#
quick_abort_pct 90

# Уточняем серверу манеру поведения при запросе объекта на докачку (offset_limit равный -1 вынуждает загружать весь объект в кеш до того как начать передачу клиенту; offset_limit равный 0 указывает Squid никогда не грузить больше, чем клиент запросил; offset_limit равный определенному числу означает, что Squid будет грузить весь объект до отдачи его клиенту, если начало запроса меньше этого числа). Выбираем автоматическую докачку небольших объектов, чтобы они целыми попадали в "дисковый кеш"
#
range_offset_limit 1024 KB

# Устанавливаем максимальный размер объекта получаемого клиентом (2GB) чтобы избежать самых примитивных нерациональных загрузок
#
reply_body_max_size 2048 MB

# Дадим Squid возможность в кешировании большего количества (число IP-адресов) DNS-запросов, чем это определено по умолчанию (меньше будет отвлекаться для очистки кеша от устаревших адресов)
#
ipcache_size 8192

# Определим верхний и нижний уровень заполнения кеша IP-адресов (в процентах) в рамках которого будет отрабатывать алгоритм (LRU) удаления старых объектов
#
ipcache_high 98
ipcache_low 80

# Дадим Squid возможность в кешировании большего количества (число записей) FQDN-записей (параметр не совсем понятный, особенно в свете того, что для него нет правила очистки кеша от устаревших записей, как это сделано для ipcache_size; подозреваю, что это работает тогда, когда нужно осуществить обратное разрешение имени исходя из имеющегося IP-адреса, что в типовой конфигурации Squid не подразумевается)
#
fqdncache_size 8192

# Refresh patterns: begin
# Отдельно опишем правила хранения в "дисковом кеше" для некоторых типов объектов
#
refresh_pattern -i \.zip$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.rar$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.cab$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.arj$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.tar$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.gz$  1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.tgz$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.bz2$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.rpm$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.deb$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.exe$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
#
refresh_pattern -i \.ppt$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.pdf$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
refresh_pattern -i \.txt$ 1440 100% 129600 ignore-no-cache reload-into-ims override-lastmod
#
refresh_pattern . 0 80% 14400

# Refresh patterns: end

# Cache: end

Для информации прилагаю расшифровку параметров настройки правил хранения в "дисковом кеше":

refresh_pattern -i regex min percent max options

Где:

regex - регулярное выражение. Описывает адреса, к которым применимо это правило;
min - минимальное время, в течении которого объект считается новым (время (в минутах), которое объект, имеющийся в кеше и не имеющий явного указания срока действия считается свежим);
percent - процент от возраста объекта с явным указание срока актуальности, в течении которого объект считается новым;
max - указывает верхний предел времени, в течении которого объект считается новыми (время (в минутах), которое объект, имеющийся в кеше и не имеющий явного указания срока действия считается свежим);
options - опции, перечисляемые через пробел. Самые интересные из них:
override-expire - заставляет игнорировать факт истечения времени актуальности объекта (игнорировать информацию об истечении свежести объекта и использовать min);
override-lastmod - заставляет игнорировать переданное сервером время последней модификации объекта (игнорировать информацию о дате изменения файла и использовать min);
ignore-reload - заставляет игнорировать запрос reload от клиента и выдавать версию объекта из кэша (игнорировать запросы клиентов "не кешировать документы" (no-cache) или "перезагрузить документ" (reload));
ignore-no-cache - заставляет игнорировать заголовок no-cache с сервера и принудительно кэшировать объект;
reload-into-ims - вместо запроса клиентского запроса "не кешировать документы" (no-cache) посылать запрос "Если изменен с" (If-Modified-Since).

Проверяем конфигурационный файл на наличие ошибок, перед запуском его в работу:

# squid3 -f /etc/squid3/squid-ordinary-cache.conf -k parse

Processing Configuration File: /etc/squid3/squid-ordinary-cache.conf (depth 0)
....
2011/10/05 18:49:10| WARNING: use of 'override-lastmod' in 'refresh_pattern' violates HTTP
2011/10/05 18:49:10| WARNING: use of 'reload-into-ims' in 'refresh_pattern' violates HTTP
2011/10/05 18:49:10| WARNING: use of 'ignore-no-cache' in 'refresh_pattern' violates HTTP
....

Squid предупредит нас о том, что применяемые опции противоречат спецификациям HTTP и он слагает с себя ответственность за некорректную доставку запрошенных ресурсов. Что-же, мы на это идём сознательно и применяем правила лишь там, где нам это нужно - при сохранении дистрибутивных файлов.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )