Nginx worker_connections "устанавливает максимальное количество одновременных подключений, которые могут быть открыты рабочим процессом. Это количество включает все подключения (например, подключения с прокси-серверами, среди прочего), а не только подключения с клиентами. Еще одно соображение заключается в том, что фактическое количество одновременных подключений не может превышают текущий лимит на максимальное количество открытых файлов ». У меня есть несколько вопросов по этому поводу:
Возьмем прагматичный подход.
Все эти ограничения были жестко запрограммированы и разработаны в прошлом веке, когда оборудование было медленным и дорогим. Сейчас 2016 год, средний тостер-витрина может обработать больше запросов, чем значения по умолчанию.
Настройки по умолчанию действительно опасны. Сотни пользователей на веб-сайте ничего впечатляющего.
Связанный параметр, давайте объясним его, пока мы говорим по теме.
nginx как балансировщик нагрузки:
nginx в качестве веб-серверов:
Это сложно.
Некоторые приложения / фреймворки / промежуточное ПО (например, php-fpm) выполняются вне nginx. В этом случае достаточно 1 воркера nginx, потому что обычно внешнее приложение выполняет тяжелую обработку и потребляет ресурсы.
Кроме того, некоторые приложения / фреймворки / промежуточное ПО могут обрабатывать только один запрос за раз, и их перегрузка приводит к обратным результатам.
Вообще говоря, 1 рабочий - всегда беспроигрышный вариант.
В противном случае вы можете разместить одного воркера на ядро, если знаете, что делаете. Я бы рассмотрел этот путь как оптимизацию и посоветовал бы провести сравнительный анализ и тестирование.
Общее количество подключений worker_process * worker_connections. Половина в режиме балансировки нагрузки.
Теперь мы подошли к тостеру. Есть много серьезно недооцененных системных ограничений:
Безопасное значение по умолчанию - везде ставить 1k.
Он достаточно высок, чтобы быть больше, чем когда-либо встречается на большинстве внутренних и неизвестных сайтов. Он достаточно низкий, чтобы не достигнуть других системных ограничений.
Очень часто встречаются тысячи клиентов, особенно для общедоступных веб-сайтов. Я перестал подсчитывать количество посещенных мной веб-сайтов, которые перестали работать из-за низких значений по умолчанию.
Минимально приемлемый для производства - 10к. Связанные системные ограничения должны быть увеличены, чтобы разрешить это.
Не существует такого понятия, как слишком высокий лимит (лимит просто не действует, если нет пользователей). Однако слишком низкий лимит - это вполне реальная вещь, которая приводит к отклоненным пользователям и мертвому сайту.
10к - это легко и приятно.
Мы могли бы установить произвольные лимиты в 1000кк (в конце концов, это всего лишь лимит), но это не имеет большого практического смысла, мы никогда не получаем этот трафик и все равно не можем его взять.
Давайте придерживаться 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. Во время моих тестов при работе с более чем 1MM и отправке полезной нагрузки размером около 700B серверу требовалось около 10 секунд, чтобы обновить около 1,2MM одновременных клиентов. Следующим шагом было увеличение пропускной способности сети за счет подключения дополнительных сетевых адаптеров и отказа от виртуальных сетевых адаптеров. Можно достичь связи в псевдо-режиме, близком к реальному, с более чем 1,2 млн клиентов, учитывая полезную нагрузку, пропускную способность и разумное время для обновления всех клиентов.
Удачного тюнинга!
Соответствующий размер можно определить путем тестирования, поскольку он зависит от типа трафика, который обрабатывает Nginx.
Теоретически nginx может обрабатывать: максимальное количество клиентов = worker_processes * worker_connections (* = multiply) и worker_processes = количество процессоров.
Чтобы узнать процессоры, используйте: grep processor / proc / cpuinfo | wc -l
За ответ Марселя действительно нужно проголосовать! Если для 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 будет ограничивающим фактором.
Установка более низких пределов может быть полезна, когда вы ограничены в ресурсах. Некоторые соединения, например, keep-alive соединения (не только с клиентами, но и с вышестоящими серверамитоже), эффективно тратят ваши ресурсы (даже если nginx очень эффективен, а это так), и не требуются для правильной работы универсального сервера, а это означает, что их можно безопасно удалить, чтобы сделать больше ресурсов доступными для остальной части операции.
Таким образом, наличие более низкого предела ресурсов будет указывать для nginx, что у вас может быть мало физических ресурсов, и те, которые доступны, должны быть выделены для новых подключений, а не для обслуживания поддерживающих подключений в режиме ожидания за счет новых подключений, у которых возникают проблемы с установкой служить более насущным потребностям.
Какое рекомендуемое значение? Это по умолчанию.
Все значения по умолчанию задокументированы в документации:
По умолчанию: worker_connections 512;
И может быть подтверждено на уровне исходного кода на event/ngx_event.c, слишком
13 # определить DEFAULT_CONNECTIONS 512