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

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

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

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 ГБ и несколько виртуальных сетевых интерфейсов для обработки одновременных соединений 1MM с некоторой настройкой ядра с использованием sysctl. Во время моих тестов при работе с более чем 1MM и отправкой полезной нагрузки размером около 700B серверу требовалось около 10 секунд, чтобы обновить около 1,2MM одновременных клиентов. Затем нужно было увеличить пропускную способность сети за счет подключения дополнительных сетевых адаптеров и отказа от виртуальных сетевых адаптеров. Возможно достичь связи в псевдо-режиме, близком к реальному времени, с более чем 1,2 млн клиентов, с учетом полезной нагрузки, пропускной способности и разумного времени для обновления всех клиентов.

Удачной настройки!

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

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

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

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

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

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

13 # define DEFAULT_CONNECTIONS 512

Давайте возьмем прагматический подход.

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

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

worker_process

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

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

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

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

Этот сложный.

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

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

Вообще говоря, 1 рабочий процесс всегда безопасен.

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

worker_connections

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

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

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

1k worker_connections

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

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

10k worker_connections

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

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

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

Более 10 КБ

10 КБ - это просто и приятно.

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

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

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

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

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

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

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

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