LINUX.ORG.RU

Memcached 1.6.0 - система кэширования данных в ОЗУ с возможностью сохранения на внешнем носителе

 

Memcached 1.6.0 - система кэширования данных в ОЗУ с возможностью сохранения на внешнем носителе

2

2

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


Memcached применяется для ускорения работы высоконагруженных сайтов или веб-приложений путём кэширования доступа к СУБД и промежуточным данным.


В новой версии при сборке по умолчанию включен параметр extstore, который и отвечает за использование внешнего носителя. Для отключения функции следует указать в ./configure параметр --disable-extstore. Однако несмотря на включенную по умолчанию сборку при запуске следует прямо указать использование этой функции.

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

Ещё одним важным нововведением стала переработка сетевого взаимодействия, которое теперь адаптировано для автоматической обработки пакетных обращений в рамках одного системного вызова. В предыдущих версий обработка каждого GET-запроса передавалась в отдельном пакете, тогда как в новой версии ответы на несколько запросов собираются в один метапакет и передаются за один раз. В результате такого нововведения была снижена нагрузка на CPU на 25%.

Также в результате этой модернизации сократилось потребление памяти на буферизацию - с 4.5 Кб до 400-500 байт на вызов, и сократилось использование функций malloc, realloc и free, что привело к меньшей фрагментации памяти. Каждый поток теперь обрабатывает свой пул буферов для чтения и записи для активных соединений. Для настройки размера этих буферов предусмотрены опции -o resp_obj_mem_limit=N и -o read_buf_mem_limt=N.

Также было объявлено о переводе в разряд «устаревших» бинарного протокола обмена с сервером. Ему на смену пришел протокол meta — текстовый вариант протокола с компактными meta-командами. В новом протоколе учтены все доступные ранее операции, использующие старые версии бинарного протокола.

>>> Официальный сайт

>>> Исходный код (лицензия BSD)

>>> Описание Extstore

>>> Описание meta-комманд

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: Zhbert (всего исправлений: 5)

опреации

испольщующие

сократило использование

привело к меньше фрагментации

anonymous
()

ЖИЗНЬ БЕЗ БОРОДЫ @ ЖИЗНЬ С БОРОДОЙ

anonymous
()
Ответ на: комментарий от Radjah

Спасибо за найденные косяки. Писал новость перед уходом с работы, не было времени вычитывать вдумчиво. Исправил.

Zhbert ★★★★★
() автор топика

путём кэширования доступа к СУБД и промежуточным данным

А СУБД кешируют свои таблицы у себя в памяти. Итого все что-то кешируют, место занимают, в то время как первый доступ к данным, который как раз может происходить чаще, чем повторы, вынужден проходить целую цепочку переадресации. По ходу имеет смысл только в случае установки на сетевой шлюз, через который данные в любом случае должны роутиться.

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

И зачем тогда оно было нужно до данного апдейта?

q0tw4 ★★★★
()

8го марта

8 марта, ибо лишние буквы не нужны.

quickquest ★★★★★
()
Ответ на: комментарий от dimgel

Не нужно.

Походу тут перекличка ниасиляторов )))

anonymous
()

Кажется всё таки нужно пояснение зачем оно, если ОС кеширует i/o, а БД тоже что то у себя кеширует.

kirill_rrr ★★★★★
()
Ответ на: комментарий от q0tw4

А СУБД кешируют свои таблицы у себя в памяти. Итого все что-то кешируют, место занимают, в то время как первый доступ к данным, который как раз может происходить чаще, чем повторы, вынужден проходить целую цепочку переадресации. По ходу имеет смысл только в случае установки на сетевой шлюз, через который данные в любом случае должны роутиться.

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

(Лично всегда испытывал необъяснимое отвращение к этой поделке).

kostyarin_ ★★
()

Судя по комментам, на лоре открыли для себя key-value. oO

anonymous
()
Ответ на: комментарий от atrus

ssdb (leveldb с интерфейсом редиса).

anonymous
()
Ответ на: комментарий от kostyarin_

генеришь страницу и кэшируешь её

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

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

Но я не спец в этом деле, так что поправьте если что.

Ну так я тоже не спец. Совсем мало читал про memcached. Так что ошибки могу допускать.

Это надо еще уметь её так генерировать, чтоб генерация была медленее, чем чтение с диска, пусть даже и ssd.

А тут вопрос в том, что само приложение вообще исключается из цикла. Например страница с новостями. Это запрос к БД. Но обновляется она только при определённых обстоятельствах. Посещаемость у неё довольно большая.

Её, страницу, можно смело вытолкнуть в кэш до бессрочно. И обновлять уже в кэше, когда появляется новая новость. И даже если навалит 100 млн посетителей – всё на себя примет Nginx и Memcached. Приложение при этом вообще исключается из цепочки включая все связанные БД.

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

Во всяком случае я себе это так представлял.


По реализации: memcached использует какие-то хитрые алгоритмы выделения памяти, включая использование huge pages, и держит всё компактно. В отличии от Redis – многопроцессорно.

kostyarin_ ★★
()
Ответ на: комментарий от kostyarin_

Есть многопоточный форк редиса.

anonymous
()

и чем же memcached лучше page cache?

anonymous
()
Ответ на: комментарий от kostyarin_

ну я к тому клоню, что если БД на том же компе, а сайт на компилируемом языке, то врядли оно долго будет генерить. Правда часто надо БД вынести кудато. Впрочем сам сайт тоже может кешировать страницы (рельсы такое с коробки умеют)

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

Я вообще memcached-ом сайты дудошу

anonymous
()
Ответ на: комментарий от Radjah

memcached - один из самых тормозных движков хранения данных. Сливает на порядок всем способам, в том числе кешированию в файлах, особенно tmpfs. Медленее только кешировать в мускуле.

anonymous
()
Ответ на: комментарий от anonymous

Ну не для кеша (немного оффтопик). Так по жизни поюзать. Логи там сливать, гуем между процессами поуправлять. Разнести логику на разные машины еще.

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

Ну не для кеша (немного оффтопик). Так по жизни поюзать. Логи там сливать, гуем между процессами поуправлять. Разнести логику на разные машины еще.

Я хз, мне раббит больше зашёл…

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.