Nginx worker_connections"встановлює максимальну кількість одночасних з'єднань, які можуть бути відкриті робочим процесом. Це число включає всі з'єднання (наприклад, з'єднання з проксі-серверами, серед інших), не тільки з'єднання з клієнтами. Інше врахування полягає в тому, що фактична кількість одночасних з'єднань не може перевищувати поточний ліміт максимальної кількості відкритих файлів ". У мене є кілька запитів навколо цього:

1. Яким має бути оптимальне або рекомендоване значення для цього?
2. Які недоліки використання великої кількості підключень працівників?

Візьмемо прагматичний підхід.

Усі ці межі - це речі, які були жорстко кодовані і розроблені в минулому столітті, коли обладнання було повільним і дорогим. Зараз ми в 2016 році, середній тостер зі стінами-мартами може обробити більше запитів, ніж значення за замовчуванням.

Налаштування за замовчуванням насправді небезпечні. Маючи сотні користувачів на веб-сайті, це нічого вражаючого.

робочий_процес

Пов'язане налаштування, давайте пояснимо це, поки ми розбираємося з цією темою.

nginx як балансир навантаження:

• 1 працівник для балансування навантаження HTTP.
• 1 працівник на ядро ​​для збалансування навантаження HTTPS.

nginx як веб-сервери:

Цей хитрий.

Деякі програми / фреймворки / середнє програмне забезпечення (наприклад, php-fpm) виконуються поза nginx. У такому випадку достатньо 1 працівника nginx, оскільки це, як правило, зовнішня програма, яка робить важку обробку та поїдає ресурси.

Крім того, деякі програми / фреймворки / проміжне програмне забезпечення можуть обробляти лише один запит за один раз, і перевантажувати їх потрібно заново.

Взагалі кажучи, 1 працівник - це завжди безпечна ставка.

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

робочі_з'єднання

Загальна кількість з'єднань становить worker_process * worker_connections. Половина в режимі балансування навантаження.

Тепер ми доходимо до тостерної частини. Існує багато серйозно занижених системних обмежень:

• ulimits - це 1 ккс максимум відкритих файлів за один процес на Linux (1 к. м., 4 кп. на деяких дистрибутивах)
• обмеження системи приблизно такі ж, як і ulimits.
• За замовчуванням nginx - 512 підключень на одного працівника.
• Можливо, буде більше: SELinux, sysctl, supervisord (кожен дистрибутив + версія дещо відрізняється)

1 к. Підключень

Безпечним замовчуванням є розміщення 1k скрізь.

Це досить високо, щоб було більше, ніж коли-небудь зустрічаються внутрішні та невідомі сайти. Він досить низький, щоб не потрапляти на будь-які інші обмеження системи.

10 к. Підключень

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

Мінімально прийнятний для виробництва - 10 к. Необхідно збільшити обмеження, пов'язані з системою, щоб дозволити це.

Не існує такого поняття, як занадто високий ліміт (ліміт просто не має ефекту, якщо немає користувачів). Однак занадто низький ліміт - це дуже реальна річ, що призводить до відхилених користувачів та мертвого сайту.

Більше 10 к

10k приємно і легко.

Ми можемо встановити довільні обмеження в 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, ви можете докласти більше тиску в оперативній пам'яті, якщо у вас є процесор і достатньо оброблювачів файлів.

FYI можна отримати достатню кількість обчислювальних ресурсів, мати один сервер з приблизно 32 ГБ оперативної пам’яті та кілька віртуальних мережевих інтерфейсів для одночасного з'єднання 1ММ з деякою настройкою ядра за допомогою sysctl. Під час моїх тестів при роботі з більш ніж 1 ММ та надсиланням корисного навантаження близько 700 біт сервер знадобився близько 10 секунд, щоб оновити близько 1,2 ММ одночасних клієнтів. Далі було збільшити пропускну здатність мережі за допомогою приєднання додаткових NIC та виривання віртуальних мікросхем. Можливо досягти псевдо близького спілкування в реальному часі з більш ніж 1,2-мільйонними клієнтами, враховуючи корисну навантаження, пропускну здатність та розумний час для оновлення всіх клієнтів.

Щаслива настройка!

Відповідне розмір може бути виявлено за допомогою тестування, оскільки воно є змінним на основі типу трафіку, яким обробляється Nginx.

Теоретично, nginx може обробляти: максимум клієнтів = робочий_процес * робочий_з'єднання (* = множити) і робочий_процес = кількість процесорів

Щоб дізнатися процесори, використовуйте: grep-процесор / proc / cpuinfo | wc -l

Встановлення нижчих лімітів може бути корисним, коли ви можете бути обмеженими ресурсами. Деякі з’єднання, наприклад, постійні зв’язки (не тільки з клієнтами, але і з верхніми серверами також), ефективно витрачають ваші ресурси (навіть якщо nginx дуже ефективний, що це є), і не потрібен для правильна робота сервера загального призначення, тобто їх можна безпечно скинути, щоб зробити більше ресурсів доступними для решти операції.

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

Яке рекомендоване значення? Це за замовчуванням.

Значення за замовчуванням зафіксовані в документації:

За замовчуванням: worker_connections 512;

І може бути підтверджено на рівні вихідного кодуevent/ngx_event.c також

13 # визначте DEFAULT_CONNECTIONS 512

Відповідь Марселя справді потрібно підтримати! Якщо для обмежувачів встановлено значення за замовчуванням близько 1k, max_connections слід встановити приблизно однакове значення, інакше немає користі для встановлення max_connections в 10k.

Ви отримаєте запит на чергу та сокети, закриті на nginx, якщо "ваші робочі з'єднання не можуть бути більшими за будь-які з них, або клієнтські з'єднання будуть стояти в черзі до net.core.netdev_max_backlog - загального розміру черги TCP".

Один процес може відкриватися так само, як і з'єднання, наскільки це дозволяє. num_workers * max_connections - це формула, але зовнішні максимуми навантаження / проксі-максимуми та обмеження повинні враховуватися для розумних значень. Встановлення max_connection на дійсно високе значення може призвести до виникнення негативного ефекту, оскільки обмеження будуть обмежуючим фактором.