Состоялся релиз системы кеширования данных в оперативной памяти Memcached 1.5.18, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51514
Дропнул мемкеш, перешел на редис.
Для каких задач лучше каждое решение из этих?
если ты не пейсбук - для любых твоих задач лучше уже редис. мемкэш изуродован пейсбуковцами до полной неузнаваемости, все полимеры (которых в общем и так было ограниченное количество) успешно продолбаны.Если ты админ локалхоста, разьве что...хотя и в этом случае редис -просто работает из коробки в любом вменяемом дистрибутиве, а на мелочи на локалхосте наплевать.
Каждый раз читая твои посты, я удивляюсь тому, насколько наша страна богата талантами, которые нахрен никому не нужны.
Так и есть. И причина: зачем что-то надолго.
> наша странаСтрана Анонима обычно размыта до размеров всей Вселенной (и даже больше ;) Так что да, Пох находится в вашей стране уважаемый Аноним ;)
ОФФ:Анек.
В Израиль ты приехал, ты - русский.
В Россию - еврей.
Лопата. )))Страна бывает виртуальная, в сознании. Из неё не уехать. Если только долго, долго "идти пешком" тайгой без троп.
Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.
Если читать/писать хватит производительности одного ядра одного цпу, то redis может казаться более удобным в использовании. Ну а всякие плюшки типа pub/sub в redis - это на любителя (redis всё равно это делает через опу). Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.
> Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.У них сравнимая производительность, если отключить сбрасывание данных на диск, которое memcached не умеет из коробки. Также у редиса есть и много других фич из коробки которых нету memcached
> Если читать/писать хватит производительности одного ядра одного цпу
У вас устарела информация, начиная еще с 4 версии - редис умеет в потоки и утилизировать больше 1 ядра
> Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.
Судя по всему вы очень давно щупали редис - думаю версии до 3. Уже давно все детские болезни починили и много разных фич завезли. Сейчас можно использовать редис практически во всех сценариях, просто правильно конфигурируя под тот который нужен вам. в частности полноценная масштабируемость (шардинг + репликация) уже из коробки.
Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого софта которые умеет только в мемкеш. Спомощью крутилок всегда можно сделать то что вам нужно практически из коробки, но да крутилок намного больше чем в мемкеше;)
> в частности полноценная масштабируемость (шардинг + репликация) уже из коробки.но лучше ту коробку не открывать без респиратора.
> Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого
но тут присоединяюсь - мемкэш доломали, если не собираешься его самостоятельно дописывать (причем вернувшись куда-нибудь во времена 1.3) - лучше просто использовать redis.
Плюшек в redis понапихали, но нет, не умеет он в треды, ну так-то они в нём есть изначально, по одному - io к диску, io по сети, лог и main. Но из 64 ядер на 2х cpu он будет утилизировать только одно ядро, ну и когда бросает данные на накопитель ещё одно - и всЁ. И кластер у него не пойми как работает.
Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для кеширования в мелких веб-проектиках, но увы, народ легко на хайп ведётся и пихает всюду это недоразумение.[не]судите дальше.
> И кластер у него не пойми как работает.воооот у мемкыша-то кластер - пооонятно как работает.
нет ножек, нет проблемы, да?
С тредами - это "design decision"(c). Поскольку кластерные конфигурации, когда его писали, упирались (внезапно!) в сеть, а не в способность одного ядра эту сеть наполнять.
зато нет интерлоков и неизбежных потерь на них (во времена мемкэша 1.3 интеловцы обнаружили, что после четвертого ядра производительность падает, а не растет)
впрочем, полагаю, время отклика пейсбуку как раз совершенно неинтересно, учитывая модный-современный openssl(!) навернутый ими в качестве "защщщыты".
> Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для
> кеширования в мелких веб-проектикахвот мемкэш-то мооожно, дооо, дооо.
Узлы в кластере не обязаны быть связаны, не обязаны заниматься распределением и ребалансировкой, но могут (делать это вменяемо, см. 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, 10000000memcached - 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
> Узлы в кластере не обязаны быть связанытогда это не кластер, а просто набор несвязанных сервисов.
А вопросы задержек, синхронизации и фэйловера надо задавать уже тому, кто за них это делает.> И до лампочки что там у facebook
ну так и что там у тебя - до лампочки, потому что непонятно ни как это настроено, ни как используется. Какой-то синтетический тест? А какое он имеет отношение к (моим, к примеру) реальным применениям?
вообще - результаты странные. Если бы меня интересовали результаты такого теста - надо было бы лезть разбираться, что не так в тесте или в мемкэше.
Связанность может быть обеспечена на application уровне.Тест самый приближенный к обычным условиям:
* ubuntu 18.04, актуальные для этой версии ubuntu пакеты redis и memcached установленные через apt
* YCSB https://github.com/brianfrankcooper/YCSB/releases/download/0...
Конфиги приведены:
для redis - выключен save (не нужно, но пусть)
для memcached - 20 тредов, 30GiB и -MПроцессоры AMD EPYC 7501, память 2666 ECC
lxc (nproc 110, 200G) контейнер для redis и memcached
lxc (nproc 64, 100G) контейнер для ycsbИтог: redis в 9 раз медленнее throughput, в 10 раз медленнее latency и в 1,4 раза прожорливее, чем memcached.
------------------------------------------------------------------------------------------------------------------------------------------Любой может повторить в три притопа, три прихлопа.
Ты можешь конечно начать лечить, что в redis можно применять pipeline, но только обычно это не применимо для типичных кейсов кеширования и всё равно он будет медленнее memcached.
Так что прекращай пузырить.
> Связанность может быть обеспечена на application уровне.
> Тест самый приближенный к обычным условиям:не доказано
> * YCSB https://github.com/brianfrankcooper/YCSB/releases/download/0...tl;dr
"обычные условия" лично у меня явно ничего общего с этой хренью не имеют. А что она там имитирует - сорри, лень качать и разбираться.
> Конфиги приведены:
> для redis - выключен save (не нужно, но пусть)
> для memcached - 20 тредов, 30GiB и -M-c отсутствует, что как бы намекает нам?
> Итог: redis в 9 раз медленнее throughput, в 10 раз медленнее latency
> и в 1,4 раза прожорливее, чем memcached.если забыть о том что он сожрал ровно одно ядро, а мемкэш - 20.
ну ооок... "всего" чуть больше 50% пара - в свисток.
> Любой может повторить в три притопа, три прихлопа.
да, но зачем?
вот поинтересоваться, чем он там таким занимался в худшем случае 0.17c - было бы может и интересно, в плане "а вот вы так никогда не делайте" (потому что это куда важнее средней latency, измеряемой микросекундами). Но можно ограничиться предположением, что а мы и не делаем. А вам, как я вижу, неинтересно (хотя во всем тесте это единственное, что стоило бы поизучать).
Ну и возвращаясь к вопросу о кластерах - а теперь померяйте таки - то что у вас изображает кластер. Надеюсь, с блокировками, ha, ну хрен с ним, можно без sharding.
Потом будете рассказывать - имеют хоть какое-то значение эти ваши миллисекундные пиписькомерки, или ни малейшего.
>не доказаноТвои проблемы
>"обычные условия" лично у меня явно ничего общего с этой хренью не имеют.
Тоже твои проблемы
>-c отсутствует, что как бы намекает нам?
1024 по default, без всяких намёков
>если забыть о том что он сожрал ровно одно ядро, а мемкэш - 20.
А не надо забывать, redis больше 1-ого и не может.
> ну ооок... "всего" чуть больше 50% пара - в свисток.
Не доверяй ты своему потолочному калькулятору, он у тебя врёт.
memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:
[OVERALL], RunTime(ms), 174148
[OVERALL], Throughput(ops/sec), 57422.42230746262
[INSERT], Operations, 10000000
[INSERT], AverageLatency(us), 511.1519592
[INSERT], MinLatency(us), 54
[INSERT], MaxLatency(us), 181503
[INSERT], 95thPercentileLatency(us), 883
[INSERT], 99thPercentileLatency(us), 1153
[INSERT], Return=OK, 10000000> да, но зачем?
Затем, что-бы изначально выбрать масштабируемое решение, а не плодить костыли тупо запилив код для redis и плача о затраченных человеко часах и тоннах написанного кода, когда redis упрётся в полочку.
>вот поинтересоваться, чем он там таким занимался в худшем случае 0.17c
Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа выполняется в ОС с вытесняющей многозадачностью. Интересно только общее время, throughput, средний latency и перцентиль 95,99.
>Ну и возвращаясь к вопросу о кластерах - а теперь померяйте таки - то что у вас изображает кластер.
Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды.
Уясни наконец, что redis масштабируется через костыли. И там где справится один memcached, не нужно разводить 10-20 редисов. А если обычного memcached недостаточно, есть memcached на стеройдах - на seastar с dpdk.
> Твои проблемытвои - ты же пыжился тут кому-то что-то втереть.
> Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды.
узнаю, узнаю дЭффехтивных менеджеров. Они вообще не складываются.
> Не доверяй ты своему потолочному калькулятору, он у тебя врёт.
он у меня не врет - а ты не умеешь даже собственные данные оценивать. (впрочем, пейсбуковцы плакались о той же проблеме)
> memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи. Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня.
> Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа
> выполняется в ОС с вытесняющей многозадачностью.это, в отличие от твоего надувательства щек про "складывание в секунды" - явный показатель что что-то пошло очень криво, и вместо предсказуемого результата за фиксированное время, не смотря на привязку к конкретным ядрам и локнутую память - хваленый мемкэш о чем-то задумался на время, на четыре порядка(!) большее чем обычно. И когда под реальной, а не высосанной из пальца нагрузкой, ВНЕЗАПНО он начнет так задумываться на каждый второй запрос - а, ну да, дЭффехтивный уже в другом месте руководит процессами.
> Уясни наконец, что redis масштабируется через костыли.
спасибо, что бы я без тебя делал.
твои же измеризмы показали ясно - эффективность "масштабирования" непатченного мемкэша в пределах одного-единственного процессора - менее 50%. Думаю, хуже и ненадежнее сделать с редисом- надо будет постараться.
А когда ты начнешь те же костыли костылить в приложении (потому что, кто бы мог подумать, уперлись в network latency и все измеризмы с микросекундами пошли лесом, а еще, внезапно, понадобился фэйловер) - они от этого костылями быть перестанут, превратившись в изящнейшие подпорочки.> И там где справится один memcached, не нужно разводить 10-20 редисов.
ага, согласно твоим же измеризмам, хватит 5-6. При условии, конечно, что не справится и один - а на микросекундные персентили пользователям вообще-то наплевать.
При этом они сожрут таки 6 ядер, а не 20, и дадут более предсказуемый результат.
> есть memcached на стеройдах - на seastar с dpdk.
это решение опять каких-то пейсбукопроблем, а не моих. Кстати, намекающее, что кто-то в сетевую -то уперся. Ну и хрен с ними - это, повторяю, не мои проблемы, у меня совсем другая область применения мемкэшей - и там у них никаких явных преимуществ нет (были в простоте и предсказуемости поведения, но доломаны). А пейсбук у нас, к счастью, один.
Не пыжился я, это ты начал пузырить (https://www.opennet.me/openforum/vsluhforumID3/118500.html#21) о том, о чём как выясняется представление имеешь поверхностное.> а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи.
Вот ты думаешь, что ты один это понимаешь? Так вот слезь со стула и перестань страдать капитанством.
> Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня.
Ты свои догадки за "наглядно демонстрируют" не выдавай. Твой калькулятор врёт, ещё и потому, что ты делаешь выводы там, где ты их делать не можешь - нет у тебя всей полноты информации о тесте.
> явный показатель что что-то пошло очень криво, и вместо предсказуемого результата за фиксированное время, не смотря на привязку к конкретным ядрам и локнутую память - хваленый мемкэш о чем-то задумался на время, на четыре порядка(!) большее чем обычно. И когда под реальной, а не высосанной из пальца нагрузкой, ВНЕЗАПНО он начнет так задумываться на каждый второй запрос - а, ну да, дЭффехтивный уже в другом месте руководит процессами.
Это твои нелепые догадки не более. То что при интенсивной конкуренции latency деградирует и без твоего капитанства известно, и это не только к memcached относится, но и к redis и к любому другому сетевому сервису, будь в нём один или много тредов, и естественно блокировки оказывают влияние и естественно у любой программы есть потолок насыщения. Но мы тут обсуждаем не это, а то почему redis - не может, а memcached - может.
>твои же измеризмы показали ясно - эффективность "масштабирования" непатченного мемкэша в пределах одного-единственного процессора - менее 50%. Думаю, хуже и ненадежнее сделать с редисом- надо будет постараться.
Всё так-же твой калькулятор тебя агрессивно наё...обманывает. Но ты не сдавайся, однажды ты заставишь его правильно считать.
>А когда ты начнешь те же костыли костылить в приложении (потому что, кто бы мог подумать, уперлись в network latency и все измеризмы с микросекундами пошли лесом, а еще, внезапно, понадобился фэйловер) - они от этого костылями быть перестанут, превратившись в изящнейшие подпорочки.
Ты и про network latency ничего не знаешь, так что не напрягайся.
>ага, согласно твоим же измеризмам, хватит 5-6. При условии, конечно, что не справится и один - а на микросекундные персентили пользователям вообще-то наплевать. При этом они сожрут таки 6 ядер, а не 20, и дадут более предсказуемый результат.
Не обманывай себя, даже с 10 redis'ами, ты будешь страдать и предсказуемости ты не увидишь (разве-что если заведёшь sparc m8 о 5GHz на каждое ядро под solaris с конкретной привязкой каждого redis'а на ядро).
>это решение опять каких-то пейсбукопроблем, а не моих. Кстати, намекающее, что кто-то в сетевую -то уперся. Ну и хрен с ними - это, повторяю, не мои проблемы, у меня совсем другая область применения мемкэшей - и там у них никаких явных преимуществ нет (были в простоте и предсказуемости поведения, но доломаны). А пейсбук у нас, к счастью, один.
Так и не лезь ты со своими микро. А для тех кто знает, что такое LLC и почему redis должен быть сложен в /dev/null, применение memcached оправданно, и применение seastar-memcached оправдано, когда требуется выжать ещё больше за те же деньги.
Ну и вникай в результаты теста родного для redislab - memtier_benchmark:
redis - https://paste.ubuntu.com/p/3DV8HfjpRg/
AGGREGATED AVERAGE RESULTS (10 runs)
=========================================================================
Type Ops/sec Hits/sec Misses/sec Latency KB/sec
-------------------------------------------------------------------------
Sets 21812.85 --- --- 14.02310 3111.31
Gets 43495.08 32279.00 11216.07 13.85290 4843.18
Waits 0.00 --- --- 0.00000 ---
Totals 65307.92 32279.00 11216.07 13.90960 7954.49
real 2m41.305smemcached - https://paste.ubuntu.com/p/Pwqf8sdBVN/
AGGREGATED AVERAGE RESULTS (10 runs)
=========================================================================
Type Ops/sec Hits/sec Misses/sec Latency KB/sec
-------------------------------------------------------------------------
Sets 800396.40 --- --- 1.07490 107131.09
Gets 1596000.02 1596000.02 0.00 1.06220 234135.42
Waits 0.00 --- --- 0.00000 ---
Totals 2396396.42 1596000.02 0.00 1.06670 341266.51
real 0m36.168s
--дубликат--
> У них сравнимая производительность, если отключить сбрасывание данных на дисконо у редиса было организовано примерно из того же дерьма и палок, что и все остальное - поэтому на производительность влияет примерно никак, основной демон делает fork, и немедленно забывает про все эти дисковые проблемы, задачей записи занимается потомок, никак не мешая обрабатывать текущие запросы. Сомневаюсь что в четвертой и fsfопротивной пятой что-то поменялось.
Степень консистентности этих данных (как и консистентности слейвов в кластере, обслуживаемых примерно по тому же принципу) оставляется для самостоятельного изучения ;-)
безумству храбрых, использующих ЭТО не для распределенной замены мемкэшу, а для долговременного хранения чего-то важного, что нельзя просто заново прочитать из нормальной, персистентной базы - поем мы песню.
... на несвободный? ССЗБ
>требуется, чтобы файл находился на RAM-дискеОткуда такие требования?
Иначе вестимо будет тормазить. А про двойной расход памяти недумают.
Вообще конечно это решение не для ребута тачки. А только рестарта самого мемкеша.
Какие проблемы это решает? Апгрейд? Борьба с утечками памяти или благами в коде?
какие-то пейсбукопроблемы. Для прочих смертных он уже просто ненужно.
>А про двойной расход памяти недумают.mmap() с tmpfs-а -- нет "двойного расхода". //на ядре kernel.org
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.
То есть можно и на диск для persistence вместо lmdb.
Мемкеш, похоже, чекает, что находится на RAM-сторадже. Наверное, можно и к диску присобачить через эмуляцию NVDIMM-памяти, но, скорее всего, толку будет мало.
Если бы он ещё научится расходовать память не всю сразу, которую ему предоставили, а только столько, сколько ему нужно в данный момент.
И тратить время на довыделение?
> И тратить время на довыделение?1 Судя по сравнению с редиской не сильно она и тратит.
2 А вот как на сабже понять, выделенного Гига хватает или нет?
Сколько из него реально используется?
И когда подходит к порогу (например более 90% занято)?Я так понимаю, пока порог не привысится и не начнут затираться старые записи - то и не узнаешь, что нужно больше?
А как оптимизировать потребление памяти, изменяя время жизни некоторых данных и мониторить как это отражается на потреблении памяти?
O(1) всегда, без исключений и всяких amortized - это главный и незыблемый принцип мемкеша, его основная фича, этим обусловлено все остальное. Если на это пофиг и хочется фич - всегда есть redis.
> А вот как на сабже понять, выделенного Гига хватает или нет?использовать любой из миллиона перделко-поделочных серверов статистики - или накорябать на коленке свой, используя запрос 'stats'.