Я довольно долго изучал и читал об этом и слышал много путаницы по этому поводу.Там очень мало документации по опциям Memcached на стороне сервера.Я нашел скрытый драгоценный камень, удивительно размещенный MySQL.Проверьте это http://downloads.mysql.com/docs/mysql-memcached-en.pdf
Существует несколько потенциальных причин, некоторые из которых убедительно процитированы:
- ulimit на уровне ОС установлен на определенный уровень, который блокирует дополнительные соединения
- количество соединений превысило
- это происходит только при высокой нагрузке (извините, но!)
Я не смог ни понять, ни представитьвыше, верно для большинства случаев.В нашем случае оказывается, что мы переключались в режим подключения в двоичном режиме, когда приложение ранее работало в автоматическом режиме (в подробном режиме -vv, мы говорим, ascii пишет).Как только мы включили двоичную опцию, все записи заканчивались сбоем, что приводило к разрыву каналов.
Что касается максимальных выпадений соединений, их можно обнаружить, когда вы посмотрите на статистику, когда вы входите в нее через telnet.Посмотрите на следующее
STAT accepting_conns 1
STAT listen_disabled_num 0
Если listen disabled_num
равно 0, это хорошо.Это означает, что с момента запуска экземпляра memcached нет сбрасываемых соединений.
Также попробуйте оптимизировать ваше соединение с помощью следующих параметров Memcached, по крайней мере в PHP, мы используем следующее:
$this->m = new Memcached();
$this->m->setOption(Memcached::OPT_TCP_NODELAY, true);
$this->m->setOption(Memcached::OPT_LIBKETAMA_COMPATIBLE, true);
$this->m->setOption(Memcached::OPT_SERIALIZER, Memcached::SERIALIZER_IGBINARY);
Все, что я могу сказать, это попробовать несколько комбинаций настроек на стороне приложения, на стороне сервера memcached и изменить другие настройки по умолчанию в приложении (например, memcached.sess_lock_wait в файле memcached.ini, см. php -i|grep memcached
для получения дополнительной информации).
Удачи!