Memcache::set() 损坏的管道

一般来说，Memcache 正在工作......但我的日志中多次出现这样的情况：

Memcache::set() [memcache.set]: 发送 8192 字节失败，errno=32 管道破裂

（字节数变化）

PHP5.3, Memcache https://www.php.net/Memcache类（v2.2.5 - 最新稳定version http://pecl.php.net/package/memcache)

什么是断水管，为什么发生这么多，可以改善吗？

我对此进行了相当多的研究和阅读，并且听到了很多对此的困惑。关于服务器端 Memcached 选项的文档非常少。我发现了一个隐藏的宝石，令人惊讶的是它由 MySQL 托管。一探究竟http://downloads.mysql.com/docs/mysql-memcached-en.pdf http://downloads.mysql.com/docs/mysql-memcached-en.pdf

有一些潜在的原因，其中一些令人信服地引用了：

• 操作系统级别的 ulimit 设置为阻止其他连接的特定级别
• 连接数已达到上限
• 它只发生在高负载期间（抱歉，但是废话！）

我无法理解也无法想象上述内容在大多数情况下都是正确的。对于我们的例子，事实证明，当应用程序先前在自动模式下运行时（在 -vv 详细模式下，我们说 ascii 写入），我们切换到了二进制模式连接选项。一旦我们打开二进制选项，写入全部失败，从而导致管道损坏。

至于最大连接数影响，当您通过远程登录查看统计数据时，可以检测到它们。寻找以下内容

STAT accepting_conns 1
STAT listen_disabled_num 0

If 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.ini 文件上的 memcached.sess_lock_wait ，请参阅php -i|grep memcached了解更多信息）。

祝你好运！