2

pecl の memcached (D に注意してください。memcache と memcached の 2 つがあります) 拡張を使用して、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 つのボックスとは、memcached クラスターへの OUTBOUND 接続を行う 2 つの異なるサーバーを意味します。両方とも同じLAN上にあります。

注: セキュリティのために、上記の 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 の誰もがこれを読むとは思えませんが、読んでいる場合は、よろしくお願いします。

Twitter は最近 (2012 年 2 月だと思います)、memcached プロキシをオープンソース化しました。

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

本質的に、これはすべて、memcached プロトコルの ip:port またはソケットベースのプロキシです。

ip:port またはソケットにバインドできます。ソケットルートを選択しました。

そのため、残っているのは、memcached サーバーのプールにアクセスできるローカルにホストされたソケットです。

pecl 拡張機能 memcached 2.0.0b1+ は、ソケット ベースの接続をサポートします。

したがって、ステップバイステップは次のようになります。

php -> memcached 2.0.2 pecl 拡張機能 -[LOCALLY HOSTED SOCKET] -> Twitter の素晴らしい memcached プロキシ -[TRULY PERSISTENT CONNECTIONS] -> memcached サーバーのプール

TCP リセットが停止しました。

言及する価値があります：

最初に、Twitter memcached プロキシ 127.0.0.1 をバインドしようとしました... pecl memcached を twitter プロキシと通信させたときでさえ、tcp のリセットが見られました.... 奇妙な!

これは言うまでもなく「修正」ではないと思います...しかし、それは私たちの側で問題を解決しました。

楽しい！

于 2012-05-24T10:17:08.723 に答える