|
|
3.13, пох. (?), 11:31, 19/09/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
если ты не пейсбук - для любых твоих задач лучше уже редис. мемкэш изуродован пейсбуковцами до полной неузнаваемости, все полимеры (которых в общем и так было ограниченное количество) успешно продолбаны.
Если ты админ локалхоста, разьве что...хотя и в этом случае редис -просто работает из коробки в любом вменяемом дистрибутиве, а на мелочи на локалхосте наплевать.
| |
|
4.24, Аноним (24), 12:45, 20/09/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Каждый раз читая твои посты, я удивляюсь тому, насколько наша страна богата талантами, которые нахрен никому не нужны.
| |
|
5.27, Аноним (27), 10:21, 22/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
> наша страна
Страна Анонима обычно размыта до размеров всей Вселенной (и даже больше ;) Так что да, Пох находится в вашей стране уважаемый Аноним ;)
| |
|
6.28, Аноним (26), 10:45, 22/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
ОФФ:
Анек.
В Израиль ты приехал, ты - русский.
В Россию - еврей.
Лопата. )))
Страна бывает виртуальная, в сознании. Из неё не уехать. Если только долго, долго "идти пешком" тайгой без троп.
| |
|
|
|
3.16, RNZ (ok), 12:51, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.
Если читать/писать хватит производительности одного ядра одного цпу, то redis может казаться более удобным в использовании. Ну а всякие плюшки типа pub/sub в redis - это на любителя (redis всё равно это делает через опу). Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.
| |
|
4.17, Anonimus (??), 13:14, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Если много читать/писать и требуется утилизировать железо по максимуму, то memcached.
У них сравнимая производительность, если отключить сбрасывание данных на диск, которое memcached не умеет из коробки. Также у редиса есть и много других фич из коробки которых нету memcached
> Если читать/писать хватит производительности одного ядра одного цпу
У вас устарела информация, начиная еще с 4 версии - редис умеет в потоки и утилизировать больше 1 ядра
> Если требуется масштабируемое решение, то на redis это делается через оверхед и страдания.
Судя по всему вы очень давно щупали редис - думаю версии до 3. Уже давно все детские болезни починили и много разных фич завезли. Сейчас можно использовать редис практически во всех сценариях, просто правильно конфигурируя под тот который нужен вам. в частности полноценная масштабируемость (шардинг + репликация) уже из коробки.
Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого софта которые умеет только в мемкеш. Спомощью крутилок всегда можно сделать то что вам нужно практически из коробки, но да крутилок намного больше чем в мемкеше;)
| |
|
5.18, пох. (?), 17:11, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
> в частности полноценная масштабируемость (шардинг + репликация) уже из коробки.
но лучше ту коробку не открывать без респиратора.
> Лично я бы рекомендовал для всех случаев использовать редис за исключением использования старого
но тут присоединяюсь - мемкэш доломали, если не собираешься его самостоятельно дописывать (причем вернувшись куда-нибудь во времена 1.3) - лучше просто использовать redis.
| |
5.19, RNZ (ok), 21:01, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Плюшек в redis понапихали, но нет, не умеет он в треды, ну так-то они в нём есть изначально, по одному - io к диску, io по сети, лог и main. Но из 64 ядер на 2х cpu он будет утилизировать только одно ядро, ну и когда бросает данные на накопитель ещё одно - и всЁ. И кластер у него не пойми как работает.
Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для кеширования в мелких веб-проектиках, но увы, народ легко на хайп ведётся и пихает всюду это недоразумение.
[не]судите дальше.
| |
|
6.21, пох. (?), 10:45, 20/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
> И кластер у него не пойми как работает.
воооот у мемкыша-то кластер - пооонятно как работает.
нет ножек, нет проблемы, да?
С тредами - это "design decision"(c). Поскольку кластерные конфигурации, когда его писали, упирались (внезапно!) в сеть, а не в способность одного ядра эту сеть наполнять.
зато нет интерлоков и неизбежных потерь на них (во времена мемкэша 1.3 интеловцы обнаружили, что после четвертого ядра производительность падает, а не растет)
впрочем, полагаю, время отклика пейсбуку как раз совершенно неинтересно, учитывая модный-современный openssl(!) навернутый ими в качестве "защщщыты".
> Нельзя редис во всех сценариях использовать, его вообще нельзя использовать, кроме как для
> кеширования в мелких веб-проектиках
вот мемкэш-то мооожно, дооо, дооо.
| |
|
7.25, RNZ (ok), 15:22, 21/09/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Узлы в кластере не обязаны быть связаны, не обязаны заниматься распределением и ребалансировкой, но могут (делать это вменяемо, см. scylladb).
И интеловцы могут-что угодно обнаружить, там где беда не с софтом, а с их процессорами.
И до лампочки что там у facebook, но что-бы пресечь всякое вспениваение и лапшу про throughput и latency:
redis - https://paste.ubuntu.com/p/G673Yby32b/
[OVERALL], RunTime(ms), 452433
[OVERALL], Throughput(ops/sec), 22102.72018177277
[INSERT], Operations, 10000000
[INSERT], AverageLatency(us), 1354.2462232
[INSERT], MinLatency(us), 99
[INSERT], MaxLatency(us), 64063
[INSERT], 95thPercentileLatency(us), 1656
[INSERT], 99thPercentileLatency(us), 1774
[INSERT], Return=OK, 10000000
memcached - https://paste.ubuntu.com/p/fqX5m5vNJD/
[OVERALL], RunTime(ms), 50390
[OVERALL], Throughput(ops/sec), 198452.07382417147
[INSERT], Operations, 10000000
[INSERT], AverageLatency(us), 133.8726188
[INSERT], MinLatency(us), 44
[INSERT], MaxLatency(us), 172287
[INSERT], 95thPercentileLatency(us), 227
[INSERT], 99thPercentileLatency(us), 467
[INSERT], Return=OK, 10000000
| |
|
8.29, пох. (?), 17:12, 22/09/2019 [^] [^^] [^^^] [ответить] | –1 +/– | тогда это не кластер, а просто набор несвязанных сервисов А вопросы задержек, ... текст свёрнут, показать | |
|
9.30, RNZ (ok), 18:03, 22/09/2019 [^] [^^] [^^^] [ответить] | +/– | Связанность может быть обеспечена на application уровне Тест самый приближенны... текст свёрнут, показать | |
|
10.31, пох. (?), 22:29, 22/09/2019 [^] [^^] [^^^] [ответить] | –1 +/– | не доказано tl dr обычные условия лично у меня явно ничего общего с этой хрень... текст свёрнут, показать | |
|
11.32, RNZ (ok), 13:45, 23/09/2019 [^] [^^] [^^^] [ответить] | +/– | Твои проблемы Тоже твои проблемы 1024 по default, без всяких намёков А не надо з... текст свёрнут, показать | |
|
12.33, пох. (?), 17:41, 23/09/2019 [^] [^^] [^^^] [ответить] | +/– | твои - ты же пыжился тут кому-то что-то втереть узнаю, узнаю дЭффехтивных менед... большой текст свёрнут, показать | |
|
13.34, RNZ (ok), 21:11, 23/09/2019 [^] [^^] [^^^] [ответить] | +/– | Не пыжился я, это ты начал пузырить https www opennet ru openforum vsluhforum... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
5.23, пох. (?), 10:54, 20/09/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> У них сравнимая производительность, если отключить сбрасывание данных на диск
оно у редиса было организовано примерно из того же дерьма и палок, что и все остальное - поэтому на производительность влияет примерно никак, основной демон делает fork, и немедленно забывает про все эти дисковые проблемы, задачей записи занимается потомок, никак не мешая обрабатывать текущие запросы. Сомневаюсь что в четвертой и fsfопротивной пятой что-то поменялось.
Степень консистентности этих данных (как и консистентности слейвов в кластере, обслуживаемых примерно по тому же принципу) оставляется для самостоятельного изучения ;-)
безумству храбрых, использующих ЭТО не для распределенной замены мемкэшу, а для долговременного хранения чего-то важного, что нельзя просто заново прочитать из нормальной, персистентной базы - поем мы песню.
| |
|
|
|
|
|
2.3, аааааа (?), 00:18, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Иначе вестимо будет тормазить. А про двойной расход памяти недумают.
| |
|
3.5, rshadow (ok), 01:21, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вообще конечно это решение не для ребута тачки. А только рестарта самого мемкеша.
Какие проблемы это решает? Апгрейд? Борьба с утечками памяти или благами в коде?
| |
|
4.14, пох. (?), 11:32, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
какие-то пейсбукопроблемы. Для прочих смертных он уже просто ненужно.
| |
|
|
2.4, KonstantinB (ok), 00:55, 19/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
This feature works by putting memory related to item data into an external mmap file (specified via -e). All other memory; the hash table, connection memory, etc, stay in normal RAM. When the daemon is restarted, it runs a pass over the item data and fixes up all the internal pointers. It also regenerates the hash table.
| |
|
|
4.36, Аноним (36), 21:59, 23/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Мемкеш, похоже, чекает, что находится на RAM-сторадже. Наверное, можно и к диску присобачить через эмуляцию NVDIMM-памяти, но, скорее всего, толку будет мало.
| |
|
|
|
1.11, Ilya Indigo (ok), 10:38, 19/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Если бы он ещё научится расходовать память не всю сразу, которую ему предоставили, а только столько, сколько ему нужно в данный момент.
| |
|
|
3.15, Ilya Indigo (ok), 11:34, 19/09/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> И тратить время на довыделение?
1 Судя по сравнению с редиской не сильно она и тратит.
2 А вот как на сабже понять, выделенного Гига хватает или нет?
Сколько из него реально используется?
И когда подходит к порогу (например более 90% занято)?
Я так понимаю, пока порог не привысится и не начнут затираться старые записи - то и не узнаешь, что нужно больше?
А как оптимизировать потребление памяти, изменяя время жизни некоторых данных и мониторить как это отражается на потреблении памяти?
| |
|
4.20, Аноним (20), 05:36, 20/09/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
O(1) всегда, без исключений и всяких amortized - это главный и незыблемый принцип мемкеша, его основная фича, этим обусловлено все остальное. Если на это пофиг и хочется фич - всегда есть redis.
| |
4.22, пох. (?), 10:47, 20/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
> А вот как на сабже понять, выделенного Гига хватает или нет?
использовать любой из миллиона перделко-поделочных серверов статистики - или накорябать на коленке свой, используя запрос 'stats'.
| |
|
|
|
|