Tenemos tres servidores dedicados en nuestra empresa, uno ejecuta Nginx y actúa como servidor web (php), otro maneja MySQL y Memcached y el otro se utiliza para servir archivos estáticos: css, js e imágenes.
Todos los servidores muestran un excelente rendimiento en New Relic, especialmente el servidor de archivos estáticos:
- CPU continuamente por debajo del 10%
- La E/S de red se recibe muy baja, la transmisión es de alrededor de 10 Mb/s como máximo, pero el servidor MySQL tiene las mismas especificaciones y habitualmente alcanza un máximo de 20 mb/s, por lo que dudo que esto sea un problema.
- Carga media inferior a 0,5
El problema es que, en las horas pico, aparentemente las imágenes (que pueden tener un tamaño de 100 kb a 200 kb) tardan mucho en cargarse para algunos usuarios (muchos segundos, incluso a veces hasta un minuto, cuando normalmente tomaría solo unos pocos). segundos en el peor de los casos).
¿Alguna idea de lo que podríamos hacer? Lo ideal es que si ni la CPU, ni la RAM ni el ancho de banda han alcanzado ningún tipo de límite, esto no debería suceder.
¿Algún parámetro de configuración clave de Nginx que deberíamos analizar (y probablemente cambiar)?
Respuesta1
Se me ocurren dos posibilidades.
- Su disco ha alcanzado su límite de E/S.
- Has alcanzado el límite de subprocesos de trabajo en nginx. Mira elobrero_*parámetros de configuración del módulo Core yconexiones_trabajadoresdel módulo Eventos para descubrir cómo impulsar esto. El valor predeterminado es un proceso de trabajo único, que tiene un solo subproceso, por lo que si está ejecutando en una plataforma de múltiples CPU, definitivamente debería impulsarlo. Incluso si está en una caja de una sola CPU, se beneficiará al aumentar este número en una máquina que sirve recursos estáticos, ya que estará vinculado a la E/S del disco mucho antes que cualquier otra cosa, y otros subprocesos pueden recibir y procesar más solicitudes mientras el primero está esperando recibir datos del disco.
Respuesta2
Podríamos sentarnos aquí y adivinar dónde está tu cuello de botella todo el día, pero algunos consejos más generales te ayudarán a encontrarlo por tu cuenta mucho antes.
jeffatrackaid escribióesta respuesta ayerque es una versión más sucinta delo que escribí hace bastante tiempo. Sugeriría leerlos primero para ayudar a comprender cómo se realiza la depuración del rendimiento.
En su caso, usaría Firebug primero para determinar qué parte de la solicitud durante las horas pico va lenta. Esto debería descartar el ancho de banda si el ancho de banda no es el verdadero problema. Busque en la sección "Net" de Firebug y observe qué parte de la solicitud cambia entre los tiempos rápidos y los tiempos lentos.
Después de eso, ejecutaría una prueba con las opciones -ty -Ten uno de los trabajadores de nginx durante uno de estos tiempos lentos. El análisis del resultado debería mostrarle exactamente dónde va lento nginx. Es útil escribir la salida de strace en un archivo y luego usar lesso grepen el archivo para identificar llamadas al sistema que tardaron mucho tiempo.
Es posible que le resulte útil la -copción de strace.
Una vez que haya identificado las llamadas lentas al sistema, aún puede ser necesario trabajar para determinar qué parámetro de nginx necesita cambiar, pero debería estar en el camino correcto. Vuelva y haga preguntas más específicas si necesita ayuda con esa parte.
Si resulta ser una llamada al sistema basada en archivos, asegúrese de mirar hacia atrás en el seguimiento hasta encontrar el archivo que estaba esperando. Esa será una gran pista.