Для юзера это выглядит как разлогинивание, особенно если нет автологина. Я бы, например, обиделся, если посреди написания гигантского поста на Хабр у меня бы слетела сессия, а я бы забыл это сохранить ;)
Разделяемая память — да, это отличная штука, пока одна машина, один язык программирования и один код. Но дальше не масштабируется. А так согласен, пошустрее будет.
Тем же пингом можно, интервал поменьше, потери он покажет. Если честно, я совсем не админ, так что тут, возможно, нужен «админский глаз». Если я прав про сетевые проблемы, конечно.
Согласен с первым, хотя на первом этапе роста это совершенно нормально, лишь бы не навсегда. Хотя, если объем кэширования велик, то memcached работает быстрее, чем, например, кэш на файлах.
Но это всё очень относительно и зависит от конкретной задачи, «серебряной пули» здесь нет.
При масштабировании и росте числа frontend-ов для большинства задач кластер memcached — то, что надо.
Насчет второго — если «нельзя терять» воспринимать буквально, то да, тогда это не задача для memcached, а для ACID-БД на хорошем RAIDе с батарейкой, с бэкапами off-site, hot standy и т. п.
Памяти в кластере memcached доступно столько, сколько есть. Сколько каждому нужно. Сегодня есть инсталляции (не самые большие), где кластер имеет ёмкость 750Гб, например. (Это то, о чем я знаю, есть и больше, я думаю).
Про slab-аллокатор я не сказал не случайно. Это тема отдельного разговора и статьи, которая будет попозже в цикле. Да, действительно он так работает, что если зоны будут иметь размер 16 и 32 Кб, то выделения в 16.1Кб пойдут в зону 32Кб и будут потери 50%. Однако сегодня memcached более умно адаптирует slab-аллокатор под потребности конкретной задачи (выделяет зоны нужного размера). Такое поведение slab-аллокатора — это его «фича», он обладает своими недостатками и своими преимуществами.
Запас есть всегда, надо лишь рассчитать грамотно и грамотно мониторить. Я не призываю всё хранить в memcached, я рассказываю о нём как о решении.
Насчет LRU — прямо под рукой линка нет, можете заглянуть в исходники, там механизм LRU достаточно явный.
Но это всё очень относительно и зависит от конкретной задачи, «серебряной пули» здесь нет.
При масштабировании и росте числа frontend-ов для большинства задач кластер memcached — то, что надо.
Насчет второго — если «нельзя терять» воспринимать буквально, то да, тогда это не задача для memcached, а для ACID-БД на хорошем RAIDе с батарейкой, с бэкапами off-site, hot standy и т. п.
Про slab-аллокатор я не сказал не случайно. Это тема отдельного разговора и статьи, которая будет попозже в цикле. Да, действительно он так работает, что если зоны будут иметь размер 16 и 32 Кб, то выделения в 16.1Кб пойдут в зону 32Кб и будут потери 50%. Однако сегодня memcached более умно адаптирует slab-аллокатор под потребности конкретной задачи (выделяет зоны нужного размера). Такое поведение slab-аллокатора — это его «фича», он обладает своими недостатками и своими преимуществами.
Запас есть всегда, надо лишь рассчитать грамотно и грамотно мониторить. Я не призываю всё хранить в memcached, я рассказываю о нём как о решении.
Насчет LRU — прямо под рукой линка нет, можете заглянуть в исходники, там механизм LRU достаточно явный.