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

1. Какое должно быть оптимальное или рекомендуемое значение для этого?
2. Каковы недостатки использования большого количества рабочих соединений?

Давайте прагматичный подход.

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

Настройки по умолчанию на самом деле опасны. Наличие сотен пользователей на сайте не впечатляет.

worker_process

Связанная настройка, давайте объясним это, пока мы находимся на теме.

nginx как балансировщик нагрузки:

• 1 рабочий для балансировки нагрузки HTTP.
• 1 рабочий на ядро ​​для балансировки нагрузки HTTPS.

nginx как веб-серверы:

Этот хитрый.

Некоторые приложения / frameworks / middleware (например, php-fpm) запускаются за пределами nginx. В этом случае достаточно одного работника nginx, потому что обычно внешнее приложение выполняет тяжелую обработку и использует ресурсы.

Кроме того, некоторые приложения / платформы / промежуточное программное обеспечение могут обрабатывать только один запрос за раз, и это приводит к обратным последствиям для их перегрузки.

Вообще говоря, 1 работник всегда безопасная ставка.

В противном случае вы можете поставить одного работника на ядро, если знаете, что делаете. Я бы посчитал этот маршрут оптимизацией и посоветовал бы правильно провести бенчмаркинг и тестирование.

worker_connections

Общее количество подключений составляет worker_process * worker_connections. Половина в режиме балансировки нагрузки.

Теперь мы подходим к тостеру. Есть много серьезно недооцененных системных ограничений:

• Максимальное количество открытых файлов на процесс в Linux составляет 1 КБ (1 КБ, 4 КБ в некоторых дистрибутивах).
• Системные ограничения примерно такие же, как и улимитов.
• По умолчанию nginx составляет 512 соединений на одного работника.
• Там может быть больше: SELinux, sysctl, supervisord (каждая версия distro + немного отличается)

1k worker_connections

Безопасное значение по умолчанию - 1k везде.

Это достаточно высоко, чтобы быть больше, чем большинство внутренних и неизвестных сайтов когда-либо сталкиваются. Это достаточно низко, чтобы не нарушать другие системные ограничения.

10 тыс. Рабочих_соединений

Распространено тысячи клиентов, особенно для публичного сайта. Я перестал считать количество сайтов, которые я видел, из-за низких значений по умолчанию.

Минимально приемлемый для производства 10к. Соответствующие системные ограничения должны быть увеличены, чтобы это было возможно.

Не существует такой вещи, как слишком высокий лимит (лимит просто не действует, если нет пользователей). Однако слишком низкий лимит - это очень реальная вещь, которая приводит к отклонению пользователей и мертвому сайту.

Более 10к

10к это красиво и легко.

Мы могли бы установить произвольные ограничения в 1000kk (это всего лишь предел), но это не имеет особого практического смысла, мы никогда не получаем этот трафик и не можем его взять.

Давайте придерживаться 10k в качестве разумной настройки. Сервисы, которые собираются (и могут сделать) больше, потребуют специальной настройки и сравнительного анализа.

Специальный сценарий: расширенное использование

Иногда мы знаем, что на сервере не так много ресурсов, и мы ожидаем всплески, с которыми мы ничего не можем поделать. Мы скорее откажемся от пользователей, чем попробуем. В этом случае установите разумный лимит соединения и настройте хорошие сообщения об ошибках и обработку.

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

ulimit -a скажет вам, сколько открытых файлов ваша система позволяет процессу использовать.

Кроме того, net.ipv4.ip_local_port_rangeзадает общий диапазон сокетов для включения по IP.

Таким образом, вы worker_connectionsне можете быть больше, чем любой из них, или ваши клиентские подключения будут стоять в очереди до net.core.netdev_max_backlog- общего размера очереди TCP.

Имейте в виду, что если вы используете nginx в качестве обратного прокси-сервера, то для каждого соединения используются два сокета. Возможно, вы захотите немного поиграть с net.ipv4.tcp_fin_timeoutдругими таймаутами ядра, связанными с tcp, чтобы попытаться быстро переключить состояние сокетов. Следует также отметить, что каждый сокет выделяет память из стека памяти TCP, вы также можете установить некоторые ограничения стека памяти TCP, используя sysctl, вы можете увеличить нагрузку на оперативную память, если у вас есть процессор и достаточно обработчиков файлов.

К вашему сведению, возможно, при наличии достаточных вычислительных ресурсов, иметь один сервер с оперативной памятью около 32 ГБ и несколько виртуальных сетевых интерфейсов для обработки одновременных подключений 1 ММ с некоторой настройкой ядра с использованием sysctl. Во время моих тестов при работе с более чем 1 ММ и отправке полезной нагрузки около 700 Байт серверу потребовалось около 10 секунд для обновления около 1,2 ММ одновременных клиентов. Следующим шагом было увеличение пропускной способности сети путем соединения нескольких дополнительных сетевых карт и отключения виртуальных сетевых карт. Можно обеспечить псевдо-связь почти в реальном времени с более чем 1,2-миллионными клиентами, учитывая полезную нагрузку, пропускную способность и разумное время для обновления всех клиентов.

Удачного тюнинга!

Соответствующий размер можно найти в ходе тестирования, поскольку он зависит от типа трафика, который обрабатывает Nginx.

Теоретически, nginx может обрабатывать: максимум клиентов = worker_processes * worker_connections (* = умножить) и worker_processes = количество процессоров

Чтобы узнать процессоры, используйте: grep processor / proc / cpuinfo | туалет

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

Таким образом, более низкий лимит ресурсов будет означать для nginx, что у вас может быть мало физических ресурсов, и те, которые доступны, должны быть выделены для новых соединений, а не для обслуживания холостых соединений с поддержкой активности за счет того, что более новые соединения не могут быть установлены для служить более насущным потребностям.

Какое рекомендуемое значение? Это по умолчанию.

Все значения по умолчанию задокументированы в документации:

По умолчанию: worker_connections 512;

И может быть подтверждено на уровне исходного кодаevent/ngx_event.c тоже

13 # define DEFAULT_CONNECTIONS 512

Ответ Марселя действительно нуждается в голосовании! Если для ulimits установлено значение по умолчанию около 1 КБ, max_connections должно быть установлено на то же значение, в противном случае установка max_connections на 10 КБ не имеет смысла.

Вы получите запрос очереди и сокеты, закрытые на nginx, если «ваши worker_connections не могут быть больше, чем любые из них, или ваши клиентские подключения будут стоять в очереди до net.core.netdev_max_backlog - общий размер очереди TCP».

Один процесс может открыться так же, как и соединение, если позволяют ограничения. num_workers * max_connections - формула, но внешние соединения loadbalancer / proxy max и ограничения должны учитываться для получения разумных значений. Установка max_connection на действительно высокое значение может иметь неприятные последствия, так как ulimits будет ограничивающим фактором.