SPDY/1.3.4: strange connection buildup

[Tom van der Woerdt]

Hi,

I've attached two Munin screenshots that show a strange issue I've been 
having with nginx. I'm running the 1.3.4 version with the SPDY patch 
(latest, 51) and it really looks like nginx sometimes forgets to close 
connections.

I've been running the SPDY patch since version 38, which is just under 2 
months ago. The attached screenshots really show the issue well.

A few things:
  * Before the SPDY patch, the connection count would go to nearly 0 in 
the night.
  * After the patch, even at night the connection count would stick to 
20 or 30. This is not entirely unexpected as the SPDY protocol suggests 
not letting the connection time out unless necessary.
  * I've always used the exact same build arguments (see below) and I 
haven't changed the configuration recently.
  * Before patch 50/51 the connection count would hardly ever go above 100.
  * After patch 50/51 the connection count managed to go over 300 and 
never below 80.
  * Note in the month screenshot how between week 29 and week 30 there 
was a pretty low connection count. This is because that week I restarted 
the server. It seems to take a while for nginx to start making mistakes.
  * The drop in connections tonight was because I restarted nginx.
  * The server only serves 1 SPDY/SSL site which has approximately 40 or 
50 unique visitors a day. All other sites are HTTP-only and hardly 
popular. There's no reason for the server to have 300 active connections.

I'm hoping that someone else can reproduce this issue as well.

Tom




Right, here go the build arguments:
> ./configure \
>     --prefix=/etc/nginx/ \
>     --sbin-path=/usr/sbin/nginx \
>     --conf-path=/etc/nginx/nginx.conf \
>     --error-log-path=/var/log/nginx/error.log \
>     --http-log-path=/var/log/nginx/access.log \
>     --pid-path=/var/run/nginx.pid \
>     --lock-path=/var/run/nginx.lock \
>     --http-client-body-temp-path=/var/cache/nginx/client_temp \
>     --http-proxy-temp-path=/var/cache/nginx/proxy_temp \
>     --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \
>     --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp \
>     --http-scgi-temp-path=/var/cache/nginx/scgi_temp \
>     --user=nginx \
>     --group=nginx \
>     --with-http_ssl_module \
>     --with-http_realip_module \
>     --with-http_addition_module \
>     --with-http_sub_module \
>     --with-http_dav_module \
>     --with-http_flv_module \
>     --with-http_mp4_module \
>     --with-http_gzip_static_module \
>     --with-http_random_index_module \
>     --with-http_secure_link_module \
>     --with-http_stub_status_module \
>     --with-mail \
>     --with-mail_ssl_module \
>     --with-file-aio \
>     --with-ipv6 \
>     --with-cc-opt='-O2 -g -m32 -march=i386 -mtune=generic 
> -fasynchronous-unwind-tables' \
>     --with-openssl='/root/libraries/openssl-1.0.1c/'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx_status-month.png
Type: image/png
Size: 41567 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120813/8b01f2a3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx_status-week.png
Type: image/png
Size: 32292 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120813/8b01f2a3/attachment-0003.png>