☰

El tiempo de respuesta ascendente de Nginx ocasionalmente es muy lento

tag-icon • tag-icon nginx load-balancing
El tiempo de respuesta ascendente de Nginx ocasionalmente es muy lento

Tengo un servidor Ubuntu que maneja mucho tráfico y muchos sitios, ocasionalmente Nginx tarda mucho en responder (20-30 segundos algunas veces, y generalmente la solicitud se agota antes de eso), inicialmente pensé que era porque de picos de tráfico en combinación con Passenger que no lo maneja bien, pero desde entonces reemplacé Passenger con Puma y equilibré la carga del tráfico y todavía está sucediendo.

Nginx Amplify me envía alertas de tipo nginx.upstream.response.timedemasiado alto, como 14 segundos, por ejemplo.

Aquí hay una descripción general de la configuración:

  • El servidor n.° 1 (el que ocasionalmente tiene una respuesta lenta) tiene bloques de servidor Nginx para más de 300 sitios.
  • el servidor se bloquea proxy_passen un bloque de servidor de equilibrador de carga (sites.myapp.com) también en el servidor n.º 1
  • el equilibrador de carga divide el tráfico entre este servidor n.º 1 (peso 1) y el servidor n.º 2 (peso 2) de modo que el doble de tráfico vaya al servidor n.º 2
  • Tanto en el servidor n.° 1 como en el n.° 2 tengo otro bloque de servidor que recibe el tráfico del balanceador de carga y proxy_passlo envía a un socket Unix utilizado por Puma para servir una instancia de mi aplicación.

Puede encontrar las configuraciones relevantes para todo eso a continuación. No sé cómo solucionar este problema, pero me pregunto si quizás haya algunas configuraciones en esos bloques de servidores que puedan mejorarse, como por ejemplo desactivar el almacenamiento en búfer del proxy o cambiar el tamaño del búfer del proxy.

¿Alguna idea de qué podría estar causando esto y cómo localizar el problema? Porque cuando Nginx responde muy lentamente, el tráfico ni siquiera se redirige al servidor 2.

Tenga en cuenta que sé que debo mover todos los bloques de servidor/SSL de los sitios y el equilibrador de carga a un servidor separado para que al menos cuando el servidor 1 esté pasando por esa fase de respuesta lenta, el tráfico aún se transmita al servidor 2, pero ahora mismo. Todo lo que tengo son estos dos servidores.

Ejemplo de configuración del sitio:

server {
  server_name www.somesite.com;

  location / {
    proxy_pass                      https://sites.myapp.com;
    proxy_set_header                X-Real-IP       $remote_addr;
    proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header                Cookie $http_cookie;
    proxy_set_header                WLDOMAIN www.somesite.com;
    proxy_cookie_domain             .myapp.com .somesite.com;
    proxy_pass_request_headers      on;
    rewrite ^/(.*)$ /sites/12345/$1 break;
  }
}

Configuración simplificada del equilibrador de carga:


upstream cluster {
  ip_hash;
  server X.X.X.X:1234 weight=1; #internal ip of server #1
  server Y.Y.Y.Y:1234 weight=2; #internal ip of server #2
}

server {
  server_name sites.myapp.com;
  
  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://cluster;

    proxy_next_upstream error timeout invalid_header http_429 http_500 http_502 http_503 http_504;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    proxy_redirect off;
  }
}

Configuración simplificada ascendente:

upstream puma {
  server unix:///var/www/myapp/shared/sockets/puma.sock;
}

server {
  listen 1234;

  root /var/www/myapp/public;

  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://puma;

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 128;

    proxy_redirect off;
  }

}

Tenga en cuenta que este problema ya estaba ocurriendo cuando la configuración era solo que el servidor de varios sitios bloqueaba proxy_passel tráfico hacia un flujo ascendente en lugar de tener el equilibrador de carga entre ellos y la aplicación servida por Passenger en lugar de Puma.

Por si importa, la aplicación es Ruby on Rails.

Respuesta1

Entonces, después de activar la salida de depuración en Nginx, parece que el problema estaba en el módulo Nchan en el nginx-extraspaquete de Phusion Passenger, ese tiene errores y se bloquea de vez en cuando, una vez que me deshice de Passenger (reemplazado por Puma) y lo reemplacé nginx-extrascon nginxNo he tenido ese problema desde entonces.

información relacionada