снова aio и утечка сокетов

Костенко Евгений nobody.mail на gmail.com
Чт Фев 3 15:35:35 MSK 2011


Всем доброго времени суток.

В очередной раз вопрос по aio и большой куче сокетов в состоянии CLOSED.
Как собственно и в обсуждаемых ранее случаях - "CLOSED" магическим образом
исчезают при рестарте nginx.

Все бы ничего, но не могу выловить закономерность - есть коробки под FreeBSD
7.x и 8.x, все amd64.
На некоторых из них, количество сокетов в состоянии "CLOSED" активно растет,
на других - редко отличается от нуля.
Предположительно это "заслуги" aio, т.к. началось после включения последнего
(на графиках munin это очень хорошо заметно).
Отказаться от aio к сожалению нельзя, в связи с его полезностью в условиях
текущей нагрузки.

> uname -a
> FreeBSD hostname.here 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19
02:36:49 UTC 2010     root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 amd64

Для сравнения взял 2 коробки с 8.1 amd64. Везде nginx 0.8.54 собранный с
одинаковыми параметрами:

> root at hostname:~# nginx -V
> nginx version: nginx/0.8.54
> TLS SNI support enabled
> configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I
/usr/local/include' --with-ld-opt='-L /usr/local/lib'
--conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
--error-log-path=/var/log/nginx-error.log --user=www --group=www
--with-file-aio --http-client-body-temp-path=/var/tmp/nginx/client_body_temp
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
--http-scgi-temp-path=/var/tmp/nginx/scgi_temp
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
--http-log-path=/var/log/nginx-access.log --with-http_addition_module
--with-http_geoip_module --with-http_gzip_static_module
--with-http_image_filter_module --with-http_perl_module
--with-http_realip_module --with-http_secure_link_module
--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module
--with-http_xslt_module --with-pcre

Конфиги nginx на коробках однотипные - используется "aio on", т.к.
proxy_cache на zfs/raidz.
Проблемный сервер в течение суток по нарастающей накрывает, т.к.
заканчиваются kern.maxfiles/kern.maxfilesperproc.

Конфиги nginx приводить полностью не стал, т.к. там много-много всего.
Выборочно:

user  nobody nogroup;
worker_rlimit_nofile 10240;
worker_processes  8;

pid        /var/run/nginx.pid;

events {
    worker_connections  10240;
    use kqueue;
}

http {
    server_names_hash_bucket_size 64;
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] $status
"$request" $body_bytes_sent "$http_referer" "$http_user_agent"
"$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main buffer=1m;

    sendfile        off;
    aio            on;
    server_tokens  off;

    output_buffers 1 128k;
    tcp_nopush     on;

    keepalive_timeout  15;
    tcp_nodelay        on;
    reset_timedout_connection on;
    uninitialized_variable_warn on;
    merge_slashes on;

    open_file_cache             max=1000 inactive=40s;
    open_file_cache_valid       60s;
    open_file_cache_min_uses    2;
    open_file_cache_errors      on;

    gzip  on;
    limit_zone   one  $binary_remote_addr  10m;
    limit_zone   lz_free $host 16m;

    limit_req_zone  $combined zone=lrz_two:32m rate=30r/m;
    limit_zone lz_one $combined 32m;

    open_log_file_cache  max=500  inactive=30m  valid=10m  min_uses=1;

    recursive_error_pages on;
    proxy_intercept_errors on;

    proxy_cache_path /mnt/data/nginx.pages_cache/bla1 levels=1:2
keys_zone=cache-bla1:10m inactive=90d max_size=400g;
    proxy_cache_path /mnt/data/nginx.pages_cache/bla2 levels=1:2
keys_zone=cache-bla2:10m inactive=90d max_size=150g;
    proxy_cache_path /mnt/data/nginx.pages_cache/bla3 levels=1:2
keys_zone=cache-bla3:10m inactive=30d max_size=10g;

    geoip_country /usr/local/share/GeoIP/GeoIP.dat;

    <SKIPPED>
}

Сейчас сие лечится полуночным рестартом nginx по крону, но это потеря
запросов на время рестарта.
Есть предложения/домыслы, как найти причину? Хотя бы workaround?

PS: Натягивать на 0.8.54 патчи Максима (Maxim Dounin) не стал, т.к. судя по
changlelog'у они уже приняты в 0.8.53. Или не все?

-- 
С Уважением,
Костенко Евгений

моб: +7(928)2961142
icq: 101241013
jabber: nobody.mail at gmail.com
skype: nobody.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20110203/f3c95c48/attachment.html>


Подробная информация о списке рассылки nginx-ru