On 01.03.2011 0:15, Kirill A. Korinskiy wrote:

> предлагаю более простой и надежный вариант решения этой проблемы:
>
> при старте nginx установить limit on number of open files
> в (40 * 1024) вместо дефолтового для системы значения 1024.
>
> это устранит проблему Too many open files во время service nginx reload,
> при этом для worker-процессов можно будет выставить любой нужный лимит
> с помощью глобальной директивы worker_rlimit_nofile в конфиге nginx.
>
>
> А если кто-то создаст очень много файлов?

если "кто-то" создаст очень много конфигурационных файлов
и выполнит service nginx reload - значит он root и ему это надо.

тем более, что при желании можно даже для master-процесса выставить
лимит в 16384, а для worker-процессов поставить лимит, например, 1024.

> Почему бы, человеку, который
> делает такие вещи не править настройки системы?

править дефолтовые настройки системы для всех процессов -
это самый худший вариант, потому что если какие-то программы
используют select - у них будут проблемы при числе дескрипторов
больше чем 1024.

# man select

NOTES
An fd_set is a fixed size buffer. Executing FD_CLR() or
FD_SET() with a value of fd that is negative or is equal to or larger than
FD_SETSIZE will result in undefined behavior. Moreover, POSIX
requires fd to be a valid file descriptor.

например, http://sourceware.org/bugzilla/show_bug.cgi?id=10352

эта ошибка в GLIBC имеет статус WONTFIX - поэтому
дефолтовые системные настройки для всех процессов трогать нельзя.

> Строить workaround для решения этой проблемы, ИМХО, глупо, когда есть
> вполне нормальные способы настройки этого параметра для системы.

параметр для ./configure - это никакой не workaround, это есть solution.

изменение этого параметра для системы приводит к stack/heap corruption.

--
Best regards,
Gena


_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru