forum.opennet.ru - "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." (35)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
Сообщение от opennews (??), 18-Сен-19, 22:35
Состоялся релиз системы кеширования данных в оперативной памяти Memcached 1.5.18, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD... Подробнее: https://www.opennet.me/opennews/art.shtml?num=51514
Ответить \| Правка \| Cообщить модератору

Оглавление

Дропнул мемкеш, перешел на редис , Аноним (1), 22:35 , 18-Сен-19, (1) –4

Для каких задач лучше каждое решение из этих , Аноним (8), 05:56 , 19-Сен-19, (8) –1

если ты не пейсбук - для любых твоих задач лучше уже редис мемкэш изуродован пе, пох. (?), 11:31 , 19-Сен-19, (13) –2

Каждый раз читая твои посты, я удивляюсь тому, насколько наша страна богата тала, Аноним (24), 12:45 , 20-Сен-19, (24) +2

Так и есть И причина зачем что-то надолго , Аноним (26), 22:49 , 21-Сен-19, (26)
Страна Анонима обычно размыта до размеров всей Вселенной и даже больше Так ч, Аноним (27), 10:21 , 22-Сен-19, (27)

ОФФ Анек В Израиль ты приехал, ты - русский В Россию - еврей Лопата Страна б, Аноним (26), 10:45 , 22-Сен-19, (28)

Если много читать писать и требуется утилизировать железо по максимуму, то memca, RNZ (ok), 12:51 , 19-Сен-19, (16)

У них сравнимая производительность, если отключить сбрасывание данных на диск, к, Anonimus (??), 13:14 , 19-Сен-19, (17)

но лучше ту коробку не открывать без респиратора но тут присоединяюсь - мемкэш д, пох. (?), 17:11 , 19-Сен-19, (18)
Плюшек в redis понапихали, но нет, не умеет он в треды, ну так-то они в нём есть, RNZ (ok), 21:01 , 19-Сен-19, (19)

воооот у мемкыша-то кластер - пооонятно как работает нет ножек, нет проблемы, да, пох. (?), 10:45 , 20-Сен-19, (21)

Узлы в кластере не обязаны быть связаны, не обязаны заниматься распределением и , RNZ (ok), 15:22 , 21-Сен-19, (25) +2

тогда это не кластер, а просто набор несвязанных сервисов А вопросы задержек, с, пох. (?), 17:12 , 22-Сен-19, (29) –1

Связанность может быть обеспечена на application уровне Тест самый приближенный, RNZ (ok), 18:03 , 22-Сен-19, (30)

не доказаноtl dr обычные условия лично у меня явно ничего общего с этой хренью , пох. (?), 22:29 , 22-Сен-19, (31) –1

Твои проблемыТоже твои проблемы1024 по default, без всяких намёковА не надо забы, RNZ (ok), 13:45 , 23-Сен-19, (32)

твои - ты же пыжился тут кому-то что-то втереть узнаю, узнаю дЭффехтивных менедж, пох. (?), 17:41 , 23-Сен-19, (33)
Не пыжился я, это ты начал пузырить https www opennet ru openforum vsluhforum, RNZ (ok), 21:11 , 23-Сен-19, (34)
--дубликат--, RNZ (ok), 21:15 , 23-Сен-19, (35)

оно у редиса было организовано примерно из того же дерьма и палок, что и все ост, пох. (?), 10:54 , 20-Сен-19, (23) –1

на несвободный ССЗБ, qweo (?), 15:57 , 28-Сен-19, (37)

Откуда такие требования , Медведшатун (?), 22:35 , 18-Сен-19, (2)

Иначе вестимо будет тормазить А про двойной расход памяти недумают , аааааа (?), 00:18 , 19-Сен-19, (3)

Вообще конечно это решение не для ребута тачки А только рестарта самого мемкеша, rshadow (ok), 01:21 , 19-Сен-19, (5)

какие-то пейсбукопроблемы Для прочих смертных он уже просто ненужно , пох. (?), 11:32 , 19-Сен-19, (14)

mmap с tmpfs-а -- нет двойного расхода на ядре kernel org, Andrey Mitrofanov_N0 (??), 09:00 , 19-Сен-19, (10) +3

This feature works by putting memory related to item data into an external mmap , KonstantinB (ok), 00:55 , 19-Сен-19, (4)

То есть можно и на диск для persistence вместо lmdb , Аноним (9), 08:34 , 19-Сен-19, (9)

Мемкеш, похоже, чекает, что находится на RAM-сторадже Наверное, можно и к диску, Аноним (36), 21:59 , 23-Сен-19, (36)

Если бы он ещё научится расходовать память не всю сразу, которую ему предоставил, Ilya Indigo (ok), 10:38 , 19-Сен-19, (11) –2

И тратить время на довыделение , Аноним (12), 11:22 , 19-Сен-19, (12)

1 Судя по сравнению с редиской не сильно она и тратит 2 А вот как на сабже понят, Ilya Indigo (ok), 11:34 , 19-Сен-19, (15) +1

O 1 всегда, без исключений и всяких amortized - это главный и незыблемый принци, Аноним (20), 05:36 , 20-Сен-19, (20) +1
использовать любой из миллиона перделко-поделочных серверов статистики - или нак, пох. (?), 10:47 , 20-Сен-19, (22)

Сообщения [Сортировка по времени | RSS]

1. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –4 +/–

Сообщение от Аноним (1), 18-Сен-19, 22:35

Дропнул мемкеш, перешел на редис.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –1 +/–

Сообщение от Аноним (8), 19-Сен-19, 05:56

Для каких задач лучше каждое решение из этих?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

13. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –2 +/–

Сообщение от пох. (?), 19-Сен-19, 11:31

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

24. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +2 +/–

Сообщение от Аноним (24), 20-Сен-19, 12:45

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

26. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Аноним (26), 21-Сен-19, 22:49

Так и есть. И причина: зачем что-то надолго.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Аноним (27), 22-Сен-19, 10:21

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

28. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Аноним (26), 22-Сен-19, 10:45

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

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

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

16. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от RNZ (ok), 19-Сен-19, 12:51

Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.
Если читать/писать хватит производительности одного ядра одного цпу, то redis может казаться более удобным в использовании. Ну а всякие плюшки типа pub/sub в redis - это на любителя (redis всё равно это делает через опу). Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

17. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Anonimus (??), 19-Сен-19, 13:14

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от пох. (?), 19-Сен-19, 17:11

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от RNZ (ok), 19-Сен-19, 21:01

Плюшек в redis понапихали, но нет, не умеет он в треды, ну так-то они в нём есть изначально, по одному - io к диску, io по сети, лог и main. Но из 64 ядер на 2х cpu он будет утилизировать только одно ядро, ну и когда бросает данные на накопитель ещё одно - и всЁ. И кластер у него не пойми как работает.
Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для кеширования в мелких веб-проектиках, но увы, народ легко на хайп ведётся и пихает всюду это недоразумение.
[не]судите дальше.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от пох. (?), 20-Сен-19, 10:45

> И кластер у него не пойми как работает.
воооот у мемкыша-то кластер - пооонятно как работает.
нет ножек, нет проблемы, да?
С тредами - это "design decision"(c). Поскольку кластерные конфигурации, когда его писали, упирались (внезапно!) в сеть, а не в способность одного ядра эту сеть наполнять.
зато нет интерлоков и неизбежных потерь на них (во времена мемкэша 1.3 интеловцы обнаружили, что после четвертого ядра производительность падает, а не растет)
впрочем, полагаю, время отклика пейсбуку как раз совершенно неинтересно, учитывая модный-современный openssl(!) навернутый ими в качестве "защщщыты".
> Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для
> кеширования в мелких веб-проектиках
вот мемкэш-то мооожно, дооо, дооо.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

25. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +2 +/–

Сообщение от RNZ (ok), 21-Сен-19, 15:22

Узлы в кластере не обязаны быть связаны, не обязаны заниматься распределением и ребалансировкой, но могут (делать это вменяемо, см. 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

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

29. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –1 +/–

Сообщение от пох. (?), 22-Сен-19, 17:12

> Узлы в кластере не обязаны быть связаны
тогда это не кластер, а просто набор несвязанных сервисов.
А вопросы задержек, синхронизации и фэйловера надо задавать уже тому, кто за них это делает.
> И до лампочки что там у facebook
ну так и что там у тебя - до лампочки, потому что непонятно ни как это настроено, ни как используется. Какой-то синтетический тест? А какое он имеет отношение к (моим, к примеру) реальным применениям?
вообще - результаты странные. Если бы меня интересовали результаты такого теста - надо было бы лезть разбираться, что не так в тесте или в мемкэше.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

30. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от RNZ (ok), 22-Сен-19, 18:03

Связанность может быть обеспечена на 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.
Так что прекращай пузырить.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –1 +/–

Сообщение от пох. (?), 22-Сен-19, 22:29

> Связанность может быть обеспечена на 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.
Потом будете рассказывать - имеют хоть какое-то значение эти ваши миллисекундные пиписькомерки, или ни малейшего.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

32. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от RNZ (ok), 23-Сен-19, 13:45

>не доказано
Твои проблемы
>"обычные условия" лично у меня явно ничего общего с этой хренью не имеют.
Тоже твои проблемы
>-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.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от пох. (?), 23-Сен-19, 17:41

> Твои проблемы
твои - ты же пыжился тут кому-то что-то втереть.
> Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды.
узнаю, узнаю дЭффехтивных менеджеров. Они вообще не складываются.
> Не доверяй ты своему потолочному калькулятору, он у тебя врёт.
он у меня не врет - а ты не умеешь даже собственные данные оценивать. (впрочем, пейсбуковцы плакались о той же проблеме)
> memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency:
а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи. Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня.
> Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа
> выполняется в ОС с вытесняющей многозадачностью.
это, в отличие от твоего надувательства щек про "складывание в секунды" - явный показатель что что-то пошло очень криво, и вместо предсказуемого результата за фиксированное время, не смотря на привязку к конкретным ядрам и локнутую память - хваленый мемкэш о чем-то задумался на время, на четыре порядка(!) большее чем обычно. И когда под реальной, а не высосанной из пальца нагрузкой, ВНЕЗАПНО он начнет так задумываться на каждый второй запрос - а, ну да, дЭффехтивный уже в другом месте руководит процессами.
> Уясни наконец, что redis масштабируется через костыли.
спасибо, что бы я без тебя делал.
твои же измеризмы показали ясно - эффективность "масштабирования" непатченного мемкэша в пределах одного-единственного процессора - менее 50%. Думаю, хуже и ненадежнее сделать с редисом- надо будет постараться.
А когда ты начнешь те же костыли костылить в приложении (потому что, кто бы мог подумать, уперлись в network latency и все измеризмы с микросекундами пошли лесом, а еще, внезапно, понадобился фэйловер) - они от этого костылями быть перестанут, превратившись в изящнейшие подпорочки.
> И там где справится один memcached, не нужно разводить 10-20 редисов.
ага, согласно твоим же измеризмам, хватит 5-6. При условии, конечно, что не справится и один - а на микросекундные персентили пользователям вообще-то наплевать.
При этом они сожрут таки 6 ядер, а не 20, и дадут более предсказуемый результат.
> есть memcached на стеройдах - на seastar с dpdk.
это решение опять каких-то пейсбукопроблем, а не моих. Кстати, намекающее, что кто-то в сетевую -то уперся. Ну и хрен с ними - это, повторяю, не мои проблемы, у меня совсем другая область применения мемкэшей - и там у них никаких явных преимуществ нет (были в простоте и предсказуемости поведения, но доломаны). А пейсбук у нас, к счастью, один.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

34. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от RNZ (ok), 23-Сен-19, 21:11

Не пыжился я, это ты начал пузырить (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.305s
memcached - 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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

35. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от RNZ (ok), 23-Сен-19, 21:15

--дубликат--

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

23. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –1 +/–

Сообщение от пох. (?), 20-Сен-19, 10:54

> У них сравнимая производительность, если отключить сбрасывание данных на диск
оно у редиса было организовано примерно из того же дерьма и палок, что и все остальное - поэтому на производительность влияет примерно никак, основной демон делает fork, и немедленно забывает про все эти дисковые проблемы, задачей записи занимается потомок, никак не мешая обрабатывать текущие запросы. Сомневаюсь что в четвертой и fsfопротивной пятой что-то поменялось.
Степень консистентности этих данных (как и консистентности слейвов в кластере, обслуживаемых примерно по тому же принципу) оставляется для самостоятельного изучения ;-)
безумству храбрых, использующих ЭТО не для распределенной замены мемкэшу, а для долговременного хранения чего-то важного, что нельзя просто заново прочитать из нормальной, персистентной базы - поем мы песню.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

37. "'Редиска'" +/–

Сообщение от qweo (?), 28-Сен-19, 15:57

... на несвободный? ССЗБ

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Медведшатун (?), 18-Сен-19, 22:35

>требуется, чтобы файл находился на RAM-диске
Откуда такие требования?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от аааааа (?), 19-Сен-19, 00:18

Иначе вестимо будет тормазить. А про двойной расход памяти недумают.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от rshadow (ok), 19-Сен-19, 01:21

Вообще конечно это решение не для ребута тачки. А только рестарта самого мемкеша.
Какие проблемы это решает? Апгрейд? Борьба с утечками памяти или благами в коде?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

14. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от пох. (?), 19-Сен-19, 11:32

какие-то пейсбукопроблемы. Для прочих смертных он уже просто ненужно.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +3 +/–

Сообщение от Andrey Mitrofanov_N0 (??), 19-Сен-19, 09:00

>А про двойной расход памяти недумают.
mmap() с tmpfs-а  --  нет "двойного расхода".  //на ядре kernel.org

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от KonstantinB (ok), 19-Сен-19, 00:55

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.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Аноним (9), 19-Сен-19, 08:34

То есть можно и на диск для persistence вместо lmdb.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

36. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Аноним (36), 23-Сен-19, 21:59

Мемкеш, похоже, чекает, что находится на RAM-сторадже. Наверное, можно и к диску присобачить через эмуляцию NVDIMM-памяти, но, скорее всего, толку будет мало.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." –2 +/–

Сообщение от Ilya Indigo (ok), 19-Сен-19, 10:38

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от Аноним (12), 19-Сен-19, 11:22

И тратить время на довыделение?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +1 +/–

Сообщение от Ilya Indigo (ok), 19-Сен-19, 11:34

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

20. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +1 +/–

Сообщение от Аноним (20), 20-Сен-19, 05:36

O(1) всегда, без исключений и всяких amortized - это главный и незыблемый принцип мемкеша, его основная фича, этим обусловлено все остальное. Если на это пофиг и хочется фич - всегда есть redis.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

22. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..." +/–

Сообщение от пох. (?), 20-Сен-19, 10:47

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	–4 +/–
Сообщение от Аноним (1), 18-Сен-19, 22:35
Дропнул мемкеш, перешел на редис.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	8. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	–1 +/–
	Сообщение от Аноним (8), 19-Сен-19, 05:56
	Для каких задач лучше каждое решение из этих?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	13. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	–2 +/–
	Сообщение от пох. (?), 19-Сен-19, 11:31
	если ты не пейсбук - для любых твоих задач лучше уже редис. мемкэш изуродован пейсбуковцами до полной неузнаваемости, все полимеры (которых в общем и так было ограниченное количество) успешно продолбаны. Если ты админ локалхоста, разьве что...хотя и в этом случае редис -просто работает из коробки в любом вменяемом дистрибутиве, а на мелочи на локалхосте наплевать.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	24. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+2 +/–
	Сообщение от Аноним (24), 20-Сен-19, 12:45
	Каждый раз читая твои посты, я удивляюсь тому, насколько наша страна богата талантами, которые нахрен никому не нужны.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	26. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от Аноним (26), 21-Сен-19, 22:49
	Так и есть. И причина: зачем что-то надолго.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	27. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от Аноним (27), 22-Сен-19, 10:21
	> наша страна Страна Анонима обычно размыта до размеров всей Вселенной (и даже больше ;) Так что да, Пох находится в вашей стране уважаемый Аноним ;)
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	28. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от Аноним (26), 22-Сен-19, 10:45
	ОФФ: Анек. В Израиль ты приехал, ты - русский. В Россию - еврей. Лопата. ))) Страна бывает виртуальная, в сознании. Из неё не уехать. Если только долго, долго "идти пешком" тайгой без троп.
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	16. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от RNZ (ok), 19-Сен-19, 12:51
	Если много читать/писать и требуется утилизировать железо по максимуму, то memcached. Если читать/писать хватит производительности одного ядра одного цпу, то redis может казаться более удобным в использовании. Ну а всякие плюшки типа pub/sub в redis - это на любителя (redis всё равно это делает через опу). Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	17. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от Anonimus (??), 19-Сен-19, 13:14
	> Если много читать/писать и требуется утилизировать железо по максимуму, то memcached. У них сравнимая производительность, если отключить сбрасывание данных на диск, которое memcached не умеет из коробки. Также у редиса есть и много других фич из коробки которых нету memcached > Если читать/писать хватит производительности одного ядра одного цпу У вас устарела информация, начиная еще с 4 версии - редис умеет в потоки и утилизировать больше 1 ядра > Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания. Судя по всему вы очень давно щупали редис - думаю версии до 3. Уже давно все детские болезни починили и много разных фич завезли. Сейчас можно использовать редис практически во всех сценариях, просто правильно конфигурируя под тот который нужен вам. в частности полноценная масштабируемость (шардинг + репликация) уже из коробки. Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого софта которые умеет только в мемкеш. Спомощью крутилок всегда можно сделать то что вам нужно практически из коробки, но да крутилок намного больше чем в мемкеше;)
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	18. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от пох. (?), 19-Сен-19, 17:11
	> в частности полноценная масштабируемость (шардинг + репликация) уже из коробки. но лучше ту коробку не открывать без респиратора. > Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого но тут присоединяюсь - мемкэш доломали, если не собираешься его самостоятельно дописывать (причем вернувшись куда-нибудь во времена 1.3) - лучше просто использовать redis.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	19. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от RNZ (ok), 19-Сен-19, 21:01
	Плюшек в redis понапихали, но нет, не умеет он в треды, ну так-то они в нём есть изначально, по одному - io к диску, io по сети, лог и main. Но из 64 ядер на 2х cpu он будет утилизировать только одно ядро, ну и когда бросает данные на накопитель ещё одно - и всЁ. И кластер у него не пойми как работает. Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для кеширования в мелких веб-проектиках, но увы, народ легко на хайп ведётся и пихает всюду это недоразумение. [не]судите дальше.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	21. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от пох. (?), 20-Сен-19, 10:45
	> И кластер у него не пойми как работает. воооот у мемкыша-то кластер - пооонятно как работает. нет ножек, нет проблемы, да? С тредами - это "design decision"(c). Поскольку кластерные конфигурации, когда его писали, упирались (внезапно!) в сеть, а не в способность одного ядра эту сеть наполнять. зато нет интерлоков и неизбежных потерь на них (во времена мемкэша 1.3 интеловцы обнаружили, что после четвертого ядра производительность падает, а не растет) впрочем, полагаю, время отклика пейсбуку как раз совершенно неинтересно, учитывая модный-современный openssl(!) навернутый ими в качестве "защщщыты". > Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для > кеширования в мелких веб-проектиках вот мемкэш-то мооожно, дооо, дооо.
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	25. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+2 +/–
	Сообщение от RNZ (ok), 21-Сен-19, 15:22
	Узлы в кластере не обязаны быть связаны, не обязаны заниматься распределением и ребалансировкой, но могут (делать это вменяемо, см. 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
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	29. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	–1 +/–
	Сообщение от пох. (?), 22-Сен-19, 17:12
	> Узлы в кластере не обязаны быть связаны тогда это не кластер, а просто набор несвязанных сервисов. А вопросы задержек, синхронизации и фэйловера надо задавать уже тому, кто за них это делает. > И до лампочки что там у facebook ну так и что там у тебя - до лампочки, потому что непонятно ни как это настроено, ни как используется. Какой-то синтетический тест? А какое он имеет отношение к (моим, к примеру) реальным применениям? вообще - результаты странные. Если бы меня интересовали результаты такого теста - надо было бы лезть разбираться, что не так в тесте или в мемкэше.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	30. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от RNZ (ok), 22-Сен-19, 18:03
	Связанность может быть обеспечена на 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. Так что прекращай пузырить.
	Ответить \| Правка \| ^ к родителю #29 \| Наверх \| Cообщить модератору


	31. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	–1 +/–
	Сообщение от пох. (?), 22-Сен-19, 22:29
	> Связанность может быть обеспечена на 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. Потом будете рассказывать - имеют хоть какое-то значение эти ваши миллисекундные пиписькомерки, или ни малейшего.
	Ответить \| Правка \| ^ к родителю #30 \| Наверх \| Cообщить модератору


	32. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от RNZ (ok), 23-Сен-19, 13:45
	>не доказано Твои проблемы >"обычные условия" лично у меня явно ничего общего с этой хренью не имеют. Тоже твои проблемы >-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.
	Ответить \| Правка \| ^ к родителю #31 \| Наверх \| Cообщить модератору


	33. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от пох. (?), 23-Сен-19, 17:41
	> Твои проблемы твои - ты же пыжился тут кому-то что-то втереть. > Мне это не нужно, уже давно всё измерено и взвешено. И миллисекунды складываются в секунды. узнаю, узнаю дЭффехтивных менеджеров. Они вообще не складываются. > Не доверяй ты своему потолочному калькулятору, он у тебя врёт. он у меня не врет - а ты не умеешь даже собственные данные оценивать. (впрочем, пейсбуковцы плакались о той же проблеме) > memcached даже c -t 1 вывозит в 2,6 раза больше с в 2,6 раза меньшей latency: а при наращивании числа ядер - закономерно _теряет_ это свое преимущество, упираясь во внутренние локи. Что твои измеризмы наглядно и демонстрируют - но ты видишь в них фигу, а калькулятор, конечно же, врет у меня. > Это не интересно и совершенно не имеет смысла это изучать, т.к. известно, что программа > выполняется в ОС с вытесняющей многозадачностью. это, в отличие от твоего надувательства щек про "складывание в секунды" - явный показатель что что-то пошло очень криво, и вместо предсказуемого результата за фиксированное время, не смотря на привязку к конкретным ядрам и локнутую память - хваленый мемкэш о чем-то задумался на время, на четыре порядка(!) большее чем обычно. И когда под реальной, а не высосанной из пальца нагрузкой, ВНЕЗАПНО он начнет так задумываться на каждый второй запрос - а, ну да, дЭффехтивный уже в другом месте руководит процессами. > Уясни наконец, что redis масштабируется через костыли. спасибо, что бы я без тебя делал. твои же измеризмы показали ясно - эффективность "масштабирования" непатченного мемкэша в пределах одного-единственного процессора - менее 50%. Думаю, хуже и ненадежнее сделать с редисом- надо будет постараться. А когда ты начнешь те же костыли костылить в приложении (потому что, кто бы мог подумать, уперлись в network latency и все измеризмы с микросекундами пошли лесом, а еще, внезапно, понадобился фэйловер) - они от этого костылями быть перестанут, превратившись в изящнейшие подпорочки. > И там где справится один memcached, не нужно разводить 10-20 редисов. ага, согласно твоим же измеризмам, хватит 5-6. При условии, конечно, что не справится и один - а на микросекундные персентили пользователям вообще-то наплевать. При этом они сожрут таки 6 ядер, а не 20, и дадут более предсказуемый результат. > есть memcached на стеройдах - на seastar с dpdk. это решение опять каких-то пейсбукопроблем, а не моих. Кстати, намекающее, что кто-то в сетевую -то уперся. Ну и хрен с ними - это, повторяю, не мои проблемы, у меня совсем другая область применения мемкэшей - и там у них никаких явных преимуществ нет (были в простоте и предсказуемости поведения, но доломаны). А пейсбук у нас, к счастью, один.
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	34. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от RNZ (ok), 23-Сен-19, 21:11
	Не пыжился я, это ты начал пузырить (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.305s memcached - 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
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	35. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от RNZ (ok), 23-Сен-19, 21:15
	--дубликат--
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	23. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	–1 +/–
	Сообщение от пох. (?), 20-Сен-19, 10:54
	> У них сравнимая производительность, если отключить сбрасывание данных на диск оно у редиса было организовано примерно из того же дерьма и палок, что и все остальное - поэтому на производительность влияет примерно никак, основной демон делает fork, и немедленно забывает про все эти дисковые проблемы, задачей записи занимается потомок, никак не мешая обрабатывать текущие запросы. Сомневаюсь что в четвертой и fsfопротивной пятой что-то поменялось. Степень консистентности этих данных (как и консистентности слейвов в кластере, обслуживаемых примерно по тому же принципу) оставляется для самостоятельного изучения ;-) безумству храбрых, использующих ЭТО не для распределенной замены мемкэшу, а для долговременного хранения чего-то важного, что нельзя просто заново прочитать из нормальной, персистентной базы - поем мы песню.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	37. "'Редиска'"	+/–
	Сообщение от qweo (?), 28-Сен-19, 15:57
	... на несвободный? ССЗБ
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

2. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
Сообщение от Медведшатун (?), 18-Сен-19, 22:35
>требуется, чтобы файл находился на RAM-диске Откуда такие требования?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от аааааа (?), 19-Сен-19, 00:18
	Иначе вестимо будет тормазить. А про двойной расход памяти недумают.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от rshadow (ok), 19-Сен-19, 01:21
	Вообще конечно это решение не для ребута тачки. А только рестарта самого мемкеша. Какие проблемы это решает? Апгрейд? Борьба с утечками памяти или благами в коде?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	14. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от пох. (?), 19-Сен-19, 11:32
	какие-то пейсбукопроблемы. Для прочих смертных он уже просто ненужно.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	10. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+3 +/–
	Сообщение от Andrey Mitrofanov_N0 (??), 19-Сен-19, 09:00
	>А про двойной расход памяти недумают. mmap() с tmpfs-а -- нет "двойного расхода". //на ядре kernel.org
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	4. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от KonstantinB (ok), 19-Сен-19, 00:55
	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.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	9. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от Аноним (9), 19-Сен-19, 08:34
	То есть можно и на диск для persistence вместо lmdb.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	36. "Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."	+/–
	Сообщение от Аноним (36), 23-Сен-19, 21:59
	Мемкеш, похоже, чекает, что находится на RAM-сторадже. Наверное, можно и к диску присобачить через эмуляцию NVDIMM-памяти, но, скорее всего, толку будет мало.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору