The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз Memcached 1.6.0 с включением поддержки внешнего хранилища

09.03.2020 09:41

Состоялся значительный релиз системы кэширования данных в оперативной памяти Memcached 1.6.0, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширования доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD.

В новой версии стабилизирована реализация хранилища "extstore", которое теперь собирается по умолчанию (для отключения в скрипте configure предусмотрена опция "--disable-extstore"), но требует явной активации при запуске (старые установки после обновления продолжат работу без изменения). Несмотря на то, что в целом хранилище "extstore" признано стабильным, рекомендуется соблюдать осторожность при его внедрении в очень крупных системах.

Extstore позволяет использовать SSD/Flash-накопители для расширения размера кэша. Как и при использовании оперативной памяти, хранилище на Flash не является постоянным и сбрасывается при перезапуске. В качестве области применения нового режима называется обеспечения эффективного кэширования данных большого размера. При использовании "extstore" ключи и метаданные, как и раньше, хранится только в оперативной памяти, но связанные с ключами большие данные, размер которых превышает установленный порог, сохраняются во внешнее хранилище, а в ОЗУ остаётся только указатель.

Если с ключом связываются данные небольшого размера, то Memcached работает как обычно, держит данные в памяти и не обращается к внешнему хранилищу. Если свободной памяти много, то наиболее востребованные данные дополнительно могут полностью находиться в кэше в оперативной памяти (например можно указать, чтобы на Flash сбрасывались только объекты больше 1024 байт, к которым не было обращений 3600 секунд").

Реализация оптимизирована для обеспечения максимальной производительности и минимальной нагрузки на CPU, в ущерб эффективности хранения (большой уровень фрагментации). Для продления ресурса Flash-накопителей данные буферизируются и сбрасываются в хранилище последовательно. Для сохранения состояния кэша между перезапусками может применяться появившаяся в выпуске 1.5.18 возможность сброса дампа с кэшем в файл. При следующем запуске можно восстановить кэш из данного файла для исключения пиков нагрузки на обработчики контента из-за незаполненности кэша (кэш сразу становится "тёплым").

Вторым важным изменением в Memcached 1.6 стала переработка кода для сетевого взаимодействия, который адаптирован для автоматической обработки пакетных обращений в рамках одного системного вызова. Раньше, при передаче нескольких команд "GET" в одном TCP-пакете, memcached отправлял результаты с выполнением отдельных системных вызовов. В Memcached 1.6 ответы агрегируются и возвращаются через отправку одного системного вызова. Как результат, в среднем теперь приходится 1.5 ключа на системный вызов, что демонстрирует в тестах снижение нагрузки на CPU до 25% и сокращение задержек на несколько процентов.

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

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

  1. Главная ссылка к новости (https://github.com/memcached/m...)
  2. OpenNews: Релиз Memcached 1.5.18 с поддержкой сохранения кэша между перезапусками
  3. OpenNews: Релиз Memcached 1.5.15 с поддержкой аутентификации для протокола ASCII
  4. OpenNews: Первый стабильный релиз СУБД Membase Server
  5. OpenNews: Выпуск СУБД Redis 5.0
  6. OpenNews: Выпуск СУБД Couchbase Server 4.0, сочетающей возможности CouchDB, memcached и Membase
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52507-memcached
Ключевые слова: memcached, nosql, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, Аноним (4), 13:07, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    Стильно, модно, молодежно!
     
     
  • 2.22, IRASoldier_registered (ok), 17:16, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Уже 15 лет как в продакшене дофига где. То что ты про это ничего не слышал раньше - ну, вот подумай теперь, у кого на самом деле "молодёжно".
     
     
  • 3.25, Аноним (25), 09:25, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так может тому дедушке уже 80 лет и он до сих пор еще сопровождает задачи на досовском паскале - голые массивы и указатели вертит, а про интернет только вчера узнал.
     
     
  • 4.26, IRASoldier_registered (ok), 12:36, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На Фортране, на ЕС 1010, а вместо Интернета фельдъегеря перфоленту доставляют в шарашку.
     
  • 3.27, Аноним (27), 13:47, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тот что 15 лет в продакшне - к этой поделке пейсбука уже никакого отношения не имеет.
    А тут, действительно, стильно-модно, с подворотиками. А что изначальные идеи давно похоронены и разлагаются - пейсбука не беспокоит.
     
     
  • 4.29, IRASoldier_registered (ok), 15:17, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Зайди на офсайт memcached, вдумчиво почитай эбауты и узбагойся.


     
  • 3.32, НамаНама (?), 19:23, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и что? Дельфин тоже дофига используется. От этого лучше он не становится. Глупые выбирают то, что плавает на поверхности. Увы, это аксиома.
     
     
  • 4.41, IRASoldier_registered (ok), 16:44, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну давай, расскажи нам об альтернативах, которые использует умная элита типа тебя.
     

  • 1.5, Аноним (5), 13:50, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Memcrashed
     
     
  • 2.28, Аноним (28), 14:55, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Факты
     

  • 1.6, gogo (?), 14:28, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А файл, используемый для extstore тоже кешируется в ОЗУ... ))
    Жаль, что не свопится )
     
     
  • 2.23, Аноним (23), 21:03, 09/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    это если на сервере есть свободная память (а обычно её нет, т.к. она вся отдана memcached).
     

  • 1.10, Аноним (10), 16:48, 09/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >объекты больше 1024 байт

    Это 1 кибибайт, страница памяти 4 и более. Размер сектора на современных hdd больше 4к, раньше сектор был 512 байт, например. Меньше записать нельзя, и фс накладывает дополнительные ограничения (запись блоками в 64к вполне обычное дело). Физически это всё выглядит ещё более странно (особенно на SMR моделях). На ссд размер блока, который записывается разом что-то там порядка 32 миллионов.

    Так вот, сабж как-то упаковывает данные, или нет? Кто-нибудь это вообще делает? Может ведь быть и сотня байт, но таких сущностей при этом миллионы. Очень часто вижу ситуации, что метаинформация объектов занимает едва ли не больше, нежели сами данные.

     
     
  • 2.24, Аноним (24), 04:59, 10/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, что там у Фейсбука, но каноничный memcached выделяет память не поэлементно, а крупными блоками (slab-ами), slab-ы разного "класса" соответствуют объектам размера 2^n (с округлением вверх) с целью избежания фрагментации.

    Могу предположить, что фейсбуковские патчи банально используют SSD как хранилище slab-ом "больших" классов.

     

  • 1.30, НамаНама (?), 19:16, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Типичный путь неофита: сначала нужно взять что-то попроще, а потом, когда привыкнешь, это "попроще" превратить в уродливую монстрятину.
    "Сон разума рождает... мемкэши и ноусиквелы"
     
     
  • 2.33, Аноним (33), 20:49, 11/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Фейсбук делает для личных нужд форк мемкеша, который по непонятным причинам называется официальной версией.

    Оригинальный мемкеш в доработках не нуждается, поскольку идеален.

     
     
  • 3.37, пох. (?), 10:22, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну хоть один в теме, а не "на официальном сайте абаутов" начитался.

    Не, не идеален - это ты поймешь сразу же, как тебе понадобится failover или sharding - т.е. ты перестанешь помещаться в одну машину.
    И либо придется строить миллионы костылей и подпорок, либо плюнуть на O(1) и вообще предсказуемость и валить на redis.
    Пейсбука эти проблемы, предсказуемо, не колышут, он десять лет назад себе это уже накостылил, а теперь решает проблемы костылями для этих костылей, уродуя не идеальный, но простой и надежный код.

     
     
  • 4.42, Аноним (24), 18:37, 14/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нормально все делается на application level. Ketama hash и вариации на тему.

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

     
     
  • 5.43, пох. (?), 17:55, 16/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну и чего ж "нормального" в том что ты логику работы с шардингом и фэйловер вынужден выносить в "application level", вместо того чтобы предоставить базе заниматься всем этим как может и как умеет (возможно, что-то и соптимизировав, тебе недоступное, поскольку она лучше знает что у нее в данный момент где хранится), зато архинужное "сохранение принципиально неперсистентных данных на ssd" - впиндюрено ей в код (хотя ему как раз место именно в application, только она знает - что имеет смысл хранить таким образом, а что совершенно незачем)

    Ты, часом, не в фейсбуке работаешь? У них там так принято, ага.

     

  • 1.31, НамаНама (?), 19:18, 11/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А зачем это? Все массвовые серверные ОС и сами умеют кэшировать. Экземпляры всех современных РСУБД работают тоже исключительно через кэш. Балансировщики и прокси имеют свои кэши. Зачем ещё вот это?
     
     
  • 2.34, Аноним (33), 14:15, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Подсказка: Фейсбук работает более чем на одном сервере.
     
  • 2.35, Аноним (33), 14:16, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подсказка вторая: в MySQL такой кэш, что лучше бы его не было
     
     
  • 3.36, НамаНама (?), 19:55, 12/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Только болваны используют MySQL. Хотя, только болваны и мемкэш используют. Всё же самый ценный работник "технологической компании" это PR.
     
  • 3.38, пох. (?), 10:27, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вот не надо - там механика взаимодействия с хранилищем такая, что если бы и такого не было - вообще бы ничего и ни у кого не работало.
    Ты легко можешь это проверить, уменьшив все кэши до минимумов.

    Ну а чо, еще, штоль, кто-то есть?

    Моооожет, ты хочешь немнооожечко mongo? Признайся - хочешь ведь?
    Стой, стой, пошутил я!

     
     
  • 4.39, Аноним (24), 15:36, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    я про query cache с глобальным локом. Внутренние кэши innodb ок, конечно.

    Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов. Как френдлента в ЖЖ (вроде ради нее memcached и придумали).

     
     
  • 5.44, пох. (?), 18:02, 16/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > я про query cache с глобальным локом

    ну вот без него - еще хуже, если, конечно, все запросы не исключительно where id=....
    Можешь легко проверить ;-)

    > Но на самом деле memcached нужен для централизованного кэширования собранного с разных серверов.

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

    Но мы вот вынуждены были сбежать на редис, потому что ТАКОЙ фэйловер нам нафиг не упал.
    Но у нас, к счастью, там интранет, он подождет.

     
  • 4.40, Аноним (24), 15:41, 13/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, Монгу не хочу, спасибо. если нужно schemaless, постгрес с таблицами вида (serial, jsonb) намного шустрее и фичастее (инвертированные индексы на json зачастую куда уместнее btree), а шардинг я и сам делать умею :)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру