Error '768 worker_connections no son suficientes'

Soporte Instalación
1

¡Hola!

Desde la reconstrucción de hoy, estamos experimentando un alto número de errores del servidor. Parece ser un problema de conexión con nginx; en nginx/error.log a veces veo ráfagas de mensajes como 768 worker_connections are not enough, similar a este:

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"

¿Tienes alguna idea sobre cómo podemos solucionarlo? Tenemos mucha CPU y memoria disponibles; ¿podríamos aumentar el número de ‘worker connections’?

2

Actualización: He aumentado las conexiones de los workers por ahora, pero aún obtengo estos errores (con menos frecuencia y para un mayor número de workers). Me da mucha curiosidad saber si algo ha cambiado recientemente que pueda estar causando esto, o cómo podría rastrearlo mejor.

## Cualquier comando personalizado para ejecutar después de la compilación
run:
  - exec: echo "Inicio de los comandos personalizados"

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

Es interesante que esto haya ocurrido después de una reconstrucción; ¿has realizado recientemente alguna acción masiva? Te sugiero revisar los registros de Sidekiq y ver si también hay una gran cantidad de trabajos allí.

4

Sí, recientemente realicé algunas acciones masivas al cambiar a la vista previa de miniaturas TC, pero no hay nada en mi cola de Sidekiq, así que definitivamente puedo descartar eso.

5

Actualizamos la versión de nginx hace dos días, así que estemos atentos. ¿Tu sitio recibe más de 500 visitantes simultáneos?

Además, como todo tu sitio está detrás de Cloudflare, las cosas podrían comportarse de manera diferente debido a ello.

6

No tengo idea, ¡quizás! ¿Alguna idea sobre cómo puedo verificar eso?

Correcto. Pero he desactivado cualquier aceleración y básicamente solo lo uso para almacenar en caché imágenes y avatares. Nunca ha sido un problema hasta hoy.

7

Jaja, por lo general la gente usa Google Analytics o algo similar para conocer ese tipo de información. El panel de control de Discourse tiene vistas diarias de páginas y visitas de usuarios que también se pueden utilizar para aproximarse a ello.

No es cierto, todo tu sitio se sirve a través de 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

Pero eso puede ser completamente irrelevante, ya que tu nginx se queja de las conexiones upstream en lugar de las downstream, lo que significa que se está quedando sin conexiones entre nginx ⟷ unicorn.

Dado que mantenemos una conexión abierta para cada visitante debido a message_bus (servicio de actualizaciones en vivo), esto es algo esperado si tu sitio es algo popular.

Aumentar worker_processes y worker_connections es seguro y tiene sentido en tu caso. Por defecto, worker_processes se establece igual al número de núcleos de CPU que tienes. ¿Cuántos núcleos de CPU tienes?

8

Verdad :slight_smile: Lo dejamos hace mucho tiempo… Tenemos unas 250k visitas diarias a páginas (incluyendo bots), así que 500 no parece inusual. ¿Las visitas de usuarios solo rastrean las visitas de usuarios conectados, verdad?

Correcto: tenemos que pasar nuestras solicitudes a través de CF, pero no permitimos que toquen nuestro JavaScript, etc.

Tenemos 12 núcleos y 64 GB. La carga típica es de aproximadamente 2, y usamos el 50% de nuestra memoria RAM.

9

¡Vaya, eso es muy extraño!

La fórmula para las conexiones es worker_processes * worker_connections, lo que debería ser 12 * 768, es decir (clic clac) 9216. Pero tus registros indican 1768…

Prueba esto en tu app.yml:

## Cualquier comando personalizado para ejecutar después de la construcción
run:
  - exec: echo "Inicio de comandos personalizados"

  - 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"

Ten en cuenta que tu bloque en la publicación 2 está actuando sobre el archivo incorrecto.

10

:facepalm: Pegué el código incorrecto: primero probé la plantilla de Let’s Encrypt, pero terminé cambiando nginx.conf a 1768 conexiones de workers.

Probaré tus valores; volveré para informar cómo me fue.

11

Sigo recibiendo estos mensajes, me temo:

2021/06/02 17:40:03 [alert] 2102#2102: *262491 2000 worker_connections no son suficientes al conectar con el upstream, cliente: <ip eliminada>, servidor: _, solicitud: "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

He aumentado worker_connections a 4000 y hasta ahora todo va bien :crossed_fingers:

13

Ahora lo hemos hecho más fácil de anular:

14

¡Genial! ¿Entonces haríamos algo como

params:
  nginx_worker_connections: 4000

en app.yml/web_only.yml?

15

Exacto. También aumentamos el valor predeterminado a 4k en el mismo parche, por lo que los administradores querrán evaluar cuidadosamente si todavía necesitan aumentarlo.

16

En un sitio también aumenté las CPU de los procesos de trabajo a 2X. ¿Debería eliminar eso también?