丸ノ内テックブログ、賑やかしのためのネタを探しに自分ブログの過去記事を見直してみたところ、そこそこ面白そうな話を見つけたので、ここで再掲載してみます。

昔むかし、あるWEBサイトで、セッションデータをmemcachedに保存していました。
順調にアクセスを捌けていたのですが、ある時、MySQLへのアクセス負荷を軽減しようと思い、マスター系データの一部(更新されないデータ)もmemcachedにキャッシュすることにしました。

よく使う手なので心配していなかったのですが、途端にWEBサイトのレスポンスがガクッと遅くなりました。

memcachedへの同時アクセス数がボトルネックになったことまで推測できるものの、一体どこに原因があるのか。

(1) memcachedの設定？

起動オプションを確認しました。

 同時接続数：10,000
メモリ割当：2GB

です。WEBサーバの最大セッション数×2（セッションデータのget と、マスターデータのget）としても十分有り余る設定でした。memcachedの設定の問題ではなさそうです。

(2) memcachedサーバの通信帯域？

インフラレベルでデータ転送量を見る限り、アップアップしている様子はありません。
（そもそも、DBデータをキャッシュしようと思った時に、転送量は見積もり済みです）

(3) memcachedサーバ内の何か？

vmstatとか、sarとか、その辺りを叩いてみたところ（当時、dstatは知らなかった）、
…見つけました。

 11211ポートで、受付拒否、いや、取りこぼしが発生してるってことです。

私のスキルじゃここでお手上げで、Google先生に質問したところ、

“SYNs to LISTEN sockets dropped”

KLab様のブログを教えてくれました。さすがDSAS開発者様です。
http://dsas.blog.klab.org/archives/51977201.html

「net.core.somaxconn」の値が小さいと、backlogの値、すなわちTCPソケットの接続要求を捌くキューの容量を
狭めることになるので、それが原因で通信不全が起こっていたということでした。

/etc/sysctl.conf

 にしておいて、再起動は嫌なので、

 も実行しておきました。

今どきのAmazon ElastiCache なんかだと、こういう設定まわりは気にする余地もなくなります。
サーバって何なのか、だんだんと勘所が分からなくなっていくけど、そういうご時世ってことでしょうか。