Hello!

On Thu, Jun 25, 2020 at 08:13:06PM +0500, Илья Шипицин wrote:

> чт, 25 июн. 2020 г. в 19:59, Gena Makhomed <gmm@csdoc.com>:
>
> > On 25.06.2020 17:23, Maxim Dounin wrote:
> >
> > >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на
> > >>> количество файлов.
> > >>
> > >>> посмотрите в /proc/<pid>/limits , действительно ли там значения,
> > которые вы
> > >>> ожидаете или нет
> > >>> у нас было, что systemd применял свои лимиты поверх
> > >>
> > >> # cat /proc/205/cmdline
> > >> nginx: worker process
> > >>
> > >> # grep "Max open files" /proc/205/limits
> > >> Max open files 262144 262144 files
> > >
> > > А у master-процесса что?
> >
> > # cat /proc/182/cmdline
> > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
> >
> > # grep "Max open files" /proc/182/limits
> > Max open files 1024 262144 files
> >
> > С помощью директив конфига nginx, насколько я понимаю,
> > 1024 нельзя увеличить до какого-нибудь большего значения.
> >
> > с помощью systemctl edit nginx сделал
> >
> > /etc/systemd/system/nginx.service.d/override.conf
> >
> > [Service]
> > LimitNOFILE=infinity
> >
> > так что теперь, после перезапуска у мастера такие параметры:
> >
> > # cat /proc/690/cmdline
> > nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
> >
> > # grep "Max open files" /proc/690/limits
> > Max open files 262144 262144 files
> >
> > И nginx теперь нормально запускается даже при worker_processes 128;
> >
> > Спасибо!
> >
> > > Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает,
> > > что количество одновременно отправляемых файловых дескрипторов
> > > превышает лимит на количество дескрипторов в отправляющем
> > > процессе, в данном случае - в мастере, ибо никто больше файловые
> > > дескрипторы с помощью sendmsg() не шлёт.
> >
> > > Ну и отвечая на исходный вопрос про "насколько критична эта
> > > ошибка": приведённая ошибка как минимум означает, что система
> > > общения между мастером и рабочими процессами больше не работает.
> > > То есть отвечать на запросы nginx будет, а скажем reload сделать -
> > > уже нормально не сможет. То есть приблизительно как и со всеми
> > > ошибками уровня alert: "что-то развалилось и непредсказуемо
> > > глючит, сделайте что-нибудь".
> >
> > Если я правильно понял Ваш ответ - nginx шлет файловые дескрипторы
> > из мастера в воркеры только в процессе старта и в процессе релоада,
> > то есть, эта ошибка
> >
>
> насколько я помню, в принципе разная работа с дескрипторами может быть,
> например, если логи открыты в буферизированном варианте.

В данном случае речь не про открытые файловые дескрипторы, а про
дескрипторы, одновременно отправляемые через unix-сокеты с помощью
системного вызова sendmsg(). Там тоже применяется NOFILE-лимит,
но счётчик при этом совершенно отдельный.

> (если небуферизированные, то воркер открывает, записывает и закрывает. если
> буферизированные, то дескриптор хранится в мастере)

Нет. Паттерн "воркер открывает, записывает и закрывает"
применяется только для access-логов с переменными в имени. В
остальных случаях - то есть когда переменных в имени лога нет -
лог-файл открывается мастером и остаётся открытым всегда, от
настроек буферизации это не зависит.

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