☰

Apache con mod_jk con instancias de glassfish, gran cantidad de conexiones establecidas para una cantidad baja de usuarios

tag-icon • tag-icon apache-2.2 load-balancing cluster glassfish mod-jk
Apache con mod_jk con instancias de glassfish, gran cantidad de conexiones establecidas para una cantidad baja de usuarios

Estoy haciendo un ajuste para nuestros servidores de producción para un portal, tenemos 4 servidores, 2 para web y 2 para aplicaciones, y hay un firewall antes y después de los servidores web (así que sí, hay un firewall entre la aplicación y los servidores web), el problema Aquí comencé con la eliminación de conexiones inactivas entre los servidores de aplicaciones y los servidores web mediante el firewall, probé con muchas soluciones y ahora parecía que el problema pasó de conexiones rotas atascadas que estaban en la aplicación porque se cayó del firewall, este problema ocurre cuando tengo poca carga para portal, y para resolverlo necesito reiniciar todos los servidores de aplicaciones, ahora tengo problemas con días de carga alta y la solución urgente fue simplemente reiniciar rápidamente los servidores web Apache, cómo resolver este problema.

Hice cambios con la ayuda del generador de configuración de equilibrio de carga Jboss:http://lbconfig.appspot.com/?lb=mod_jk&mjv=1.2.28&nca=64&ncj=64&nai=2&nji=2&njips=6&f=true&c=false&lr=false&lrl=&mpm=Prefork

Y al monitorear las conexiones en ambos servidores usando el comando netstat y con la descripción general en tiempo real de Google Analytics, obtuve las siguientes estadísticas con ~ 40 visitantes después de 3 días del último reinicio:

Lado web(2 servidores pero sus conexiones "para cada" no son totales):

ESTABLISHED ~700 - 750
TIME_WAIT: 100-200 (big jumbs for one second 150 another 200 another 170 and then 120 and so)

Lado de la aplicación(aquí conté todas las conexiones, la mayoría ESTABLECIDAS y algunas CLOSE_WAIT 0 - 5 cada vez que verifico):

S1 (4 instances running) : 900-950
S2 (5 instances running) : 1000-1100

Detalles de los servidores:

  • En servidores web 2x: Apache 2.2.14 / mod_jk 1.2.37
  • en servidores de aplicaciones 2x: Clustered Glassfish 2.1.1 con ajp13 (6 instancias/cada servidor)
  • Todos los servidores Solaris SPARC 64 V-CPUs 32GB ram.

Mis configuraciones: Principalmente como me dio el generador (puedes ver el enlace):

httpd.conf:

KeepAlive On
ServerLimit         12800
StartServers        5
MinSpareServers     5
MaxSpareServers     20
MaxClients          12800
MaxRequestsPerChild 5000

ExtendedStatus Off

propiedades.del.trabajador:

worker.maintain=30
worker.template.type=ajp13
worker.template.session_cookie=JSESSIONID
worker.template.lbfactor=1
worker.template.ping_timeout=10000
worker.template.connection_pool_timeout=10
worker.template.socket_keepalive=True
worker.template.socket_timeout=600
worker.template.connect_timeout=10000
worker.template.prepost_timeout=10000
worker.template.connection_ping_interval=20
worker.template.ping_mode=A
worker.template.socket_connect_timeout=600000

Del lado del pez cristaltiempos de espera de 10 segundos desde el lado de la configuración del clúster, tengo:

Propiedad del servicio HTTP:

  • tiempo de espera de conexión = 10000

Procesamiento de solicitudes:

  • Número de hilos: 2133
  • Número de hilos inicial: 20
  • Incremento del hilo: 10

Mantener vivo (habilitado):

  • Número de hilos: 400
  • Conexiones máximas 256
  • Tiempo de espera: 10 segundos

Grupo de conexiones:

  • Número máximo de conexiones pendientes: 4096

Entonces:

  • Entonces, ¿mi configuración es correcta?
  • ¿Cómo resolver una gran cantidad de conexiones establecidas o es seguro? No quiero que Apache vuelva a estar inactivo si vuelve a tener una carga alta.

Respuesta1

Con respecto a mod_jk / mod_ajp: utilizamos esta configuración un poco más grande y nos topamos con errores de vez en cuando, las conexiones se interrumpieron, pero nunca encontramos una solución real a ninguno de nuestros problemas (pero encontramos algunos errores, que todavía existen)

Mi consejo: realice una configuración alternativa y pruebas de rendimiento: mod_jk vs proxy_http y si proxy_http está dentro de rangos aceptables, omita mod_jk. Hice esto en 2 configuraciones diferentes ahora (y, además, puedo reemplazar Apache con nginx -> BIG WIN) y no me arrepiento.

pros

  • más fácil de depurar
  • más variedad de posibles puertas de enlace lb/frontend (haproxy, nginx, barniz)
  • menos chinches

contras

  • no encontré algunos

información relacionada