The OpenNET Project / Index page

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

Релиз Memcached 1.5.4 с поддержкой кэша на SSD-накопителях

21.12.2017 22:15

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

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

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

Основной упор делается на обеспечении максимальной производительности и минимальной нагрузки на CPU, в ущерб эффективности хранения и потери данных после перезапуска. В лучшем случае из-за фрагментации эффективность использования выделенного постоянного хранилища составляет 80-90%. Для снижения фрагментации применяется технология уплотнения страниц памяти в хранилище. Для продления ресурса Flash-накопителей данные буферизируются и сбрасываются в хранилище последовательно. Для обработки ввода/вывода используется пул потоков, сбрасывающих данные в асинхронном режиме.

Возможность пока остаётся экспериментальной, но отмечается как достаточно стабильная и хорошо протестированная. Например, новый режим уже используется компанией Netflix в своей основной инфраструктуре. Для включения внешнего хранилища следует использовать опцию "-o ext_path=/mnt/somefile,ext_page_count=100" (где /mnt/somefile файл с БД, а 100 - число страниц хранения по 64 Мб каждая), предварительно собрав memcached с указанием "./configure --enable-extstore".

  1. Главная ссылка к новости (https://github.com/memcached/m...)
  2. OpenNews: Выпуск СУБД Redis 4.0 с новым движком репликации и поддержкой модулей
  3. OpenNews: Критические уязвимости в Memcached
  4. OpenNews: Выпуск СУБД Couchbase Server 4.0, сочетающей возможности CouchDB, memcached и Membase
  5. OpenNews: Релиз Memcached 1.4.10 со значительным увеличением производительности
  6. OpenNews: Проекту memcached исполнилось 10 лет
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/47783-memcached
Ключевые слова: memcached
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, username (??), 23:09, 21/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Оно живо. Ты смотри.
     
     
  • 2.34, Аноним (-), 09:29, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Иногда главное вовремя остановиться! Memcached отличный, полностью завершенный продукт, а фичеразвитие для него - это скорее плохо, чем хорошо!
     

  • 1.2, Crazy Alex (ok), 23:09, 21/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не пойму, а какая религия им помешала сделать персистентность? На тех же условиях, что и сейчас - без гарантий, если вам не повезло - то кэш умер, как всегда с мемкешом и было? По идее, для этого же вообще ничего не нужно?
     
     
  • 2.3, Аноним (-), 23:19, 21/12/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Лишние несколько байт на сохранение ключа вместе с данными на постоянном носителе конечно не жалко, но для синхронизации состояния, какие ключи актуальны, а какие нет, пришлось бы заметно усложнить всю архитектуру. Сейчас вся логика в ОЗУ, а на Flash только голые данные без информации об их актуальности.

     
     
  • 3.4, Аноним (-), 23:26, 21/12/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Но я бы всё же сделал, что-то типа CoW - кроме ключа сохранял бы время записи, а при запуске предусмотрел бы режим восстановления, оставляя самые свежие ключи при наличии дубликатов остающихся после перезаписи значений ключа.

     
     
  • 4.5, ыы (?), 23:38, 21/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    зачем?
     
     
  • 5.7, Аноним (-), 23:54, 21/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы кэш тёплым после перезапуска оставался.
     
     
  • 6.26, ыы (?), 08:53, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Чтобы кэш тёплым после перезапуска оставался.

    После перезапуска с какой целью и с каким временем простоя?

     
     
  • 7.36, Аноним (-), 09:56, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > После перезапуска с какой целью и с каким временем простоя?

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

     
     
  • 8.37, sabakka (?), 10:47, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    если больше трех мемкэш серверов, то проседание производительности будет незначи... текст свёрнут, показать
     
     
  • 9.43, J.L. (?), 15:15, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    я правильно понимаю что мемкешед можно держать на двух нодах с разным содержимым... текст свёрнут, показать
     
  • 2.18, KonstantinB (ok), 02:31, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вопрос в том, как реализовать дамп без блокировок.

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

    В такой ситуации единственный способ сдампиться - поступить так же, как делает Redis - тупо форкнуться. Однако здесь возникает проблема. Memcached преимущественно используется в очень высоконагруженных системах с огромным размером кэша - часто это выделенный сервер, в котором почти вся оперативка отведена под memcached. Пока все эти десятки гигабайтов запишутся на диск, произойдет куча запросов к мемкешу, в том числе и на запись, сработает линуксовый copy-on-write, и в результате задолго до того, как мы успеем все скинуть на диск, оперативка закончится и OOM killer кого-нибудь тупо прибьет.

     
     
  • 3.24, Аноним (-), 08:19, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    приличная хранилка имеет скорость 10-15 Gbyte/s сервак с 256G-512G  - запишет свою память менее чем за минуту.
     
     
  • 4.25, ыы (?), 08:30, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >10-15 Gbyte/s
    >запишет свою память

    вы имеете в виду скорость записи на диск?

     
  • 3.30, Роман (??), 09:07, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вопрос в том, как реализовать дамп без блокировок.

    Тарантул делает дамп без блокировок и без форка.

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

    Не единственный, можно mvcc в памяти сделать.

    > Redis - тупо форкнуться. Однако здесь возникает проблема. Memcached преимущественно используется
    > в очень высоконагруженных системах с огромным размером кэша - часто это
    > выделенный сервер, в котором почти вся оперативка отведена под memcached. Пока
    > все эти десятки гигабайтов запишутся на диск, произойдет куча запросов к
    > мемкешу, в том числе и на запись, сработает линуксовый copy-on-write, и
    > в результате задолго до того, как мы успеем все скинуть на
    > диск, оперативка закончится и OOM killer кого-нибудь тупо прибьет.

     
     
  • 4.46, Аноним (-), 04:04, 24/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, сравнили. Тарантул - это хоть и специфичная, но вполне полноценная субд-версионник. А в мемкеше главная ценность именно в том, что он настолько прост, что все операции имеют сложность О(1).

    Тарантул и мемкеш не конкуренты, у них разное назначение.

     

  • 1.9, Аноним (-), 00:38, 22/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    вот и началась стираться граница между озу и диском.
    интересно, когда на компах ползунком в гуи или параметром в конфиге можно будет задавать - сколько отвести под память, а сколько под перманент сторадж?
     
     
  • 2.11, VINRARUS (ok), 00:47, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вообще то это началось с добавлением кэша диска в неиспользуюмую оперативку под управлением Linux.
     
  • 2.13, Аноним (-), 00:49, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Надеюсь никогда, ибо ненужно. Для для машины с быстрой энергонезависимой памятью можно будет отказаться от этих двух абстракций и существенно упростить архитектуру ОС. Концепты уже давно существуют.
     
     
  • 3.40, Аноним (-), 11:07, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    См. #38.
     
  • 2.15, Avator (ok), 01:11, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ИМХО я думаю что придёт просто к тому что диск по скорости догонит или почти догонит ОЗУ и просто понятие ОЗУ постепенно отомрёт на обычных ПК.
    Останется только на серверах для использования штук типа Memcached.
    Это как замена ДВС на электромотор. Всё станет проще и это круто.
     
     
  • 3.16, VINRARUS (ok), 02:26, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё будет ещо проще - появится энергонезависимая ОЗУ. :)
    И вот после этого надобность в дисках хранения отпадет, по крайней мере на многих серверах (ну кроме бекапов).
     
     
  • 4.19, KonstantinB (ok), 02:40, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если появится энергонезависимая ОЗУ по цене накопителей, то надобность отпадет очень во многом. Например, в файловой системе. :-) Сериализация-десерализация останется, конечно - для обмена данными между различными приложениями по сети или через IPC - но писать файлы уже не надо - зачем, если можно просто держать в памяти все в естественном виде внутренних структур?
     
     
  • 5.22, letsmac (ok), 03:18, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > можно просто держать в памяти все в естественном виде внутренних структур?

    Ага а резервные копии идиоты придумали. Интересно как в таком идеальном хранилище будет обрабатываться разименование указателя?

     
  • 5.27, ыы (?), 08:56, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/

    > Сериализация-десерализация останется, конечно - для обмена данными между различными приложениями по сети или через IPC

    а через IPC нельзя передать просто бинарные данные?


     
  • 4.21, letsmac (ok), 03:17, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Всё будет ещо проще - появится энергонезависимая ОЗУ. :)
    > И вот после этого надобность в дисках хранения отпадет, по крайней мере
    > на многих серверах (ну кроме бекапов).

    В 80-х Smalltalk таки работал в полностью сохраняющей состояние машине. Но тогда и программисты не на  PHP/javascript писали.  

     
     
  • 5.28, ыы (?), 09:00, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Иными словами - технология доказала свою неэффективность еще  20+ лет назад
     
     
  • 6.29, ыы (?), 09:06, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А вот например Ерланг, тоже кстати не молодой, построенный на прямо противоположной идее - что состояние машины сохранять ненадо а надо ее почаще перезапускать - жив.
     
  • 6.45, Аноним (-), 18:10, 23/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не успела доказать — упёрлась в технические ограничения в виде слишком медленных ПЗУ.
     
  • 3.39, Аноним (-), 11:07, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    См. #38
     
  • 3.41, Аноним (-), 11:09, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Физику в школу учить, диск физически не может, т.к. скорость света в нашу вселенную слишком маленькую завезли...
    Как думаете почему планки памяти вокруг проца ставят ? :)
     
  • 2.38, Аноним (-), 11:05, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Гуглите "память на мемристорах" и HP The Machine.
     

  • 1.31, Роман (??), 09:09, 22/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    .


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

    Не понятно зачем нужна данная фича, если тот же Тарантул уже лет восемь как умеет хранить данные в памяти, но при этом они персистетны на диске. Таким образом, решается проблема старта с холодном кешом. К тому же, тарантул - это СУБД и имеет таблицы, транзакции, репликацию и прочее, тогда как мешкеш тупо 'кеш."

     
     
  • 2.32, ыы (?), 09:18, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не понятно зачем нужен Тарантул , ведь есть Oracle который покруче Тарантула, и тоже умеет хранить данные в памяти.


     
  • 2.33, ыы (?), 09:23, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Таким образом, решается проблема старта с холодном кешом.

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

     
  • 2.42, Аноним (-), 14:36, 22/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вашими же словами:
    > мешкеш тупо 'кеш."
    > Не понятно зачем нужна данная фича

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

     

  • 1.35, Inv (?), 09:55, 22/12/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждем интеграции с systemd
     
     
  • 2.47, anonymous (??), 13:11, 28/12/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ждем смерти systemd
     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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