2

我们使用 pecl 的 memcached（注意 D，有 2 个，memcache 和 memcached）扩展连接到 memcached 1.4.13 盒子的集群。

我们注意到发生了大量的 tcpip 重置：

[root@box ~]# netstat -s | grep unexpected
2078913548 connections reset due to unexpected data

[root@box ~]# tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0' -nn
13:30:45.786577 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.19093 > LANSUBNET.4.999: Flags [R], cksum 0xfad9 (correct), seq 1996582451, win 0, length 0
13:30:45.786697 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.11540 > LANSUBNET.100.999: Flags [R], cksum 0x904c (correct), seq 2003170685, win 0, length 0
13:30:45.793199 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.55125 > LANSUBNET.3.999: Flags [R], cksum 0x42c3 (correct), seq 1998297456, win 0, length 0
13:30:45.793389 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.19112 > LANSUBNET.4.999: Flags [R], cksum 0xa2b5 (correct), seq 1993131641, win 0, length 0
13:30:45.793547 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.11564 > LANSUBNET.100.999: Flags [R], cksum 0x447c (correct), seq 2003255604, win 0, length 0
13:30:45.817874 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.55135 > LANSUBNET.3.999: Flags [R], cksum 0x841c (correct), seq 1995200572, win 0, length 0
13:30:45.818549 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
LANSUBNET.1.55141 > LANSUBNET.3.999: Flags [R], cksum 0x385d (correct), seq 1997841357, win 0, length 0

Memcached 绑定在我们所有的 memcached 盒子的 999 端口上。

我们是否错误地诊断了这一点？

这可能是什么原因造成的？

我们肯定知道：

A）这与 mecached pecl 扩展无关（注意 d，有 2 个扩展...memcache 和 memcached）。我们尝试切换到另一个 memcache 扩展，但出现了同样的问题。

B) 这实际上 100% 是由 memcache 连接引起的。我们禁用了 php -> memcached 会话，并且由于 netstat 中的意外数据而重置的连接立即停止增长。

C）我们在 2 个盒子上出现了这个问题，所以我不认为它是特定于服务器的问题。当我说 2 个盒子时，我的意思是 2 个不同的服务器，它们与我们的 memcached 集群建立 OUTBOUND 连接。他们都坐在同一个局域网上。

注意：为了安全起见，我们将上面的 LAN 子网更改为“LANSUBNET”...这是在此处发布消息之前完成的；）

任何帮助，将不胜感激！

谢谢。

更多数据：

[root@box ~]# netstat -s | grep unexpected ; sleep 1 ; netstat -s | grep unexpected ;
2089258664 connections reset due to unexpected data
2089258858 connections reset due to unexpected data

所以看起来，在“不太忙”的时间里，重置以大约 200 / 秒的速度发生。哎哟!

另外，非常值得一提：

我们执行了以下操作：

tcpdump -nn -v 'tcp[tcpflags] & (tcp-rst) != 0' and tcp port not 999

因此过滤端口 999（我们的 memcached 守护进程所在的位置）......并且 tcp 重置缓慢到微小的涓涓细流......几分钟，我认为这在相当繁忙的服务上是可以接受的。

4

2 回答 2

1

我们已经找到了这个问题的完整解决方案。

这是由 memcached pecl 扩展“Memcached::OPT_BUFFER_WRITES”常量设置为 true 引起的。

于 2012-05-28T14:58:02.387 回答
0

我找到了解决方案。

我怀疑推特上的任何人都不会读到这个，但如果你是，谢谢你：

twitter 最近（我相信是 2012 年 2 月）开源了他们的 memcached 代理。

https://dev.twitter.com/blog/twemproxy

本质上，这一切都是基于 ip:port 或 socket 的 memcached 协议代理。

您可以将其绑定到 ip:port 或套接字。我们选择了套接字路由。

所以我们剩下的是一个本地托管的套接字，我们可以从中访问我们的 memcached 服务器池。

pecl 扩展 memcached 2.0.0b1+ 支持基于套接字的连接。

所以现在一步一步如下：

php -> memcached 2.0.2 pecl extension -[LOCALLY HOSTED SOCKET]-> twitters awesome memcached proxy -[TRULY PERSISTENT CONNECTIONS]-> memcached 服务器池

tcp 重置已停止。

值得一提：

我们最初尝试绑定 twitter memcached 代理 127.0.0.1 ......即使我们让 pecl memcached 与 twitter 代理通信，我们看到 tcp 重置......奇怪！

我想这不是一个“修复”……但它解决了我们的问题。

请享用！

于 2012-05-24T10:17:08.723 回答