The OpenNET Project / Index page

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

Релиз Memcached 1.5.18 с поддержкой сохранения кэша между перезапусками

18.09.2019 22:11

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

В новой версии добавлена поддержка сохранения состояния кэша между перезапусками. Memcached теперь может перед завершением работы сбрасывать дамп с кэшем в файл (требуется, чтобы файл находился на RAM-диске) и при следующем запуске загружать его, исключая пики нагрузки на обработчики контента из-за незаполненности кэша (кэш сразу становится "тёплым"). В новом выпуске также появилась возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM) через их монтирование с использованием DAX (прямой доступ к ФС в обход страничного кэша без применения уровня блочных устройств).

  1. Главная ссылка к новости (https://github.com/memcached/m...)
  2. OpenNews: Релиз Memcached 1.5.15 с поддержкой аутентификации для протокола ASCII
  3. OpenNews: Релиз Memcached 1.5.13 с поддержкой TLS
  4. OpenNews: Выпуск СУБД Redis 5.0
  5. OpenNews: Релиз Memcached 1.5.4 с поддержкой кэша на SSD-накопителях
  6. OpenNews: Зафиксировано использование Memcached в качестве усилителя трафика для DDoS-атак
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51514-memcached
Ключевые слова: memcached
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:35, 18/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Дропнул мемкеш, перешел на редис.
     
     
  • 2.8, Аноним (8), 05:56, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для каких задач лучше каждое решение из этих?
     
     
  • 3.13, пох. (?), 11:31, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    если ты не пейсбук - для любых твоих задач лучше уже редис. мемкэш изуродован пейсбуковцами до полной неузнаваемости, все полимеры (которых в общем и так было ограниченное количество) успешно продолбаны.

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

     
     
  • 4.24, Аноним (24), 12:45, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Каждый раз читая твои посты, я удивляюсь тому, насколько наша страна богата талантами, которые нахрен никому не нужны.
     
     
  • 5.26, Аноним (26), 22:49, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так и есть. И причина: зачем что-то надолго.
     
  • 5.27, Аноним (27), 10:21, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > наша страна

    Страна Анонима обычно размыта до размеров всей Вселенной (и даже больше ;) Так что да, Пох находится в вашей стране уважаемый Аноним ;)

     
     
  • 6.28, Аноним (26), 10:45, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ОФФ:

    Анек.

    В Израиль ты приехал, ты - русский.
    В Россию - еврей.


    Лопата. )))

    Страна бывает виртуальная, в сознании. Из неё не уехать. Если только долго, долго "идти пешком" тайгой без троп.

     
  • 3.16, RNZ (ok), 12:51, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.
    Если читать/писать хватит производительности одного ядра одного цпу, то redis может казаться более удобным в использовании. Ну а всякие плюшки типа pub/sub в redis - это на любителя (redis всё равно это делает через опу). Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.
     
     
  • 4.17, Anonimus (??), 13:14, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.

    У них сравнимая производительность, если отключить сбрасывание данных на диск, которое memcached не умеет из коробки. Также у редиса есть и много других фич из коробки которых нету memcached

    > Если читать/писать хватит производительности одного ядра одного цпу

    У вас устарела информация, начиная еще с 4 версии - редис умеет в потоки и утилизировать больше 1 ядра

    > Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.

    Судя по всему вы очень давно щупали редис - думаю версии до 3. Уже давно все детские болезни починили и много разных фич завезли. Сейчас можно использовать редис практически во всех сценариях, просто правильно конфигурируя под тот который нужен вам. в частности полноценная масштабируемость (шардинг + репликация) уже из коробки.
    Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого софта которые умеет только в мемкеш. Спомощью крутилок всегда можно сделать то что вам нужно практически из коробки, но да крутилок намного больше чем в мемкеше;)

     
     
  • 5.18, пох. (?), 17:11, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > в частности полноценная масштабируемость (шардинг + репликация) уже из коробки.

    но лучше ту коробку не открывать без респиратора.

    > Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого

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


     
  • 5.19, RNZ (ok), 21:01, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Плюшек в redis понапихали, но нет, не умеет он в треды, ну так-то они в нём есть изначально, по одному - io к диску, io по сети, лог и main. Но из 64 ядер на 2х cpu он будет утилизировать только одно ядро, ну и когда бросает данные на накопитель ещё одно - и всЁ. И кластер у него не пойми как работает.
    Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для кеширования в мелких веб-проектиках, но увы, народ легко на хайп ведётся и пихает всюду это недоразумение.

    [не]судите дальше.

     
     
  • 6.21, пох. (?), 10:45, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > И кластер у него не пойми как работает.

    воооот у мемкыша-то кластер - пооонятно как работает.

    нет ножек, нет проблемы, да?

    С тредами - это "design decision"(c). Поскольку кластерные конфигурации, когда его писали, упирались (внезапно!) в сеть, а не в способность одного ядра эту сеть наполнять.

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

    впрочем, полагаю, время отклика пейсбуку как раз совершенно неинтересно, учитывая модный-современный openssl(!) навернутый ими в качестве "защщщыты".

    > Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для
    > кеширования в мелких веб-проектиках

    вот мемкэш-то мооожно, дооо, дооо.

     
     
  • 7.25, RNZ (ok), 15:22, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Узлы в кластере не обязаны быть связаны, не обязаны заниматься распределением и ребалансировкой, но могут (делать это вменяемо, см. scylladb).
    И интеловцы могут-что угодно обнаружить, там где беда не с софтом, а с их процессорами.
    И до лампочки что там у facebook, но что-бы пресечь всякое вспениваение и лапшу про throughput и latency:

    redis - https://paste.ubuntu.com/p/G673Yby32b/
    [OVERALL], RunTime(ms), 452433
    [OVERALL], Throughput(ops/sec), 22102.72018177277
    [INSERT], Operations, 10000000
    [INSERT], AverageLatency(us), 1354.2462232
    [INSERT], MinLatency(us), 99
    [INSERT], MaxLatency(us), 64063
    [INSERT], 95thPercentileLatency(us), 1656
    [INSERT], 99thPercentileLatency(us), 1774
    [INSERT], Return=OK, 10000000

    memcached - https://paste.ubuntu.com/p/fqX5m5vNJD/
    [OVERALL], RunTime(ms), 50390
    [OVERALL], Throughput(ops/sec), 198452.07382417147
    [INSERT], Operations, 10000000
    [INSERT], AverageLatency(us), 133.8726188
    [INSERT], MinLatency(us), 44
    [INSERT], MaxLatency(us), 172287
    [INSERT], 95thPercentileLatency(us), 227
    [INSERT], 99thPercentileLatency(us), 467
    [INSERT], Return=OK, 10000000

     
     
  • 8.29, пох. (?), 17:12, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    тогда это не кластер, а просто набор несвязанных сервисов А вопросы задержек, ... текст свёрнут, показать
     
     
  • 9.30, RNZ (ok), 18:03, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Связанность может быть обеспечена на application уровне Тест самый приближенны... текст свёрнут, показать
     
     
  • 10.31, пох. (?), 22:29, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не доказано tl dr обычные условия лично у меня явно ничего общего с этой хрень... текст свёрнут, показать
     
     
  • 11.32, RNZ (ok), 13:45, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Твои проблемы Тоже твои проблемы 1024 по default, без всяких намёков А не надо з... текст свёрнут, показать
     
     
  • 12.33, пох. (?), 17:41, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    твои - ты же пыжился тут кому-то что-то втереть узнаю, узнаю дЭффехтивных менед... большой текст свёрнут, показать
     
     
  • 13.34, RNZ (ok), 21:11, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не пыжился я, это ты начал пузырить https www opennet ru openforum vsluhforum... большой текст свёрнут, показать
     
  • 13.35, RNZ (ok), 21:15, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    --дубликат--... текст свёрнут, показать
     
  • 5.23, пох. (?), 10:54, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > У них сравнимая производительность, если отключить сбрасывание данных на диск

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

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

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

     
  • 2.37, qweo (?), 15:57, 28/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ... на несвободный? ССЗБ
     

  • 1.2, Медведшатун (?), 22:35, 18/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >требуется, чтобы файл находился на RAM-диске

    Откуда такие требования?

     
     
  • 2.3, аааааа (?), 00:18, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Иначе вестимо будет тормазить. А про двойной расход памяти недумают.
     
     
  • 3.5, rshadow (ok), 01:21, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще конечно это решение не для ребута тачки. А только рестарта самого мемкеша.
    Какие проблемы это решает? Апгрейд? Борьба с утечками памяти или благами в коде?
     
     
  • 4.14, пох. (?), 11:32, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    какие-то пейсбукопроблемы. Для прочих смертных он уже просто ненужно.

     
  • 3.10, Andrey Mitrofanov_N0 (??), 09:00, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >А про двойной расход памяти недумают.

    mmap() с tmpfs-а  --  нет "двойного расхода".  //на ядре kernel.org

     
  • 2.4, KonstantinB (ok), 00:55, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    This feature works by putting memory related to item data into an external mmap file (specified via -e). All other memory; the hash table, connection memory, etc, stay in normal RAM. When the daemon is restarted, it runs a pass over the item data and fixes up all the internal pointers. It also regenerates the hash table.
     
     
  • 3.9, Аноним (9), 08:34, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То есть можно и на диск для persistence вместо lmdb.
     
     
  • 4.36, Аноним (36), 21:59, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мемкеш, похоже, чекает, что находится на RAM-сторадже. Наверное, можно и к диску присобачить через эмуляцию NVDIMM-памяти, но, скорее всего, толку будет мало.
     

  • 1.11, Ilya Indigo (ok), 10:38, 19/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Если бы он ещё научится расходовать память не всю сразу, которую ему предоставили, а только столько, сколько ему нужно в данный момент.
     
     
  • 2.12, Аноним (12), 11:22, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И тратить время на довыделение?
     
     
  • 3.15, Ilya Indigo (ok), 11:34, 19/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И тратить время на довыделение?

    1 Судя по сравнению с редиской не сильно она и тратит.
    2 А вот как на сабже понять, выделенного Гига хватает или нет?
    Сколько из него реально используется?
    И когда подходит к порогу (например более 90% занято)?

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

    А как оптимизировать потребление памяти, изменяя время жизни некоторых данных и мониторить как это отражается на потреблении памяти?

     
     
  • 4.20, Аноним (20), 05:36, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    O(1) всегда, без исключений и всяких amortized - это главный и незыблемый принцип мемкеша, его основная фича, этим обусловлено все остальное. Если на это пофиг и хочется фич - всегда есть redis.
     
  • 4.22, пох. (?), 10:47, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот как на сабже понять, выделенного Гига хватает или нет?

    использовать любой из миллиона перделко-поделочных серверов статистики - или накорябать на коленке свой, используя запрос 'stats'.

     

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



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

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