[alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)

[Maxim Dounin]

Hello!

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

> чт, 25 июн. 2020 г. в 19:59, Gena Makhomed <gmm at 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/