1 votos

El diagnóstico lento/tiempo de salida de la aplicación web

Estoy viendo el promedio de los tiempos de carga de load average: 12.41, 11.94, 11.59 sobre un linux basado en una máquina de servir a una aplicación web. Cuenta con 16 núcleos, por lo que el promedio de carga no es inmanejable alta.

Sin embargo, esta aplicación web con frecuencia se agote el tiempo de espera al intentar conectarse a él en el momento. ¿Qué podría estar causando esto? Esto es un poco de una curva.

El uso de la CPU se cierne alrededor de ~50% de todas las CPUs (según top). Los valores de wa entre 0.0 y 3.0. Sin swap de memoria que se está usando en todo, y hay un montón de libre mem disponible.

iostat muestra %iowait valor de 0.51. Otras estadísticas son:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               4.88         1.02      2136.25   12365497 25895371840
sdb               0.00         0.00         0.00       9456          0
sdc               0.95         0.00       452.44       4781 5484405440

Escribe/segundo son de alta - esto es una escritura/aplicación pesada. iotop muestra opina que viene de la pgbouncer proceso (postgresql concentrador de conexión), de async tarea de colas y de nginx procesos de trabajo (probablemente escrito para el registro de acceso). Yo no veo nada por encima de 6% en la IO> de columna y la mayoría de las filas de 0.00%. SWAPIN es 0.00% a lo largo.


En resumen, la utilización de la CPU no es a través del techo, la utilización de la memoria no es el problema, y no hay señales de excesivo e/S relativa a la espera de ir. ¿Por qué la aplicación web infinita de carga/tiempo de espera al intentar acceder a ella? No podía ser de temas en sysctl.conf o con mi servidor web? Necesita un experto en opinión aquí.


El servidor en cuestión es Ubuntu 14.04 LTS. Nginx es el servidor web, que se utiliza como un proxy inverso con Gunicorn (Django basado en la aplicación web). El back-end es Postgresql 9.3, y Redis está en juego así. La base de datos reside en un aparte de la VM.

0voto

James Shewey Puntos 74

Si usted trabaja con un gran volumen de conexiones TCP y vamos a ir a través de un proxy inverso, como nginx, usted puede encontrar el Puerto TCP Agotamiento. En resumen, no son teóricamente 65535 puertos TCP. Si usted tiene un proxy inverso que viene de IP 192.168.1.1 conexión a su servidor web en el puerto 80 en 192.168.1.2:80, por lo que puede hacer un teórico máximo número de conexiones simultáneas a través de su proxy inverso de 65535 al puerto 80 del servidor web. Después de que se ejecute fuera de los puertos de origen (conocidos como puertos efímeros) para su uso.

Pero es un poco más complicado que eso: Linux por defecto está ajustado para utilizar sólo acerca de 30000 (menor para los mayores núcleos/distros - tan bajo como 1024) de estos puertos, e incluso utiliza un algoritmo que aleatoriamente a tratar de encontrar una fuente gratuita de puerto para su uso. Más cerca de llegar a 30000 marca, los intentos más el kernel hace para seleccionar aleatoriamente a un puerto libre y el tiempo que se tarda en encontrar uno. Trate de usar netstat, grep y wc para contar el número de conexiones que tiene y, si están a punto de 30,000 esta es probablemente la causa de sus tiempos de espera. Usted puede revisar NGINX sugerencias para resolver este problema si este es el caso.

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