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

Maxim Dounin mdounin на mdounin.ru
Чт Июн 25 16:08:30 UTC 2020


Hello!

On Thu, Jun 25, 2020 at 05:59:33PM +0300, Gena Makhomed wrote:

> 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 шлет файловые дескрипторы
> из мастера в воркеры только в процессе старта и в процессе релоада,
> то есть, эта ошибка
> 
> sendmsg() failed (109: Too many references: cannot splice)
> 
> не должна повториться в дальнейшем, в процессе работы nginx
> под большой нагрузкой, если в процессе запуска и релоада
> подобных ошибок не было.

Да, какие-либо дескрипторы отсылаются (сейчас) только при создании 
новых рабочих процессов.  В дальнейшем, вероятно, будут отсылаться 
ещё и дескрипторы лог-файлов при их переоткрытии.

> P.S.
> 
> На том сервере процессор AMD EPYC 7502P 32-Core Processor
> так что 32 worker-процесса nginx вполне должно быть достаточно,
> по количеству физических ядер и без правки LimitNOFILE для мастера.
> 
> Но при настройке worker_processes auto; глюки есть уже сейчас,
> потому что в auto считаются виртуальные а не физические ядра.
> 
> Со стороны nginx этот глюк никак нельзя обойти/устранить,
> чтобы все работало при настройке worker_processes auto;
> без ручной правки LimitNOFILE через systemctl edit nginx
> на сервере с процессором AMD EPYC 7502P 32-Core Processor?

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

Но вообще настройка "worker_processes auto;" не является 
настройкой по умолчанию именно потому, что на серверах с большим 
количеством ядер/потоков может потребовать большого количества 
различных ресурсов, и применять её без соответствующего тюнинга 
системных ограничений - не очень хорошая идея.

-- 
Maxim Dounin
http://mdounin.ru/


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