The OpenNET Project / Index page

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



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

"Релиз Memcached 1.5.18 с поддержкой сохранения кэша между пе..."  +/
Сообщение от opennews (??), 18-Сен-19, 22:35 
Состоялся релиз системы кеширования данных в оперативной памяти Memcached 1.5.18, оперирующей данными в формате ключ/значение и отличающейся простотой использования. Memcached обычно применяется как легковесное решение для ускорения работы высоконагруженных сайтов путём кэширование доступа к СУБД и промежуточным данным. Код поставляется под лицензией BSD...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51514

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | 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.ru/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 | Индекс форумов | Темы | Пред. тема | След. тема




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

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