Ошибка «768 worker_connections are not enough»

Поддержка Самостоятельное хостинг
1

Привет!

После сегодняшнего восстановления мы наблюдаем большое количество ошибок сервера. Похоже, это проблема подключения в nginx; в файле nginx/error.log я иногда вижу всплески сообщений вида 768 worker_connections are not enough, например:

2021/06/02 10:42:21 [alert] 1143#1143: *28468 1768 worker_connections are not enough while connecting to upstream, client: (IP removed), server: _, request: "POST /message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/convert-multiple-objects-to-single-mesh-with-vertex-grouping/489173/2"

Есть ли какие-то идеи, как это исправить? У нас достаточно свободных ресурсов процессора и памяти — можем ли мы увеличить количество «worker connections»?"}

2

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

## Любые пользовательские команды для запуска после сборки
run:
  - exec: echo "Начало пользовательских команд"

  - replace:
      filename: "/etc/nginx/letsencrypt.conf"
      from: "worker_connections 768" 
      to: "worker_connections 1768"
3

Интересно, что это произошло после пересборки. Не выполняли ли вы недавно какие-либо массовые действия? Проверьте логи Sidekiq и посмотрите, нет ли там большого количества задач.

4

Недавно я действительно выполнял массовые действия, так как мы перешли на предпросмотр миниатюр TC, но в очереди Sidekiq ничего нет, так что я точно могу это исключить.

5

Мы обновили версию nginx два дня назад, поэтому давайте будем следить за этим. У вас на сайте бывает более 500 одновременных посетителей?

Также весь ваш сайт находится за Cloudflare, поэтому из-за этого ситуация может отличаться.

6

Я не знаю — возможно? Есть ли идеи, как это проверить?

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

7

Ха-ха, обычно для получения такой информации используют Google Analytics или что-то подобное. В панели управления Discourse есть данные о ежедневных просмотрах страниц и посещениях пользователей, которые тоже можно использовать для этой цели.

Это не так, весь ваш сайт обслуживается через Cloudflare:

curl -I https://blenderartists.org/                                                                                                                                         
HTTP/2 200 
cf-cache-status: DYNAMIC
cf-request-id: 0a6ef945b3000002fe272b2000000001
server: cloudflare
cf-ray: 6591c4b5ec5902fe-MIA
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400

Однако это может быть совершенно не связано с проблемой, так как ваш nginx жалуется на соединения с upstream, а не с downstream, что означает нехватку соединений между nginx ⟷ unicorn.

Поскольку мы поддерживаем открытое соединение для каждого посетителя благодаря message_bus (сервису живых обновлений), это ожидаемо, если ваш сайт достаточно популярен.

Увеличение параметров worker_processes и worker_connections безопасно и, похоже, имеет смысл в вашем случае. По умолчанию worker_processes устанавливается равным количеству ядер вашего процессора. Сколько ядер процессора у вас есть?

8

Верно :slight_smile: Мы отказались от этого очень давно… У нас около 250 тыс. просмотров страниц в день (включая ботов), так что 500 не кажется чем-то необычным. Посещения пользователей отслеживают только авторизованные визиты, верно?

Правильно — нам действительно приходится направлять наши запросы через CF, но мы не позволяем им затрагивать наш JavaScript и т.д.

У нас 12 ядер и 64 ГБ оперативной памяти. Типичная нагрузка составляет около 2, и мы используем 50% нашей оперативной памяти.

9

Черт, это так странно!

Формула для количества подключений: worker_processes * worker_connections, то есть 12 * 768, что должно дать (клик-клак) 9216. Но в ваших логах указано 1768…

Попробуйте добавить это в ваш app.yml:

## Любые пользовательские команды для запуска после сборки
run:
  - exec: echo "Начало пользовательских команд"

  - replace:
      filename: "/etc/nginx/nginx.conf"
      from: "worker_connections 768" 
      to: "worker_connections 2000"
  - replace:
      filename: "/etc/nginx/nginx.conf"
      from: "worker_processes auto" 
      to: "worker_processes 10"

Обратите внимание, что ваш блок в посте 2 действует не на тот файл!

10

:facepalm: Я вставил не тот код — сначала попробовал шаблон letsencrypt, но в итоге изменил nginx.conf на 1768 рабочих соединений.

Попробую ваши значения — вернусь с отчетом о результатах.

11

К сожалению, они всё ещё появляются:

2021/06/02 17:40:03 [alert] 2102#2102: *262491 2000 worker_connections недостаточно для подключения к upstream, client: <ip removed>, server: _, request: "POST /message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/weight-paint-not-painting/551282"
12

Я увеличил worker_connections до 4000, и пока всё выглядит хорошо :crossed_fingers:

13

Теперь переопределить стало проще:

14

Круто! Значит, мы делаем что-то вроде

params:
  nginx_worker_connections: 4000

в app.yml/web_only.yml?

15

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

16

На одном из сайтов я также увеличил количество рабочих процессов до 2X числа CPU. Стоит ли мне убрать это тоже?