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 mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru