0

Tuning IHS: consideraciones respecto al plugin WebSphere en sistemas Unix y Linux

Tunear el IHS para hacer el parámetro MaxConnections más efectivo

El uso de MaxConnections en el plugin de WebSphere es más efectivo en versiones de IHS 2.0 y superiores, usando un único proceso hijo.

Normalmente es mucho más efectivo prevenir que los sistemas del backend acepten más conexiones de las que realmente pueden manejar, creando un embotellamiento a nivel TCP. Cuando esto se hace en el lado cliente (plugin HTTP), no existe una coordinación entre los procesos, lo que hace que los límites no sean efectivos.

  • linuxthreads (pthread en Linux): ThreadsPerChild por encima de 100 (aproximadamente) implican un incremento en el consumo de CPU.
  • SSL: por encima de 100 (aproximadamente) también implican un incremento en el consumo de CPU.
  • El plugin de WebSphere 5 tiene una limitación en el descriptor de ficheros que afectará a sistemas Linux y Solaris con valores de ThreadsPerChild por encima de 500.

Usar MaxConnections con más de un proceso hijo o en una granja de servidores web conlleva muchas más complicaciones. Cada proceso hijo de cada IHS debe tener un valor de MaxConnections suficiente para permitir que cada hilo encuentre un servidor en el backend.

Eligiendo un valor adecuado para MaxConnections

MaxConnections no tiene efecto si excede el valor de ThreadsPerChild, pues ningún proceso hijo puede intentar usar más conexiones que el proceso padre.

Límite superior: Si tenemos constancia de que un servidor http está sobrecargando un servidor de aplicaciones podríamos empezar por determinar el número de conexiones que el servidor de aplicaciones puede manejar.

La fórmula para determinar el valor superior de MaxConnections sería:

N / (MaxClients / ThreadsPerChild)

Esto sería el peor de los escenarios en cuanto a conexiones desde un IHS a un servidor de aplicaciones. Si aumenta el número de servidores de aplicaciones en el backend disminuyen las posibilidades de que se llegue a dicho escenario, pues lo servidores web distribuirán las conexiones teniendo en cuenta la afinidad de sesión y el balanceo de carga.

Por ejemplo, si queremos limitar el número de conexiones a 200 en un servidor de aplicaciones utilizando 4 procesos hijo deberemos ajustar el valor de MaxConnections a 50 porque cada proceso hijo lleva su propia cuenta.

Límite inferior: Si el valor de MaxConnections es demasiado pequeño, un proceso hijo puede empezar a fallar por no tener un servidor de aplicaciones que usar.

Para evitar esto, MaxConnections debe tener un valor superior al de ThreadsPerChild.

Por ejemplo, si cada proceso hijo tiene tiene 128 ThreadsPerChild y 50 MaxConnections en dos servidores de aplicaciones, un único proceso hijo no podrá atender las 128 peticiones porque sólo se pueden atender 100 (50×2).

Para usar MaxConnections, el IHS debe estar configurado para usar un pequeño número (fijo) de procesos hijo y no variarlo para responder a la carga. Esto permite tener un número de procesos constante y predecible con un valor de MaxConnections fijo cada uno.

  • MinSpareServers y MaxSpareServers deben tener el mismo valor que MaxClients.
  • Startservers debe ajustarse a MaxClients / ThreadsPerChild.

Cuando hay configurado más de un proceso hijo (el número de procesos hijo supera a MaxConnections / ThreadsperChild), configurar MaxSpareServers como maxClients puede hacer que se mantengan vivos múltiples procesos hijo cuando no son necesarios, lo que afecta al plugin de WebSphere a la hora de detectar caídas porque los hilos de cada proceso hijo deben descubrir si el servidor se ha colgado.

Tunear el IHS para mejorar la eficiencia del plugin detectando caídas

Solo los hilos del plugin de WebSphere en cada proceso de cada IHS comparten información sobre las caídas de un servidor de aplicaciones, lo que lleva a muchos administradores a limitar drasticamente el número de procesos hijos en ejecución. Si tenemos problemas con caídas marcadas por diferentes procesos hijo en el mismo servidor de aplicaciones deberemos plantearnos aumentar el valor de ThreadsPerChild y disminuir MinSpareThreads y MaxSpareThreads de una de estas dos maneras:

  • El primer enfoque es usar un único proceso hijo con los mismos valores para MaxClients y ThreadsPerChild. El IHS no creará ni destruirá procesos en función de la carga. Precauciones:
    • Una caída del servidor web impactará al 100% de los clientes.
    • Determinados cuelgues afectarán al 100% de los clientes.
    • Aumentará el uso de CPU si usamos SSL y ThreadsPerChild es mayor que unos cientos.
  • El segundo enfoque consiste en usar un número variable de procesos hijo, pero limitando estrictamente el número de procesos que arranca el IHS por la demanda y siendo muy agresivo a la hora de terminar procesos que no se estén usando. Esto se consigue ajustando ThreadsPerChild al 25% – 50% del MaxClients, mientras que MinSpareThreads y MaxSpareThreads permanecen con valores bajos. Precauciones:
    • MaxSpareThreads < MaxClients hace que el IHS termine procesos de manera rutinaria. Por consiguiente, los procesos que estén procesando una petición muy larga necesitarán mucho tiempo para terminar.
    • Un MaxSpareThread bajo puede ocasionar un uso elevado de CPU para crear procesos hijo de reemplazo.
    • Cuando termina un proceso hijo se pierden las cachés de ESI y mod_mem_cache con él.

Tunear el IHS para mejorar la eficiencia en la invalidación ESI

Si se usa el servlet para invalidación ESI (“Reverse Proxy“) en el plugin de WebSphere, según va aumentando el número de procesos hijo (y se va ccomprimiendo el ratio ThreadsPerChild / MaxClients) se van consumiendo más hilos del Web Container. Cada proceso usa un hilo para el proceso de invalidación (si está configurado), que se usa de manera síncrona en el Web Container.

En este caso debería tenerse en cuenta el número de procesos hijo por servidor web y el número de hilos configurados en el Web container.

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *