¿Cómo puedo solucionar problemas de latencia alta en mi balanceador de carga de aplicación?

Breve descripción

Las posibles causas de la latencia alta en un balanceador de carga de aplicación incluyen:

• Problemas de conectividad de red
• Uso elevado de memoria (RAM) en las instancias de backend
• Uso elevado de CPU en las instancias de backend
• Configuración incorrecta del servidor web en las instancias de backend
• Problemas con las dependencias de aplicaciones web que se ejecutan en instancias de backend, como bases de datos externas o buckets de Amazon Simple Storage Service (Amazon S3).

Resolución

1.    Compruebe si hay problemas de conectividad de red siguiendo los pasos de solución de problemas que aparecen en Solucionar problemas en los equilibradores de carga de aplicación.

2.    Utilice la herramienta curl para medir la respuesta del primer byte y comprobar si la resolución lenta de DNS contribuye a la latencia.

curl -kso /dev/null https://www.example.com -w "==============\n\n
| dnslookup: %{time_namelookup}\n
| connect: %{time_connect}\n
| appconnect: %{time_appconnect}\n
| pretransfer: %{time_pretransfer}\n
| starttransfer: %{time_starttransfer}\n
| total: %{time_total}\n
| size: %{size_download}\n
| HTTPCode=%{http_code}\n\n"

Ejemplo de resultado:

 | dnslookup: 0.005330
 | connect: 0.006682
 | appconnect: 0.026540
 | pretransfer: 0.026636
 | starttransfer: 0.076980
 | total: 0.077111
 | size: 12130
 | HTTPCode=200

Lleve a cabo estas pruebas mediante el balanceador de carga de aplicación. A continuación, haga las pruebas sin transmitir el balanceador de carga de aplicación a los destinos. Esta estrategia ayuda a aislar el componente que induce la latencia. Para obtener más información sobre las funciones de curl, consulte Cómo utilizar las funciones de curl.

3.Consulte la estadística Promedio de la métrica TargetResponseTime de Amazon CloudWatch para su balanceador de carga de aplicación. Si el valor es alto, es probable que haya un problema con las instancias del backend o los servidores de dependencias de aplicaciones.

4.Para determinar qué instancias del backend tienen una latencia alta, compruebe las entradas del registro de acceso de su balanceador de carga de aplicación. Compruebe target_processing_time para encontrar instancias de backend con problemas de latencia. Asimismo, revise los campos request_processing_time y response_processing_time para comprobar si existen problemas en el balanceador de carga de aplicación.

5.Compruebe la métrica CPUUtilization de CloudWatch de sus instancias de backend. Busque un uso elevado de la CPU o picos en el uso de la CPU. Si existe un uso elevado de la CPU, considere la posibilidad de actualizar las instancias a un tipo de instancia más grande.

6.Verifique si hay problemas de memoria revisando los procesos de Apache en sus instancias de backend.

Ejemplo de comando:

watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

Ejemplo de resultado:

Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no-
headers | wc -1 && free –m
Apache Processes: 27
          total     used     free     shared     buffers     cached
Mem:      8204      7445     758      0          385         4567
-/+ buffers/cache:  2402     5801
Swap:     16383     189      16194

7.Comprueba la configuración MaxClient para los servidores web de sus instancias de backend. Esta configuración define cuántas solicitudes simultáneas puede atender la instancia. En los casos en los que la utilización adecuada de la memoria y la CPU experimenten una latencia alta, considere aumentar el valor de MaxClient.

Compare el número de procesos generados por Apache (httpd) con la configuración MaxClient. Si el número de procesos de Apache alcanza con frecuencia el valor de MaxClient, considere aumentar el valor.

[root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15

<IfModule prefork.c>
StartServers         10
MinSpareServers      5
MaxSpareServers      10
ServerLimit          15
MaxClients           15
MaxRequestsPerChild  4000
</IfModule>

8.Compruebe si hay dependencias de las instancias de backend que puedan estar causando problemas de latencia. Las dependencias pueden incluir bases de datos compartidas o recursos externos (como los buckets de Amazon S3). Las dependencias también pueden incluir conexiones de recursos externos, como instancias de traducción de direcciones de red (NAT), servicios web remotos o servidores proxy.

9.Utilice las siguientes herramientas de Linux para identificar los cuellos de botella de rendimiento del servidor.

uptime: muestra los promedios de carga para ayudar a determinar la cantidad de tareas (procesos) a la espera de ejecución. En los sistemas Linux, este número incluye los procesos a la espera de ejecución en la CPU, así como los procesos bloqueados en la E/S ininterrumpible (normalmente la E/S del disco). Estos datos proporcionan una visión de alto nivel de la carga (o demanda) de recursos que debe interpretarse con otras herramientas. Cuando los promedios de carga de Linux aumentan, hay una mayor demanda de recursos. Para determinar qué recursos tienen una mayor demanda, debe utilizar otras métricas. Por ejemplo, en el caso de las CPU, puede utilizar mpstat -P ALL 1 para medir la utilización por CPU, o top o pidstat 1 para medir la utilización de la CPU por proceso.

mpstat -P ALL 1: muestra los desgloses de tiempo de CPU por CPU, que puede utilizar para comprobar si hay algún desequilibrio. Una sola CPU activa puede demostrar la existencia de una aplicación de un solo subproceso.

pidstat 1: muestra la utilización de la CPU por proceso e imprime un resumen continuo que resulta útil para observar los patrones a lo largo del tiempo.

dmesg | tail: muestra los últimos 10 mensajes del sistema, si los hay. Busque errores que puedan causar problemas de rendimiento.

iostat -xz 1: muestra la carga de trabajo aplicada a los dispositivos de bloques (discos) y el rendimiento resultante.

free -m: muestra la cantidad de memoria libre. Compruebe que estos números no tengan un valor cercano a cero, lo que puede provocar un aumento de la E/S del disco (confírmelo mediante iostat) y una disminución del rendimiento.

sar -n DEV 1: muestra el rendimiento de la interfaz de red (rxkB/s y tckB/s) como medida de la carga de trabajo. Compruebe si se ha alcanzado algún límite.

sar -n TCP,ETCP 1: muestra las métricas TCP clave, que incluyen active/s (número de conexiones TCP iniciadas localmente por segundo), passive/s (número de conexiones TCP iniciadas remotamente por segundo) y retrans/s (número de retransmisiones TCP por segundo).

iftop: muestra las conexiones entre el servidor y una dirección IP remota que consumen la mayor cantidad de ancho de banda. **n iftop ** está disponible en un paquete del mismo nombre en las distribuciones basadas en Red Hat y Debian. Sin embargo, en el caso de las distribuciones basadas en Red Hat, es posible que encuentre un n iftop en un repositorio externo en su lugar.

---