Назад | Перейти на главную страницу

memcached разбился без уведомления

Мы в значительной степени полагаемся на кэш памяти и обслуживаем несколько миллиардов запросов в месяц. У нас есть 5 серверов memcache. Прошлой ночью мы увидели увеличение нашего трафика на 25%. Графики показывают, что количество запросов и данных, передаваемых каждым кешем памяти, увеличивалось, что приводило к их сбою. Это запустило цепную реакцию, и каждый сервер memcache падал один за другим (нагрузка на сервер увеличивалась).

Мы не нашли журналов в syslog, сообщениях, файле журнала memcache (подробные настройки были отключены).

У меня два вопроса:

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

  2. Как я могу гарантировать, что они никогда больше не упадут. В конечном итоге это повлияло на наши серверы mysql и репликацию, а также на множество других связанных служб. Мне нужно больше серверов memcache?

Я запустил свой кэш памяти, используя этот сценарий init.d: http://pastebin.com/wfMnB4ta где ENABLE_MEMCACHE - ДА в / etc / default / memcached

/ usr / share / memcached / scripts / start-memcached: http://pastebin.com/LaUugXye

Спасибо

Я предполагаю, что вы используете версию 1.4.5 или более раннюю.

Поскольку вы упомянули об увеличении трафика, то внезапный выход:

  • Возможно, вы достигли максимального количества подключений (см. http://memcached.org/timeouts для обсуждения этого вопроса).
  • Если вы долгое время забиваете лимит подключений, возникла ошибка, из-за которой memcached закрывался.
  • Это было частично исправлено в версии 1.4.6, далее исправлено в версии 1.4.7 и улучшено до версии 1.4.9.

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

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

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

Однако этого конкретного отказа, вероятно, было бы невозможно избежать. Вы мало что можете сказать о сбое, вызывающем увеличение нагрузки.