Какие на практике существуют стратегии кэширования linux

Обновлено: 01.07.2024

У меня довольно старый сервер с 4 ГБ оперативной памяти, и он в значительной степени обслуживает одни и те же файлы весь день, но он делает это с жесткого диска, а 3 ГБ оперативной памяти «свободны».

Любой, кто когда-либо пытался запустить ram-drive, может засвидетельствовать, что это awesome с точки зрения скорости. Использование этой системы памяти обычно не превышает 1 ГБ /4 ГБ, поэтому я хочу знать, есть ли способ использовать эту дополнительную память для чего-то хорошего.

  • Возможно ли, чтобы файловая система всегда обслуживала определенные файлы из ОЗУ?
  • Есть ли какие-либо другие методы, которые я могу использовать для улучшения возможностей чтения файлов с помощью ОЗУ?

В частности, я не ищу здесь «взломать». Я хочу, чтобы системные вызовы файловой системы обслуживали файлы из ОЗУ без необходимости создавать ram-drive и копировать файлы там вручную. Или, по крайней мере, сценарий, который делает это для меня.

  • Веб-серверы со статическими файлами, которые читаются alot
  • Серверы приложений с большими библиотеками
  • Настольные компьютеры со слишком большим объемом оперативной памяти
  • Нашел это очень информативно: Кэш-страница Linux и pdflush
  • Как отметил Зан, память на самом деле не свободна. Я имею в виду, что он не используется приложениями, и я хочу контролировать, что должно быть кэшировано в памяти.

vmtouch кажется хорошим инструментом для работы.

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

EDIT: Использование, заданное в вопросе, приведено в примере 5 на vmtouch Hompage

EDIT2: Поскольку отметил в комментариях, в настоящее время существует репозиторий git .

Это также возможно с помощью утилиты vmtouch виртуальной памяти Toucher .

Инструмент позволяет вам управлять кешем файловой системы в системе Linux. Вы можете принудительно или заблокировать определенный файл или каталог в подсистеме кэша VM или использовать его для проверки того, какие части файла /каталога содержатся в VM.

После некоторого подробного ознакомления с функциями замены ядра и кэширования я обнаружил «fcoretools». Что состоит из двух инструментов:

(Если кто-то найдет это интересным, я публикую это здесь)

Уловка бедняка для получения информации в кеш файловой системы - это просто кошка и перенаправление на /dev /null.

Linux будет кэшировать столько дискового ввода-вывода в памяти, сколько может. Это такова статистика кэша и буферной памяти. Это, вероятно, будет лучше работать, чем вы будете хранить правильные вещи.

Однако, если вы настаиваете на сохранении своих данных в памяти, вы можете создать привод ram с использованием tmpfs или ramfs. Разница заключается в том, что ramfs будет выделять всю память, которую вы запрашиваете, поскольку tmpfs будет использовать только память, которую использует ваше блочное устройство. Моя память немного ржавая, но вы должны уметь:

, а затем скопируйте данные в каталог. Очевидно, что когда вы выключите или отключите этот раздел, ваши данные будут потеряны.

Существуют две настройки ядра, которые могут значительно помочь даже без использования других инструментов:

swappiness

сообщает linux kernel, насколько агрессивно он должен использовать swap. Цитирование статьи в Википедии:

Swappiness - это свойство ядра Linux, которое изменяет баланс между заменой памяти во время выполнения, в отличие от удаления страниц из кеша системной страницы. Swappiness может быть установлен в значения от 0 до 100 включительно. Низкое значение означает, что ядро ​​попытается избежать как можно большего количества обменов, где более высокое значение вместо этого заставит ядро ​​агрессивно попытаться использовать пространство подкачки. Значение по умолчанию равно 60, и для большинства настольных систем установка 100 может повлиять на общую производительность, тогда как установка его ниже (даже 0) может улучшить интерактивность (уменьшение задержки ответа).

vfs_cache_pressure

Управляет тенденцией ядра восстанавливать память, которая используется для кэширование каталогов и объектов inode.

При значении по умолчанию vfs_cache_pressure = 100 ядро ​​будет пытаться восстанавливать зубные щетки и иноды по «справедливой» ставке в отношении pagecache и восстановление swapcache. Уменьшение vfs_cache_pressure заставляет ядро ​​предпочитать для сохранения зубных и inode-кэшей. .

Установив swappiness high (например, 100), ядро ​​перемещает все, что ему не нужно менять, освобождая RAM для кеширования файлов. И, установив vfs_cache_pressure ниже (допустим, до 50, а не до 0!), Это будет способствовать кэшированию файлов вместо хранения данных приложения в ОЗУ.

(Я работаю над большим проектом Java, и каждый раз, когда я его запускаю, он занимал много оперативной памяти и удалял кеш диска, поэтому в следующий раз, когда я скомпилировал проект, все было снова прочитано с диска. , Мне удается хранить источники и скомпилировать выходные данные в кэше в ОЗУ, что значительно ускоряет процесс.)

Я очень сомневаюсь, что он фактически служит для файлов с диска с 3 ГБ оперативной памяти. Кэширование файлов Linux очень хорошее.

Если вы видите диск IO, я бы посмотрел ваши конфигурации ведения журнала. Многие журналы устанавливаются как небуферизованные, чтобы гарантировать, что последняя информация журнала доступна в случае сбоя. В системах, которые должны быть быстрыми независимо, используйте буферизованный журнал ввода-вывода или используйте удаленный сервер журнала.

Если у вас много памяти, вы можете просто читать файлы, которые вы хотите кэшировать с помощью cat или аналогичных. После этого Linux будет хорошо справляться с этим.

Возможно, у вас есть программа, которая просто mmap с вашими файлами будет продолжать работать.

Существуют различные системы ramfs, которые вы можете использовать (например, ramfs, tmpfs), но в целом, если файлы на самом деле читаются, часто они сидят в кеше файловой системы. Если ваш рабочий набор файлов больше вашего бесплатного плунжера, тогда файлы будут удалены из него, но если ваш рабочий набор больше вашего свободного бара, вы не сможете поместить его в ramdisk.

Проверьте вывод команды «free» в оболочке - значение в последнем столбце в разделе «Cached» означает, сколько вашего свободного бара используется для кеша файловой системы.

Что касается вашего последнего вопроса, убедитесь, что ваша оперативная память находится на разных каналах памяти, чтобы процессор мог получать данные параллельно.

Я думаю, что это можно было бы лучше решить на уровне приложений. Например, для этого есть, вероятно, специализированные веб-серверы, или вы можете рассмотреть mod_cache с Apache. Если у вас есть определенная цель, например, обслуживание веб-контента быстрее, то вы можете получить улучшения, которые я думаю.

Но ваш вопрос носит общий характер, подсистема памяти Linux предназначена для обеспечения наилучшего общего использования ОЗУ. Если вы хотите настроить таргетинг на определенные типы производительности, рассмотрите возможность поиска всего в /proc /sys /vm.

Пакет fcoretools интересен, меня интересуют любые статьи о его приложении . Эта ссылка рассказывает о фактических системных вызовах, используемых в приложении.

Настольные компьютеры (например, ubuntu) уже используют предварительную загрузку файлов (по крайней мере, популярных разделяемых библиотек) в память при загрузке. Он используется, чтобы ускорить загрузку и время запуска различных bloarware , таких как FF, OO, KDE и GNOME (с эволюционной рассыпкой-почтой).

, хотя вам это действительно не нужно, linux будет очень хорошо выполнять кеширование файлов, которые вы используете самостоятельно.

Я просто попробовал dd if = /dev /yourrootpartition = /dev /null \ bs = 1Mcount = howmuchmemoryyouwanttofill

он не дает мне контроля, которого вы желаете, но он по крайней мере пытается использовать потерянную память.

Я использую find /-name stringofrandomcharacter это помогает alot

Не совсем то, что было задано, но я использую

найти BASE_DIRECTORY -type f -exec cat <>> /dev /null \;

, чтобы инициировать инициализацию файлов в томе AWS, созданном из моментального снимка. Это более сфокусировано, чем официальная рекомендация по использованию dd, если вы просто хотите прочитать некоторые файлы.

Иногда я могу захотеть кэшировать файлы в определенной папке и ее подпапках. Я просто перехожу в эту папку и выполняю следующее:

Недавно на одном из виртуальных серверов столкнулся с проблемой долгой записи на диск. И под эту тему нашел интересную статью, в которой подробно рассмотрен вопрос функционирования кэширования операций записи на диск в Linux. Сегодня будет перевод этой статьи.

Кэширование в Linux

При записи данных на диск (любой программой) Linux кэширует эту информацию в области памяти, называемой Page Cache (страничный кэш). Информацию об этой области памяти можно посмотреть с помощью команд free, vmstat или top. Полную информацию об этой области памяти можно посмотреть в файле /proc/meminfo. Ниже приведен пример этой файла на сервере с 4-мя GB RAM:

Размер Page Cache показан в параметре "Cached", в данном примере он составляет 2,9 GB. При записи страниц в память размер параметра "Dirty" увеличивается. При начале непосредственно записи на диск будет увеличиваться параметр "Writeback" до тех пор, пока запись не закончится. Достаточно сложно увидеть параметр "Writeback" высоким, так как его значение увеличивается только во время опроса, когда операции ввода/вывода (I/O) поставлены в очередь, но еще не записаны на диск.
Linux обычно записывает данные из кэша на диск с помощью процесса pdflush. В любой момент в системе запущено от 2 до 8 потоков pdflush. В файле /proc/sys/vm/nr_pdflush_threads можно посмотреть сколько в данный момент активных потоков. Каждый раз все существующие потоки pdflush заняты по крайней мере 1 секунду. Новые потоки пытаются записать данные в свободные очереди устройств, таким образом, чтобы на каждое активное устройство был 1 поток сбрасывающий данные из кэша. Каждый раз по прошествии секунды без какой либо активности со стороны pdflush убирается 1 поток. В Linux можно настроить минимальное и максимальное количество pdflush потоков.

Настройка pdflush

Каждый поток pdflush контролируется несколькими параметрами в /proc/sys/vm:

  • /proc/sys/vm/dirty_writeback_centisecs (default 500): в сотых долях секунд. Этот параметр означает как часто pdflush возобновляет работу для записи данных на диск. По умолчанию возобновляет работу 2 потока каждые 5 секунд.
    Возможно недокументированное поведение, которое пресекает попытки уменьшения dirty_writeback_centisecs для более агрессивного кэширования данных процессом pdflush. Например, в ранних версиях ядра 2.6 Linux в файле mm/page-writeback.c код включал логику, которая описывалась "если запись на диск длится дольше, чем параметр dirty_writeback_centisecs, тогда нужно поставить интервал в 1 секунду". Эта логика описана только в коде ядра, и ее функционирование зависит от версии ядра Linux. Так как это не очень хорошо, поэтому вы будете защищены от уменьшения этого параметра.
  • /proc/sys/vm/dirty_expire_centiseconds (default 3000): в сотых долях секунд. Этот параметр указывает как долго данные могут находится в кэше, после чего должны быть записаны на диск. Значение по умолчанию очень долгое: 30 секунд. Это означает, что при нормальной работе до тех пор пока в кэш не запишется достаточно данных для вызова другого метода pdflush, Linux не будет записывать данные на диск, находящиеся в кэше менее 30 секунд.
  • /proc/sys/vm/dirty_background_ratio (default 10): Максимальный процент оперативной памяти, который может быть заполнен страничным кэшем до записи данных на диск. Некоторые версии ядра Linux могут этот параметр устанавливать в 5%.

В большинстве документации этот параметр описывается как процент от общей оперативной памяти, но согласно исходным кодам ядра Linux это не так. Глядя на meminfo, параметр dirty_background_ratio расчитывается от величины MemFree + Cached - Mapped. Поэтому для нашей демонстрационной системы 10% составляет немного меньше, чем 250MB, но не 400MB.

Итого: Когда pdflush начинает запись?

В конфигурации по умолчанию, данные, записываемые на диск, находятся в памяти до тех пор пока:

  • они дольше 30 секунд находятся в памяти;
  • кэшированные страницы занимают более 10% рабочей памяти.

Если на сервере операции записи происходят часто, то однажды будет достигнут параметр dirty_background_ratio, и вы сможете увидеть, что вся запись на диск идет только через этот параметр не дожидаясь истечения параметра dirty_expire_centiseconds.

Процесс записи страниц

Параметр /proc/sys/vm/dirty_ratio (default 40): Максимальный процент общей оперативной памяти, который может быть выделен под страничный кэш, до того как pdflush будет писать данные на диск.

Примечание: Во время записи на диск все процессы блокируются на запись, не только тот который заполнил буфер на запись. Это может вызвать спровоцировать блокировку одним процессов всех операций вводы/вывода в системе. Провести этот

Рекомендации по оптимизации Linux для операций, требующий частой записи

Обычно люди при попытке увеличения производительности дисковой подсистемы сталкиваются с проблемой, что Linux буферизует слишком много информации сразу. Это особенно трудно для операций, требующий синхронизации файловой системы, использующих вызовы fsync. Если во время такого вызова в кэше много данных, то система может "подвиснуть" пока не закончится этот вызов.
Другая частая проблема происходит потому что слишком много требуется записать до того, как начнется запись на физический диск, операции ввода/вывода происходят чаще, чем при нормальной работе. Вы получите более долгие периоды, когда запись на диск не происходит, пока большой кэш не будет заполнен, после чего сработает один из триггеров pdflush и данные запишутся на максимальной скорости.

dirty_background_ratio: Основной инструмент настройки, обычно уменьшают этот параметр. Если ваша цель снизить количество данных, хранимое в кэше, так что данные будут писаться на диск постепенно, а не все сразу, то уменьшение этого параметра наиболее эффективный путь. Более приемлемо значение по умолчанию для систем имеющих много оперативной памяти и медленные диски.

dirty_ratio: Второй по значимости параметр для настройки. При значительном снижении этого параметра приложения, которые должны писать на диск, будут блокироваться все вместе.

dirty_expire_centisecs: Попробуйте уменьшить, но не сильно. Позволяет уменьшить время нахождения страниц в кэше до записи на диск, но это значительно снизит среднюю скорость записи на диск, т.к. это менее эффективно. Это особенно проявится на системах с медленными дисками.

Инструкция по настройке параметров

В файле /etc/sysctl.conf вносим, например:

После синхронизируем данные кэша и диска, очистим кэш и сохраним параметры.

В системе Linux все адреса памяти являются виртуальными. Они не указывают напрямую ни на какие физические адреса в имеющейся оперативной памяти. Всякий раз когда кто- либо осуществляет доступ к некоторому расположению в памяти, выполняется механизм трансляции для подбора соответствующей физической памяти.

Давайте начнём с короткого повествования введения в применяемое понятие виртуальной памяти. Получая номер в отеле, в каждой из комнат может иметься некий частный номер. Все установленные телефоны, само собой, принадлежат данному отелю. Никто не имеет возможности подключаться напрямую извне с данным отелем.

Если вам необходимо осуществит связь с кем-то, кто занимает эту комнату, допустим, с вашим другом, тот должен выдать вам номер панели переключения в отеле и собственно номер той комнаты, в которой вы остановились. Соответствие данного часного номера знают только располагающийся на стойке ресепшена и самого занимающего комнату:

Всякий раз, когда кто-то в этом городе (или по всему миру) желает соединиться с занимающим комнату, он должен пройти имеющуюся линию оперативной поддержки. Ему необходимо знать верный номер оперативной связи с самим отелем, а также необходимый номер комнаты. Таким образом, номер панели переключения + номер комнаты = виртуальному адресу, в то время как private phone number соответствует искомому физическому адресу. Имеется ряд правил, связанных с моделью отеля, которые также относятся и к Linux:

Вы не имеете возможности контактировать с частным телефоном того, кто занимает комнату. Даже нет варианта осуществить такую покупку. Ваш вызов внезапно будет оборван.

Вы не можете получить доступ к несуществующей памяти в вашем адресном пространстве. Это вызовет отказ сегментации.

Вы не можете осуществить соединение с несуществующим жильцом комнаты или с тем, о ком не знает персонал как о поселившимся в данном отеле, либо о ком- то, о ком нет информации в имеющейся панели переключения.

Если вы осуществляете доступ к не поставленной в соответствие памяти, имеющийся ЦПУ возбуждает отказ страницы и сама ОС отрабатывает его.

Вы не можете осуществить соединение с тем, чьё пребывание в отеле завершено.

Вы не можете получить доступ к высвобождённой памяти. Может оказаться, что она уже была выделена другому процессу.

Многие отели имеют один и то же бренд, однако они расположены в различных местоположениях, причём каждый из них имеет различные номера оперативной связи.

Различные процессы могут иметь одни и те же виртуальные адреса, которые соответствуют их адресному пространству, однако указывающие на другие физические адреса.

Существует некая книга (или программное обеспечение с базой данных), содержащая соответствие между необходимым номером комнаты и необходимым частным номером, с которой консультируется при необходимости оператор.

Виртуальные адреса устанавливают соответствие необходимой физической памяти в соответствии с таблицами страниц., которые сопровождаются самим ядром операционной системы и выступают в качестве консультанта их процессора.

Именно так можно себе представлять то, как работают все виртуальные адреса в системе Linux.

В этой главе мы будем иметь дело со всей системой управления памяти Linux, охватывая следующие разделы:

Схемы памяти, применяемые при трансляции адресов и MMU

Механизмы выделения памяти (блок распределения страниц, блок распределения листов - slab, блок распределения kmalloc и так далее)

Доступ ввода/ вывода памяти

Установление соответствия памяти ядра пространству пользователя и реализации функции обратного вызова mmap()

Введение в систему кэширования Linux

Введение в инфраструктуру ресурсов управления имеющимися устройствами ( devres )

Схема памяти системы - пространство ядра и пространство пользователя

На протяжении данной главы такие термины как пространство ядра (kernel space) и пространство пользователя (user space) будут относиться к их виртуальному адресному пространству. В системах Linux всякий процесс обладает собственным виртуальным адресным пространством. Это некий вид песочница памяти на время жизни данного процесса. В системах с 32 битами это адресное пространство составляет 4ГБ в размере (даже для систем с физическим размером менее 4ГБ). Для каждого процесса это адресное пространство в 4ГБ расщепляется на две части:

Виртуальные адреса пространства пользователя

Виртуальные адреса пространства ядра

Тот способ, которым осуществляется данное расщепление зависит от специальной опции настройки ядра, CONFIG_PAGE_OFFSET , которая определяет где начинаются адреса самого ядра в адресном пространстве некоего процесса. Обычным значением является значение по умолчанию 0xC0000000 в 32- битных системах, однако его можно изменять, как это имеет место в случае процессоров семейства i.MX6 от NXP, которые используют 0x80000000 . Во всей данной главе мы будем считать значением по умолчанию адрес 0xC0000000 . Такое расщепление именуется как расщепление 3G/1G, при котором пространству пользователя предоставляются нижние 3ГБ виртуального адресного пространства, а само ядро применяет оставшийся 1ГБ верхних адресов. Некая типичная схема виртуального адресного пространства процесса выглядит следующим образом:

Оба адреса, применяемые и пространством ядра, и пространством пользователя, являются виртуальными адресами. Единственная разница состоит в том, что доступ к некоторому адресу ядра требует какого- то привилегированного режима. Привилегированные режим имеет расширенные полномочия. Когда ЦПУ осуществляет исполнение кода на стороне пространства пользователя, такой активный процесс именуется как исполняемый в определённом режиме пользователя; когда этот ЦПУ исполняет код на стороне своего ядра, такой активный процесс именуется исполняемым в режиме ядра.

Определяя некий адрес (естественно, виртуальный), можно различить будет ли это адрес пространства ядра или адрес пространства пользователя, применяя приведённую выше схему процесса. Всякий адрес, попадающий в 0-3ГБ поступает из пространства пользователя, в противном случае он из своего ядра.

Имеется некоторая причина почему имеющееся ядро разделяет своё адресное пространство со всеми процессами: а именно, потому что всякий отдельный процесс в некий определённый момент времени применяет системные вызовы, которые вовлечены в имеющееся ядро. Установление соответствия такого виртуального адреса памяти ядра адресному пространству каждого процесса позволяет нам избегать стоимости переключения адресного пространства памяти при каждом входе в (и выходе из) имеющееся ядро. Именно по этой причине данное адресное пространство ядра непрерывно ставится в соответствие в верхних адресах каждого процесса, чтобы ускорить доступ к ядру при вызовах системы.

некая памяти страница, виртуальная страница или просто страница являются терминами, применяемыми для ссылки на непрерывный блок виртуальной памяти фиксированной длины. Аналогичное наименование, page , применяется как некая структура данных ядра для представления какой- то страницы памяти.

С другой стороны, кадр (frame, или страничный блок) указывает на некий непрерывный блок фиксированного размера физической памяти в верхних адресах, в которых данная операционная система ставит в соответствие некую страницу памяти. Каждый страничный блок определяется неким номером, PFN ( page frame number , номером страничного блока). Задавая некую страницу можно легко получить её PFN и наоборот, применяя макросы page_to_pfn и pfn_to_page , что подробно будет обсуждено в следующих разделах.

Некая таблица страниц является определяющей структурой данных ядра и архитектуры, применяемой для имеющегося соответствия между виртуальными адресами и физическими адресами. Определённый ключ пары страница/ кадр задаёт некую единичную запись в данной таблице страниц. Это и представляет из себя соответствие.

Так как некая страница памяти ставится в соответствие страничному блоку, само собой разумеется, что страницы и страничные блоки имеют один и тот же размер, в нашем случае 4кБ. Данный размер страницы определяется в самом ядре посредством макроса PAGE_SIZE .

Существуют ситуации, при которых необходимо выравнивать память на границы страниц. Говорят, что некая память является выравненной на границу страниц, если её адреса начинаются в точности в самом начале какой- то страницы. Например, в системе с размером страницы 4K, 4 096, 20 480, 409 600 представляют собой адреса памяти выравненные на границу страниц. Другими словами, всякая память, адрес которой является произведением имеющегося размера страницы именуется выравненным на границу страницы.

Адресация ядра - понятие нижних и верхних адресов памяти

Ядро Linux имеет своё собственное виртуальное адресное пространство, как это имеется в случае режима каждого процесса пользователя. Такое виртуальное адресное пространство самого ядра (с размером в 1ГБ при расщеплении 3G/1G) подразделяется на две части:

Надежные распределенные вычислительные системы и приложения стали краеугольным камнем выдающихся предприятий, особенно в области автоматизации и управления критически важными бизнес-процессами и предоставления услуг клиентам. Как разработчики и системные администраторы этих систем и приложений, вы должны предоставлять все виды решений в области информационных технологий (ИТ), которые обеспечат вам наиболее эффективные системы.

Это включает в себя такие задачи, как проектирование, тестирование и реализация стратегий для производительности, надежности, доступности и масштабируемости системы / приложения, чтобы предоставить конечным пользователям удовлетворительный уровень обслуживания. Кэширование - это одна из многих, очень простых, но эффективных технологий доставки приложений, на которые вы можете положиться. Прежде чем мы пойдем дальше, давайте кратко рассмотрим, что такое кэширование, где и / или как его можно применять, и его преимущества?

Что такое кеширование или кеширование контента?

Кэширование (или кеширование содержимого) - это широко используемый метод хранения копий данных во временном хранилище (также известном как кэш), так что к ним можно легко и быстро получить доступ, чем при их извлечении из исходного хранилища. Данные, хранящиеся в кэше, могут включать в себя файлы или фрагменты файлов (такие как файлы HTML, сценарии, изображения, документы и т. Д.), Операции или записи базы данных, вызовы API, записи DNS и т. Д., В зависимости от типа и цели кэширования.

Кеш может быть в форме аппаратного или программного обеспечения. Программный кеш (о котором идет речь в этой статье) может быть реализован на разных уровнях стека приложений.

Другим примером кэширования на стороне клиента является DNS-кэширование, которое происходит на уровне операционной системы (ОС). Это временное хранилище информации о предыдущих поисках DNS операционной системой или веб-браузером.

Кэширование также может быть реализовано на сетевом уровне, либо в локальной сети, либо в глобальной сети через прокси. Типичным примером такого типа кэширования являются CDN (сети доставки контента), которые представляют собой глобально распределенную сеть веб-прокси-серверов.

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

кэширование или запоминание приложения (используется при чтении файлов с диска, данных из других служб или процессов или при запросе данных из API и т. д.).

кэширование базы данных (для обеспечения доступа в памяти к часто используемым данным, таким как запрошенные строки базы данных, результаты запроса и другие операции).

Обратите внимание, что данные кэша могут храниться в любой системе хранения, включая базу данных, файл, системную память и т. Д., Но должны быть более быстрым носителем, чем первичный источник. В этом отношении кэширование в памяти является наиболее эффективной и широко используемой формой кэширования.

Зачем использовать кеширование?

Кэширование предлагает множество преимуществ, включая следующие:

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

На уровне приложения кэш может хранить часто читаемые данные в самом процессе приложения, тем самым сокращая время поиска данных с секунд до микросекунд, особенно по сети.

Принимая во внимание общую производительность приложений и серверов, кэширование помогает снизить нагрузку на сервер, задержку и пропускную способность сети, поскольку кэшированные данные передаются клиентам, тем самым улучшая время отклика и скорость доставки клиентам.

Кэширование также обеспечивает доступность контента, особенно через CDN, и многие другие преимущества.

В этой статье мы рассмотрим некоторые из лучших инструментов с открытым исходным кодом (приложения / базы данных и кэширование прокси-серверов) для реализации кэширования на стороне сервера в Linux.

1. Redis

Redis (REmote DIctionary Server in full) - это бесплатная, быстрая, высокопроизводительная и гибкая распределенная вычислительная система с открытым исходным кодом, которая может использоваться на большинстве, если не на всех языках программирования.

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

Его основные функции включают в себя репликацию Redis Master-Slave (которая является асинхронной по умолчанию), высокую доступность и автоматическое восстановление после отказа, предлагаемые с помощью Redis Sentinel, кластер Redis (вы можете масштабировать горизонтально, добавляя больше узлов кластера) и разделение данных (распределение данных между несколькими экземплярами Redis). ). Он также поддерживает транзакции, сценарии Lua, ряд вариантов сохранения и шифрование связи клиент-сервер.

Будучи базой данных в памяти, но постоянной на диске, Redis предлагает лучшую производительность, когда она лучше всего работает с набором данных в памяти. Однако вы можете использовать его с базой данных на диске, такой как MySQL, PostgreSQL и многими другими. Например, вы можете взять в Redis очень тяжелые для записи небольшие данные и оставить другие фрагменты данных в базе данных на диске.

Redis поддерживает безопасность разными способами: один с помощью функции «защищенного режима» для защиты доступа к экземплярам Redis из внешних сетей. Он также поддерживает аутентификацию клиент-сервер (где пароль настраивается на сервере и предоставляется на клиенте) и TLS на всех каналах связи, таких как клиентские соединения, каналы репликации, протокол шины Redis Cluster и многое другое.

2. Memcached

Memcached - это бесплатная, простая, но мощная система кеширования объектов с открытым исходным кодом. Это хранилище значений ключей в памяти для небольших порций данных, таких как результаты вызовов базы данных, вызовов API или рендеринга страниц. Он работает в Unix-подобных операционных системах, включая Linux и OS X, а также в Microsoft Windows.

Являясь инструментом разработчика, он предназначен для повышения скорости динамических веб-приложений за счет кэширования содержимого (по умолчанию - кэш-память с наименьшим количеством недавно использовавшихся (LRU)), что позволяет снизить нагрузку на базу данных на диске - он действует как кратковременная память для Приложения. Он предлагает API для самых популярных языков программирования.

Memcached поддерживает строки как единственный тип данных. Он имеет архитектуру клиент-сервер, где половина логики происходит на стороне клиента, а другая половина - на стороне сервера. Важно, что клиенты понимают, как выбрать сервер для записи или чтения элемента. Кроме того, клиент очень хорошо знает, что делать, если он не может подключиться к серверу.

Хотя система распределенного кэширования поддерживает кластеризацию, серверы Memcached отключены друг от друга (т.е. они не знают друг друга). Это означает, что нет поддержки репликации, как в Redis. Они также понимают, как хранить и извлекать предметы, управлять, когда выселять или повторно использовать память. Вы можете увеличить доступную память, добавив больше серверов.

Начиная с Memcached 1.5.13, он поддерживает аутентификацию и шифрование через TLS, но эта функция все еще находится на экспериментальной стадии.

3. Apache Ignite

Apache Ignite, также свободно распространяемая горизонтально-масштабируемая распределенная система хранения значений ключей, кэш-памяти и многомодельная база данных с горизонтальным масштабированием и открытым исходным кодом, предоставляющая мощные API обработки для вычисления распределенных данных. Это также сетка данных в памяти, которую можно использовать либо в памяти, либо с собственным постоянством Ignite. Он работает в UNIX-подобных системах, таких как Linux, а также Windows.

Он имеет многоуровневое хранилище, полную поддержку SQL и транзакции ACID (атомарность, согласованность, изоляция, долговечность) (поддерживаются только на уровне API ключ-значение) для нескольких узлов кластера, совместной обработки и машинного обучения. Он поддерживает автоматическую интеграцию с любыми сторонними базами данных, включая любые СУБД (такие как MySQL, PostgreSQL, Oracle Database и т. Д.) Или хранилища NoSQL.

Важно отметить, что хотя Ignite работает как хранилище данных SQL, он не является полностью базой данных SQL. Он четко обрабатывает ограничения и индексы по сравнению с традиционными базами данных; он поддерживает первичные и вторичные индексы, но только первичные индексы используются для обеспечения уникальности. Кроме того, он не поддерживает ограничения внешнего ключа.

Ignite также поддерживает безопасность, позволяя включать аутентификацию на сервере и предоставлять учетные данные пользователя на клиентах. Существует также поддержка сокетов SSL для обеспечения безопасного соединения между всеми узлами Ignite.

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

4. Couchbase Server

Couchbase Server также является распределенной базой данных NoSQL с открытым исходным кодом, ориентированной на документы, которая хранит данные в виде элементов в формате ключ-значение. Он работает в Linux и других операционных системах, таких как Windows и Mac OS X. Он использует многофункциональный, ориентированный на документы язык запросов N1QL, который предоставляет мощные сервисы запросов и индексирования для поддержки операций с данными с точностью до миллисекунды.

Его примечательными особенностями являются быстрое хранилище значений ключей с управляемым кешем, специализированные индексаторы, мощный механизм запросов, архитектура горизонтального масштабирования (многомерное масштабирование), интеграция больших данных и SQL, безопасность полного стека и высокая доступность. ,

Couchbase Server поставляется с встроенной поддержкой нескольких экземпляров кластера, где инструмент менеджера кластеров координирует все действия узлов и предоставляет клиентам простой интерфейс для всего кластера. Важно отметить, что вы можете добавлять, удалять или заменять узлы по мере необходимости, без простоев. Он также поддерживает репликацию данных между узлами кластера, выборочную репликацию данных между дата-центрами.

Он реализует безопасность через TLS с использованием выделенных портов Couchbase Server, различных механизмов аутентификации (с использованием учетных данных или сертификатов), контроля доступа на основе ролей (для проверки каждого аутентифицированного пользователя на наличие определенных им ролей, определенных системой), аудита, журналов и сеансов. ,

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

5. Hazelcast IMDG

Hazelcast IMDG (In-Memory Data Grid) - это легковесное, быстрое и расширяемое промежуточное программное обеспечение сетки данных с открытым исходным кодом, которое обеспечивает упруго масштабируемые распределенные вычисления в памяти. Hazelcast IMDG также работает на Linux, Windows и Mac OS X и любой другой платформе с установленной Java. Он поддерживает широкий спектр гибких и родных для языка структур данных, таких как Map, Set, List, MultiMap, RingBuffer и HyperLogLog.

Hazelcast является одноранговым и поддерживает простую масштабируемость, настройку кластера (с возможностью сбора статистики, мониторинга по протоколу JMX и управления кластером с помощью полезных утилит), распределенных структур данных и событий, портирование данных и транзакции. Это также избыточно, поскольку хранит резервную копию каждой записи данных на нескольких членах. Чтобы масштабировать кластер, просто запустите другой экземпляр, данные и резервные копии будут автоматически и равномерно сбалансированы.

Он предоставляет набор полезных API для доступа к процессорам в вашем кластере для максимальной скорости обработки. Он также предлагает распределенные реализации большого количества дружественных для разработчиков интерфейсов из Java, таких как Map, Queue, ExecutorService, Lock и JCache.

К его функциям безопасности относятся элементы кластера, а также проверка подлинности клиента и контроль доступа к операциям клиента с помощью функций безопасности на основе JAAS. Он также позволяет перехватывать сокетные соединения и удаленные операции, выполняемые клиентами, шифровать связь на уровне сокетов между членами кластера и включать сокетную связь SSL / TLS. Но согласно официальной документации, большинство этих функций безопасности предлагается в версии Enterprise.

6. Mcrouter

Mcrouter - это бесплатный маршрутизатор Memcached с открытым исходным кодом для масштабирования развертываний Memcached, разработанный и поддерживаемый Facebook. Он поддерживает протокол Memcached ASCII, гибкую маршрутизацию, поддержку нескольких кластеров, многоуровневые кэши, пулы соединений, схемы множественного хеширования, маршрутизацию с префиксами, реплицированные пулы, теневое копирование рабочего трафика, онлайн-реконфигурирование и мониторинг работоспособности назначения / автоматический переход на другой ресурс.

Кроме того, он поддерживает «холодный» разогрев кеша, расширенные команды статистики и отладки, надежное качество обслуживания потока удаления, большие значения, широковещательные операции и поставляется с поддержкой IPv6 и SSL.

Он используется в Facebook и Instagram в качестве основного компонента инфраструктуры кэширования, чтобы обрабатывать почти 5 миллиардов запросов в секунду на пике.

7. Varnish Cache

Выполняя роль посредника между клиентами и исходными серверами, Varnish Cache предлагает несколько преимуществ, в том числе кеширование веб-содержимого в памяти для снижения нагрузки на веб-сервер и повышения скорости доставки клиентам.

Функции Varnish VCL (Varnish Configuration Language - гибкий язык, специфичный для домена), используемый для настройки обработки запросов и многое другое, Varnish Modules (VMODS), которые являются расширениями для Varnish Cache.

8. Squid Caching Proxy

Как и Varnish Cache, он получает запросы от клиентов и передает их указанным внутренним серверам. Когда сервер отвечает, он сохраняет копию содержимого в кеше и передает его клиенту. Будущие запросы на тот же контент будут обслуживаться из кэша, что приведет к более быстрой доставке контента клиенту. Таким образом, он оптимизирует поток данных между клиентом и сервером для повышения производительности и кэширует часто используемый контент, чтобы уменьшить сетевой трафик и сохранить пропускную способность.

Он также поддерживает функции безопасности, такие как расширенный контроль доступа, авторизация и аутентификация, поддержка SSL / TLS и ведение журнала активности.

9. NGINX

NGINX предлагает базовые возможности кэширования, когда кэшированное содержимое хранится в постоянном кэше на диске. Интересная часть кеширования контента в NGINX заключается в том, что он может быть сконфигурирован для доставки устаревшего контента из своего кеша, когда он не может получать свежий контент с серверов происхождения.

Он обычно развертывается как обратный прокси-сервер, балансировщик нагрузки, терминатор SSL / шлюз безопасности, ускоритель приложений / кэш содержимого и шлюз API в стеке приложений. Он также используется для потоковой передачи мультимедиа.

10. Apache Traffic Server

С точки зрения безопасности, Traffic Server поддерживает управление клиентским доступом, позволяя настраивать клиенты, которым разрешено использовать прокси-кэш, SSL-завершение как для соединений между клиентами и самим собой, так и между собой и исходным сервером. Он также поддерживает аутентификацию и базовую авторизацию через плагин, ведение журнала (каждого полученного запроса и каждой обнаруженной ошибки) и мониторинг.

Сервер трафика может использоваться в качестве кэша веб-прокси, прямого прокси, обратного прокси, прозрачного прокси, балансировщика нагрузки или в иерархии кэша.

Заключительные замечания

Кэширование - это одна из наиболее полезных и давно существующих технологий доставки веб-контента, которая в первую очередь предназначена для повышения скорости работы веб-сайтов или приложений. Это помогает снизить нагрузку на сервер, задержку и пропускную способность сети, поскольку кэшированные данные передаются клиентам, что повышает время отклика приложений и скорость доставки клиентам.

В этой статье мы рассмотрели лучшие инструменты кэширования с открытым исходным кодом для использования в системах Linux. Если вы знакомы с другими инструментами кэширования с открытым исходным кодом, которых здесь нет, пожалуйста, поделитесь с нами. Вы также можете поделиться своими мыслями об этой статье с нами.

Читайте также: