Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
Hello! On Thu, Jun 25, 2020 at 04:04:55PM -0400, edo1 wrote: > BTW, а как работает worker_cpu_affinity auto если воркеров меньше, чем > ядер? Воркеры будут привязаны к первым ядрам, лишние ядра - останутся свободными. Если нужно, чтобы остались свободными другие ядра - это можно сделать с помощью дополнительной маски. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
BTW, а как работает worker_cpu_affinity auto если воркеров меньше, чем ядер? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288449,288467#msg-288467 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: limit rate и высокие скорости
> https://trac.nginx.org/nginx/ticket/1678#comment:1 читал > Подкрутить можно размеры буферов и/или включить sendfile, размеры крутил (без них было сильно хуже), sendfile тоже пробовал включать (точнее отключать aio). с "output_buffers 2 10m" получается около 80Мб/с, но 20Мб на клиента как-то перебор (и опять же это не ровно 100, как в указано через limit_rate) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288429,288466#msg-288466 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ssl_protocols
Hello! On Thu, Jun 25, 2020 at 09:23:35PM +0300, Gena Makhomed wrote: > Максим, а почему такое значение по-умолчанию у директивы ssl_protocols? > > В частности, протокол TLSv1.3 выключен, но вместо него включены > протоколы TLSv1 и TLSv1.1 - сейчас ведь наоборот рекомендуют делать. > > Даже RFC вышел соответствующий еще в мае 2015 года, > https://tools.ietf.org/html/rfc7525#section-3.1.1 Just in case, по ссылке для TLSv1.0 и TLSv1.1 чётко сказано: "the only exception is when no higher version is available in the negotiation". Именно так nginx и работает по умолчанию. > И такие же настройки рекомендуются https://ssl-config.mozilla.org/ > > Почему бы не сделать ssl_protocols TLSv1.2 TLSv1.3; значением по-умолчанию в > nginx? Тут, на самом деле, два вопроса: 1. А не запретить ли TLSv1.0 и TLSv1.1 по умолчанию. Мне это пока кажется плохой идеей, ибо клиентов, не умеющих TLSv1.2 всё ещё много. Подробный ответ тут: https://trac.nginx.org/nginx/ticket/1911#comment:2 2. А не разрешить ли TLSv1.3 по умолчанию. Сейчас для этого как минимум один блокер - в TLSv1.3 не настраиваются шифры и в результате сломаются конфиги с "ssl_ciphers aNULL;", подробнее тут: http://mailman.nginx.org/pipermail/nginx/2018-November/057194.html -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
ssl_protocols
Максим, а почему такое значение по-умолчанию у директивы ssl_protocols? В частности, протокол TLSv1.3 выключен, но вместо него включены протоколы TLSv1 и TLSv1.1 - сейчас ведь наоборот рекомендуют делать. Даже RFC вышел соответствующий еще в мае 2015 года, https://tools.ietf.org/html/rfc7525#section-3.1.1 И такие же настройки рекомендуются https://ssl-config.mozilla.org/ Почему бы не сделать ssl_protocols TLSv1.2 TLSv1.3; значением по-умолчанию в nginx? -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
Hello! On Thu, Jun 25, 2020 at 08:13:06PM +0500, Илья Шипицин wrote: > чт, 25 июн. 2020 г. в 19:59, Gena Makhomed : > > > On 25.06.2020 17:23, Maxim Dounin wrote: > > > > >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на > > >>> количество файлов. > > >> > > >>> посмотрите в /proc//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
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
Hello! On Thu, Jun 25, 2020 at 05:59:33PM +0300, Gena Makhomed wrote: > On 25.06.2020 17:23, Maxim Dounin wrote: > > > > > в этом месте вы думаете, что воркер сам себе проставил такой лимит на > > > > количество файлов. > > > > > > > посмотрите в /proc//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
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
On 25.06.2020 18:13, Илья Шипицин wrote: интересно посмотреть, что у вас в /proc//fd , это файлы открытые мастером При worker_processes 32: # cat /proc/909/cmdline nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf # ls -l /proc/909/fd/ всего там 72 дескриптора, 0 -> /dev/null 1 -> /dev/null 2 -> /var/log/nginx/error.log 3 -> socket:[1142765] 4 -> /var/log/nginx/error.log 5 -> /var/log/nginx/access.log 6 -> socket:[1148452] ... остальные указывают на сокеты. (мастер слушает на 80 и 443 порту) P.S. Но это сервер с 0-й нагрузкой, там ничего не пишется и не читается, он сейчас находится как раз в процессе настройки. P.P.S. Там еще один очень неприятный глюк с systemd проявился, не имеющий отношения к nginx: https://lists.freedesktop.org/archives/systemd-devel/2020-June/044763.html -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
чт, 25 июн. 2020 г. в 19:59, Gena Makhomed : > On 25.06.2020 17:23, Maxim Dounin wrote: > > >>> в этом месте вы думаете, что воркер сам себе проставил такой лимит на > >>> количество файлов. > >> > >>> посмотрите в /proc//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 шлет файловые дескрипторы > из мастера в воркеры только в процессе старта и в процессе релоада, > то есть, эта ошибка > насколько я помню, в принципе разная работа с дескрипторами может быть, например, если логи открыты в буферизированном варианте. (если небуферизированные, то воркер открывает, записывает и закрывает. если буферизированные, то дескриптор хранится в мастере) интересно посмотреть, что у вас в /proc//fd , это файлы открытые мастером > > 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? > > -- > Best regards, > Gena > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
On 25.06.2020 17:23, Maxim Dounin wrote: в этом месте вы думаете, что воркер сам себе проставил такой лимит на количество файлов. посмотрите в /proc//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? -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
Hello! On Thu, Jun 25, 2020 at 04:05:19PM +0300, Gena Makhomed wrote: > On 25.06.2020 14:48, Илья Шипицин wrote: > > > > /etc/systemd/nspawn/1.nspawn > > > > > > [Exec] > > > LimitNOFILE=infinity > > > > /etc/nginx/nginx.conf > > > > > > worker_rlimit_nofile 262144; > > > в этом месте вы думаете, что воркер сам себе проставил такой лимит на > > количество файлов. > > > посмотрите в /proc//limits , действительно ли там значения, которые вы > > ожидаете или нет > > у нас было, что systemd применял свои лимиты поверх > > # cat /proc/205/cmdline > nginx: worker process > > # grep "Max open files" /proc/205/limits > Max open files 262144 262144 files А у master-процесса что? Если я правильно понимаю код ядра линукса, ETOOMANYREFS означает, что количество одновременно отправляемых файловых дескрипторов превышает лимит на количество дескрипторов в отправляющем процессе, в данном случае - в мастере, ибо никто больше файловые дескрипторы с помощью sendmsg() не шлёт. Собственно, pid процесса можно смотреть сразу в сообщении об ошибке. Ну и отвечая на исходный вопрос про "насколько критична эта ошибка": приведённая ошибка как минимум означает, что система общения между мастером и рабочими процессами больше не работает. То есть отвечать на запросы nginx будет, а скажем reload сделать - уже нормально не сможет. То есть приблизительно как и со всеми ошибками уровня alert: "что-то развалилось и непредсказуемо глючит, сделайте что-нибудь". -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
On 25.06.2020 14:48, Илья Шипицин wrote: /etc/systemd/nspawn/1.nspawn [Exec] LimitNOFILE=infinity /etc/nginx/nginx.conf worker_rlimit_nofile 262144; в этом месте вы думаете, что воркер сам себе проставил такой лимит на количество файлов. посмотрите в /proc//limits , действительно ли там значения, которые вы ожидаете или нет у нас было, что systemd применял свои лимиты поверх # cat /proc/205/cmdline nginx: worker process # grep "Max open files" /proc/205/limits Max open files 262144 262144 files -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
чт, 25 июн. 2020 г. в 16:34, Gena Makhomed :
> Здравствуйте, All!
>
> CentOS 8.2, nginx 1.19.0 из официального репозитория.
>
> Когда запускаю nginx внутри systemd-nspawn контейнера -
> в error.log видно большое количество сообщений про ошибку:
>
> [alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
>
> Подозреваю, что nginx в контейнере не хватает каких-то лимитов,
> только не понятно каких именно.
>
> При worker_processes 64; ошибка появляется в логах,
> при worker_processes 32; ошибки в логах больше нет.
>
> Каким образом можно сделать так, чтобы nginx работал в контейнере
> systemd-nspawn без ошибок с директивой worker_processes 64; в конфиге?
>
> Насколько критична эта ошибка, и может ли она появиться в логах
> при worker_processes 32; в случае высокой нагрузки на nginx?
>
> Процессор на этом сервере: AMD EPYC 7502P 32-Core Processor
> 32 физических ядра, 64 виртуальных ядра (Simultaneous MultiThreading).
>
> Конфиг:
>
> /etc/systemd/nspawn/1.nspawn
>
> [Exec]
> ResolvConf=copy-host
> LimitNOFILE=infinity
> LimitNICE=40
>
> [Network]
> Bridge=venet0
>
> /etc/nginx/nginx.conf
>
> worker_processes 64;
> worker_priority -10;
> worker_rlimit_core 512M;
> worker_rlimit_nofile 262144;
>
в этом месте вы думаете, что воркер сам себе проставил такой лимит на
количество файлов.
посмотрите в /proc//limits , действительно ли там значения, которые вы
ожидаете или нет
у нас было, что systemd применял свои лимиты поверх
> worker_shutdown_timeout 60s;
> working_directory /var/log/nginx;
>
> error_log /var/log/nginx/error.log warn;
>
> events {
> worker_connections 262144;
> use epoll;
> }
>
> http {
> # ...
> }
>
> --
> Best regards,
> Gena
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
[alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
Здравствуйте, All!
CentOS 8.2, nginx 1.19.0 из официального репозитория.
Когда запускаю nginx внутри systemd-nspawn контейнера -
в error.log видно большое количество сообщений про ошибку:
[alert] 269#269: sendmsg() failed (109: Too many references: cannot splice)
Подозреваю, что nginx в контейнере не хватает каких-то лимитов,
только не понятно каких именно.
При worker_processes 64; ошибка появляется в логах,
при worker_processes 32; ошибки в логах больше нет.
Каким образом можно сделать так, чтобы nginx работал в контейнере
systemd-nspawn без ошибок с директивой worker_processes 64; в конфиге?
Насколько критична эта ошибка, и может ли она появиться в логах
при worker_processes 32; в случае высокой нагрузки на nginx?
Процессор на этом сервере: AMD EPYC 7502P 32-Core Processor
32 физических ядра, 64 виртуальных ядра (Simultaneous MultiThreading).
Конфиг:
/etc/systemd/nspawn/1.nspawn
[Exec]
ResolvConf=copy-host
LimitNOFILE=infinity
LimitNICE=40
[Network]
Bridge=venet0
/etc/nginx/nginx.conf
worker_processes 64;
worker_priority -10;
worker_rlimit_core 512M;
worker_rlimit_nofile 262144;
worker_shutdown_timeout 60s;
working_directory /var/log/nginx;
error_log /var/log/nginx/error.log warn;
events {
worker_connections 262144;
use epoll;
}
http {
# ...
}
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
