3 votos

El tiempo de respuesta del proxy Nginx es muy lento

Recientemente hemos añadido nginx delante de varnish para la descarga de ssl. Estábamos a punto de reescribir todas nuestras peticiones http a https. Pero entonces nos dimos cuenta de que había un aumento significativo en el tiempo de respuesta incluso para las llamadas http cuando es servido por nginx. Mientras que la misma solicitud servida por varnish sin nginx el tiempo de respuesta era mucho más rápido.

He ajustado los buffers del proxy (2048 4k) para que la respuesta no se almacene en un archivo y también he desactivado el buffering del proxy. Pero ambos enfoques no ayudaron. Así que cloné el servidor nginx (máquina virtual) y emití la misma solicitud contra el clonado. El tiempo de respuesta estaba a la par con varnish.

Parece que cuando hay carga en nginx (alrededor de 700 peticiones/seg) entonces el tiempo de respuesta parece aumentar.

¿Puede alguien decirme si me estoy perdiendo algo que es obvio?

Esta es mi configuración de nginx

#nginx.conf
worker_processes auto;

worker_rlimit_nofile 90000;

pid        /var/run/nginx.pid;

error_log /var/log/nginx/error.log error;

events {

    worker_connections 40000;

    multi_accept on;

    use epoll;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    client_max_body_size 20M;
    client_body_buffer_size 128k;
    server_tokens off;
    keepalive_requests 1000;
    reset_timedout_connection on;

    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    ##
    # SSL common settings
    ##
    include /etc/nginx/include.d/ssl-common;

    ##
    # Logging Settings
    ##

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

    log_format detailed '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" $request_length $request_time '
                '$upstream_response_length $upstream_response_time '
                '$upstream_status';

    log_format upstreamlog '[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $status / upstream $upstream_status $request upstream_response_time $upstream_response_time msec $msec request_time $request_time body: $request_body';

    log_format timed_combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$upstream_connect_time $upstream_header_time '
'$request_time $upstream_response_time $pipe';

    access_log off;

    ##
    # Gzip Settings
    ##

    gzip on;
    gzip_disable "msie6";

    #Proxy config

    proxy_buffering on;
    proxy_buffers 56 4k;
    proxy_busy_buffers_size 8k;

    proxy_set_header Host $host;
    proxy_http_version 1.1;
    proxy_set_header Connection ""; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

#For a specific request I've increased the proxy buffer size
proxy_buffers 2048 4k;
proxy_buffer_size 4k;
proxy_busy_buffers_size 8k;

#Upstream setting
keepalive 2000;

Incluso he optimizado la configuración de tcp en sysctl.config y eso tampoco ayuda. Aquí está mi sysctl.config

#sysctl.config

fs.file-max = 100000
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 400000
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_max_syn_backlog = 65536
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
vm.min_free_kbytes = 65536

Aquí está el gráfico para Disk IO. Nota: Las estadísticas de conexión Tcp las añadí hace poco, así que no hay mucha información.

Nginx_status - gráfico que muestra las peticiones y las conexiones

0 votos

No son 700 req/s SSL. Son las conexiones activas abiertas. He comprobado dos veces el número de peticiones, es alrededor de 100 peticiones/segundo y su incluir tanto http y https.

0 votos

¿Sigue apareciendo el problema cuando la conexión ascendente TCP permanece abierta (keepalive ascendente, cabecera de conexión proxy vacía y versión de protocolo 1.1)?

2voto

Nick Puntos 74

¿Hay algo en el registro de errores?

Recientemente tuve un problema en el que el sistema se quedaba sin manejadores de archivos porque estaba almacenando en búfer cada solicitud y los keepalives de aguas arriba no estaban habilitados. Sin embargo, no habría pensado que tendrías estos problemas con esa configuración.

No sé cómo es tu hardware pero 700 req/s de SSL por segundo es bastante pesado, ¿hay algún iowait? ¿Cpu al máximo? "keepalive_timeout 65" parece alto para ese nivel de tráfico también, usted podría estar corriendo de conexiones tcp. He encontrado que los mejores resultados para ~300 req/s son muy cortos, alrededor de 1-3 segundos, pero eso dependerá de tu carga.

0 votos

Nada en particular en el registro de errores. El servidor Nginx tiene 8GB de ram y 8 núcleos de cpu. El uso de la CPU es de alrededor del 2% y 5,8 gb de ram está libre. Así que la máquina tiene suficiente potencia de fuego. No son 700 req/s SSL. Son las conexiones activas abiertas. He comprobado dos veces el número de peticiones, es de unas 100 peticiones/segundo e incluye tanto http como https. En cuanto a la espera de IO, tengo algunas capturas de pantalla para esas métricas. Lo añadiré a mi pregunta original.

0 votos

Hmm. Lo único que puedo ver que es radicalmente diferente a mis estadísticas es la relación entre las estadísticas TCP y las estadísticas nginx. Por ejemplo en uno de mis nodos el máximo de clientes en espera es actualmente 212 y el máximo de conexiones TCP abiertas es 276. Usted tiene la situación opuesta con 70 conexiones TCP y ~ 200 clientes en espera. Yo me concentraría en la conexión ascendente, creo. ¿Está el barniz de subida en la misma máquina? Si es así, ¿está escuchando en el loopback? Si no es así, ¿está siendo retrasado por un firewall? Si está en un servidor separado, ¿hay alguna latencia inesperada? Ese tipo de cosas

0 votos

Para comparar tengo "proxy_buffers 64 32k" (sirviendo imágenes grandes), "keepalive_timeout 3s", y gzip está desactivado (el upstream lo maneja).

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X