Достаточно делать reload, без потери запросов.
# netstat -an | grep CLOSED | wc -l
3056
делаем reload - цифра та же, делаем restart
#netstat -an | grep CLOSED | wc -l
1
Видимо в моем случае reload не помогает.
BTW, в логах должны быть полезные alert'ы: как минимум при
заверешении рабочего процесса, как максимум - в конкретном
запросе.
индивидуально per-vhosts подобных жалоб в error_log нет.
в глобальном error_log иногда всплывают следующие строчки
2011/02/AA 13:19:09 [alert] 23804#0: open socket #XXX left in connection ZZZ
> PS: Натягивать на 0.8.54 патчи Максима (Maxim Dounin) не стал, т.к. судя по
> changlelog'у они уже приняты в 0.8.53. Или не все?
Не все. Нужны ещё:
http://nginx.org/pipermail/nginx-devel/2010-October/000500.html
http://nginx.org/pipermail/nginx-devel/2010-October/000497.html
К утечке сокетов может приводить отсутствие последнего патча, но
только при использовании aio sendfile и limit_rate.
aio используется только как on, ибо с "aio sendfile" поверх zfs не бегает толком.
а limite_rate в конфигах вообще нигде не используется.
в таких условиях есть смысл накатывать указанные выше патчи?
Кроме того, это могут быть какие-то другие проблемы с aio (e.g.
при использовании aio в кеше). В этом случае надо делать как
описано тут:
http://wiki.nginx.org/Debugging#Socket_leaks
Ну или если gdb пугает - для начала поиграться с включённостью aio
для конкретных location'ов, и посмотреть на результат (i.e.
определить где конкретно течёт).
под фразой "aio в кеше" подразумевается proxy_cache?
за ссылку спасибо, попробую в ближайшее время.
я так понимаю для локализации "проблемы" надо пересобрать с --with-debug и вытащить полный backtrace из core-файла?