課題

nginxでsocket(pathname)を使用して通信効率をあげようとしてみた。通信量が増えてきた所でResource temporarily unavailableということでリソース不足で怒られるようになった。

2015/11/10 23:02:27 [error] 1298#0: *296601104 connect() to unix:///tmp/sample.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.1.2, server: hoge.com, request: "POST /sample.php?p=xx_xx&_=1447164211618 HTTP/1.1", upstream: "uwsgi://unix:///tmp/sample.sock:", host: "hoge.com", referrer: "https://www.foo.com/xxx/yyy/"

設定

対象になりそうな部分だけみてみると、

nginx.conf

worker_processes 2;
worker_rlimit_nofile 65536;

events {
  worker_connections 1024;
}

  location / {
    # uWSGI application
    include uwsgi_params;
    uwsgi_pass unix:///tmp/sample.sock;
    uwsgi_connect_timeout 2s;
    uwsgi_read_timeout 2s;
  }

思い当たりそうなところを調べてみる

うーん、リソース不足...CPUもメモリもまだ余裕がある

ulimitか？

# ulimit -n
1024

多くは無いけどｗ

socket fileは大量に出来るわけでも無いのでなんか違う気がする。
ファイルディスクリプタが問題ならtoo many open filesのほうが出てきそう。

Apacheの時は256くらいのプロセス数でやったことを考えると、Nginxなら2048くらいのコネクションが精一杯か...サーバ増やすのも対して面倒じゃなくなったのでスケールアウトなんてことも

そんなわきゃない

ネットワーク状態遷移とNginxへ通信が到達するところまでを調べてみた。

kernelのところに影響があったのか！

見てみる

# sysctl net.core.somaxconn
net.core.somaxconn = 128

128??? すくなっ!?

nginxで2048を受けること考えると倍くらいでも良いのかもしれないけど、大きめに設定。この値はnet.core.somaxconnより大きかった場合、net.core.somaxconnの値を優先するようです。
(環境に合わせて数値は変更してください)

/etc/sysctl.conf

--(snip)--
net.ipv4.tcp_max_syn_backlog = 20480
net.core.somaxconn=20480

# sysctl -p

様子を見る

ログが出ないことを確認するでも良いのだがkernelのところの数値なのでもう少し深掘りしてみたい。

net.core.somaxconn=2048 のとき: 赤枠の所で少しあふれた

net.core.somaxconn=20480 のとき

embryonic resets?

Configuring TCP InterceptやTCP half-openによると

一般的には、TCP SYN、SYN ACKまでのやり取りがされた、完全ではないTCPコネクションをハーフオープンセッションと呼んだりします。他にも呼び方はいろいろあります（embryonicとも言ったりします）が、ハーフオープンセッションと言えば大体通じると思います。

なるほど、ハーフオープンセッションがリセットされた(dropのような)ことが起きてると解釈できそうな気がするので、この数値が下がってると少なくとも改善していそう！！

そういえば

Resource temporarily unavailableってなんだろうと

stack traceのコマンドで見れるらしい。

strace -tt -p [TARGET_PID] 2>&1 |tee /tmp/trace.txt|grep EAGAIN

00:51:18.848228 read(71, 0x2344873, 33093) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.855058 read(36, 0x2344873, 33093) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.858554 write(682, "hogehog""..., 5679) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.892731 recvfrom(71, 0x2395418, 109, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.902643 recvfrom(383, 0x3425370, 213, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.909802 recvfrom(383, 0x7fff72d0a7bf, 1, 2, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.916927 recvfrom(383, 0x3c2e640, 1024, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
00:51:18.923724 read(406, 0x2344873, 33093) = -1 EAGAIN (Resource temporarily unavailable)

いっぱい出てきたのでこの辺にしておこう。。。

まとめ

相変わらずSocketまわりを調べると知らないことがたくさんある... EAGAINがなんぞやなんて疑問が出てきてしまいまだまだ調べることは多そう

参考資料

Tuning TCP and NGINX on EC2
http://www.slideshare.net/chartbeat/tuning-tcp-and-nginx-on-ec2

Tuning NGINX for Performance
https://www.nginx.com/blog/tuning-nginx/

え、サーバ増やしてませんか？ソケット設定したその後に！？

課題

設定