Подготовлен (https://github.com/memcached/memcached/releases/tag/1.5.4) релиз системы кеширования данных в оперативной памяти Memcached 1.5.4 (http://memcached.org/), оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется (https://github.com/memcached/memcached) под лицензией BSD.
Новая версия интересна добавлением прослойки (https://github.com/memcached/memcached/wiki/Extstore) для работы с внешними хранилищами, позволяющая использовать 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".
URL: https://github.com/memcached/memcached/releases/tag/1.5.4
Новость: http://www.opennet.me/opennews/art.shtml?num=47783
Оно живо. Ты смотри.
Иногда главное вовремя остановиться! Memcached отличный, полностью завершенный продукт, а фичеразвитие для него - это скорее плохо, чем хорошо!
Не пойму, а какая религия им помешала сделать персистентность? На тех же условиях, что и сейчас - без гарантий, если вам не повезло - то кэш умер, как всегда с мемкешом и было? По идее, для этого же вообще ничего не нужно?
Лишние несколько байт на сохранение ключа вместе с данными на постоянном носителе конечно не жалко, но для синхронизации состояния, какие ключи актуальны, а какие нет, пришлось бы заметно усложнить всю архитектуру. Сейчас вся логика в ОЗУ, а на Flash только голые данные без информации об их актуальности.
Но я бы всё же сделал, что-то типа CoW - кроме ключа сохранял бы время записи, а при запуске предусмотрел бы режим восстановления, оставляя самые свежие ключи при наличии дубликатов остающихся после перезаписи значений ключа.
зачем?
Чтобы кэш тёплым после перезапуска оставался.
> Чтобы кэш тёплым после перезапуска оставался.После перезапуска с какой целью и с каким временем простоя?
> После перезапуска с какой целью и с каким временем простоя?Например, могут динамически генерироваться картинки/видео/звук. При полном сбросе кэша будет огромный провал в производительности и повышенная нагрузка пока кэш не наполнится. По поводу простоя, если будет сохранено время создания, то при загрузке можно отсеивать по времени жизни элемента кэша. Redis для такой задачи не подходит, так как он весь кэш в памяти держит, а другие NoSQL или избыточны (БД, а не кэш) или по производительности не дотягивают.
если больше трех мемкэш серверов, то проседание производительности будет незначительным, вероятнее всего, вот и ответ кому и зачем такая архитектура нужна.
> если больше трех мемкэш серверов, то проседание производительности будет незначительным,
> вероятнее всего, вот и ответ кому и зачем такая архитектура нужна.я правильно понимаю что мемкешед можно держать на двух нодах с разным содержимым - рейд0, но перед рестартом ноды Б можно перевести обе ноды А и Б в рейд1 и содержимое станет одинаковое (выкинув то, что не влезло, но оставив самое актуальное) ?
выключить Б
перевести А в рейд0
включить Б и ввести в рейд0
так можно делать ?
Вопрос в том, как реализовать дамп без блокировок.В архитектуре мемкеша нет никаких блокировок, кроме глобальной (окей, когда в фейсбуке добавляли мульттредовость, еще сделали локи бакетов - но это непринципиально, бакеты все равно огромные).
В такой ситуации единственный способ сдампиться - поступить так же, как делает Redis - тупо форкнуться. Однако здесь возникает проблема. Memcached преимущественно используется в очень высоконагруженных системах с огромным размером кэша - часто это выделенный сервер, в котором почти вся оперативка отведена под memcached. Пока все эти десятки гигабайтов запишутся на диск, произойдет куча запросов к мемкешу, в том числе и на запись, сработает линуксовый copy-on-write, и в результате задолго до того, как мы успеем все скинуть на диск, оперативка закончится и OOM killer кого-нибудь тупо прибьет.
приличная хранилка имеет скорость 10-15 Gbyte/s сервак с 256G-512G - запишет свою память менее чем за минуту.
>10-15 Gbyte/s
>запишет свою памятьвы имеете в виду скорость записи на диск?
> Вопрос в том, как реализовать дамп без блокировок.Тарантул делает дамп без блокировок и без форка.
> В архитектуре мемкеша нет никаких блокировок, кроме глобальной (окей, когда в фейсбуке
> добавляли мульттредовость, еще сделали локи бакетов - но это непринципиально, бакеты
> все равно огромные).
> В такой ситуации единственный способ сдампиться - поступить так же, как делаетНе единственный, можно mvcc в памяти сделать.
> Redis - тупо форкнуться. Однако здесь возникает проблема. Memcached преимущественно используется
> в очень высоконагруженных системах с огромным размером кэша - часто это
> выделенный сервер, в котором почти вся оперативка отведена под memcached. Пока
> все эти десятки гигабайтов запишутся на диск, произойдет куча запросов к
> мемкешу, в том числе и на запись, сработает линуксовый copy-on-write, и
> в результате задолго до того, как мы успеем все скинуть на
> диск, оперативка закончится и OOM killer кого-нибудь тупо прибьет.
Ну, сравнили. Тарантул - это хоть и специфичная, но вполне полноценная субд-версионник. А в мемкеше главная ценность именно в том, что он настолько прост, что все операции имеют сложность О(1).Тарантул и мемкеш не конкуренты, у них разное назначение.
вот и началась стираться граница между озу и диском.
интересно, когда на компах ползунком в гуи или параметром в конфиге можно будет задавать - сколько отвести под память, а сколько под перманент сторадж?
Вообще то это началось с добавлением кэша диска в неиспользуюмую оперативку под управлением Linux.
Надеюсь никогда, ибо ненужно. Для для машины с быстрой энергонезависимой памятью можно будет отказаться от этих двух абстракций и существенно упростить архитектуру ОС. Концепты уже давно существуют.
См. #38.
ИМХО я думаю что придёт просто к тому что диск по скорости догонит или почти догонит ОЗУ и просто понятие ОЗУ постепенно отомрёт на обычных ПК.
Останется только на серверах для использования штук типа Memcached.
Это как замена ДВС на электромотор. Всё станет проще и это круто.
Всё будет ещо проще - появится энергонезависимая ОЗУ. :)
И вот после этого надобность в дисках хранения отпадет, по крайней мере на многих серверах (ну кроме бекапов).
Если появится энергонезависимая ОЗУ по цене накопителей, то надобность отпадет очень во многом. Например, в файловой системе. :-) Сериализация-десерализация останется, конечно - для обмена данными между различными приложениями по сети или через IPC - но писать файлы уже не надо - зачем, если можно просто держать в памяти все в естественном виде внутренних структур?
> можно просто держать в памяти все в естественном виде внутренних структур?Ага а резервные копии идиоты придумали. Интересно как в таком идеальном хранилище будет обрабатываться разименование указателя?
> Сериализация-десерализация останется, конечно - для обмена данными между различными приложениями по сети или через IPCа через IPC нельзя передать просто бинарные данные?
> Всё будет ещо проще - появится энергонезависимая ОЗУ. :)
> И вот после этого надобность в дисках хранения отпадет, по крайней мере
> на многих серверах (ну кроме бекапов).В 80-х Smalltalk таки работал в полностью сохраняющей состояние машине. Но тогда и программисты не на PHP/javascript писали.
Иными словами - технология доказала свою неэффективность еще 20+ лет назад
А вот например Ерланг, тоже кстати не молодой, построенный на прямо противоположной идее - что состояние машины сохранять ненадо а надо ее почаще перезапускать - жив.
Не успела доказать — упёрлась в технические ограничения в виде слишком медленных ПЗУ.
См. #38
Физику в школу учить, диск физически не может, т.к. скорость света в нашу вселенную слишком маленькую завезли...
Как думаете почему планки памяти вокруг проца ставят ? :)
Гуглите "память на мемристорах" и HP The Machine.
.
> Суть нового метода заключается в том, что ключи и метаданные, как и
> раньше, хранится только в оперативной памяти. Если связанные с ключом данные
> небольшого размера, то Memcached работает как обычно, держит данные в памяти
> и не обращается к внешнему хранилищу. Но если данные больше определённого
> значения, они сохраняются во внешнее хранилище, а в ОЗУ остаётся только
> указатель. Если свободной памяти много, то наиболее востребованные данные дополнительно
> могут полностью находиться в кэше в оперативной памяти (например можно указать,
> чтобы на Flash сбрасывались только объекты больше 1024 байт, к которым
> не было обращений 3600 секунд").Не понятно зачем нужна данная фича, если тот же Тарантул уже лет восемь как умеет хранить данные в памяти, но при этом они персистетны на диске. Таким образом, решается проблема старта с холодном кешом. К тому же, тарантул - это СУБД и имеет таблицы, транзакции, репликацию и прочее, тогда как мешкеш тупо 'кеш."
Не понятно зачем нужен Тарантул , ведь есть Oracle который покруче Тарантула, и тоже умеет хранить данные в памяти.
> Таким образом, решается проблема старта с холодном кешом.Вы бы не могли более подробно рассказать об этой проблеме в контексте веб-приложения... Очень любопытно..
Что именно видит на экране юзер, пока вы.. эээ "стартуете с горячим кэшом"?
Вашими же словами:
> мешкеш тупо 'кеш."
> Не понятно зачем нужна данная фичаперечитайте новость. когда хранить хочется "чуточку больше", чем есть денег на оперативку.
Ждем интеграции с systemd
ждем смерти systemd