Memcache :: set()断线 [英] Memcache::set() broken pipe

问题描述

通常，Memcache可以正常工作...但是我的日志中经常出现以下情况:

Memcache :: set()[memcache.set]:发送 8192个字节失败，错误码为errno = 32 管道破损

(字节数更改)

PHP5.3， Memcache 类(v2.2.5-最新的稳定版解决方案

我已经对此进行了很多研究和阅读，并且听到了很多困惑.服务器端有关Memcached选项的文档很少.我发现一个隐藏的宝石，出人意料地由MySQL托管.检出 http://downloads.mysql.com/docs/mysql-memcached- zh.pdf

有一些潜在的原因，有说服力的是:<​​/p>

• 将操作系统级别的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.ini文件上的memcached.sess_lock_wait，有关更多信息，请参见php -i|grep memcached ).

祝你好运！

In general, Memcache is working... but my log has many occurrences of this:

Memcache::set() [memcache.set]: send of 8192 bytes failed with errno=32 Broken pipe

(the number of bytes changes)

PHP5.3, Memcache class (v2.2.5 - the latest stable version)

What is a broken pipe, why is it happening so much, and can it be improved?

解决方案

I've been researching and reading on this for quite a bit and have been hearing a lot of confusion on this. There's very little documentation out there on Memcached options on the server side. I found a hidden gem, surprisingly hosted by MySQL. Check it out http://downloads.mysql.com/docs/mysql-memcached-en.pdf

There are a few potential causes, some quoted convincingly that:

• ulimit on the OS level is set to a certain level that blocks additional connections
• the number of connections have maxed out
• it only happens during high load (sorry, but duh!)

I haven't been able to fathom nor imagine the above being true for most cases. For our case, it turns out we were switching to binary mode connection option when the app was running on auto mode prior (in -vv verbose mode, we say ascii writes). Once we turned on the binary option, writes were all failing, hence causing broken pipes.

As for max connections fallouts they can be detected when you take a look at the stats when you telnet into it. Look for the following

STAT accepting_conns 1
STAT listen_disabled_num 0

If listen disabled_num is 0, that's good. That means there are no drop connections since the start of the memcached instance.

Also try to optimize your connection with the following Memcached options, at least in PHP, we use the following:

$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);

All I can say is, tryout a few combination of settings, on the app side, the memcached server side and change other default settings on app (e.g. memcached.sess_lock_wait on memcached.ini file, see php -i|grep memcached for more info).

Good luck!

这篇关于Memcache :: set()断线的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！