Cambie una cosa, vuelva a medir: encontrar el cuello de botella real

Cuando una plataforma va lenta, la orden de compra más rápida es la de más de todo. Suele funcionar un poco, cuesta mucho, y deja en su sitio la causa real para que vuelva a morder en el siguiente pico de tráfico. La alternativa es menos emocionante y mucho más eficaz: encontrar el único recurso al que la carga de trabajo está esperando, cambiar una cosa de ese recurso y volver a medir. Aquí están el método y las herramientas.

Empiece con un número, no con una sensación

«El sitio va lento» no se puede poner a prueba. «El checkout tarda cuatro segundos en el pico de la tarde y menos de uno por la noche» sí. Antes de tocar nada, fije el síntoma a una medición que pueda repetir: un tiempo de página desde fuera, la duración de una consulta, el tiempo de ejecución de un trabajo por lotes, la tasa de peticiones a la que empiezan los errores. Ese número es cómo sabrá si algo de lo que cambie ha ayudado. Sin él, cada cambio parece un progreso.

Después escriba el camino que recorre la operación lenta: cliente, red, balanceador, servidor web, aplicación, caché, base de datos, storage. El cuello de botella está en algún punto de ese camino, y el camino le dice dónde mirar.

Revise cada recurso por uso, saturación y errores

Una disciplina sencilla, popularizada por Brendan Gregg como el método USE, mantiene la búsqueda honesta. Para cada recurso del camino, CPU, memoria, red, storage, haga tres preguntas: ¿cómo de ocupado está?, ¿hay trabajo haciendo cola para él?, ¿está informando de errores? Un recurso puede estar poco usado y aun así ser el problema si las peticiones hacen cola delante de él, así que la segunda pregunta es la que más importa.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Mire el uso por núcleo, no solo la media. Un núcleo a plena carga mientras el resto está ocioso apunta a un cuello de botella de un solo hilo que más núcleos no arreglarán. En vmstat, una cola de ejecución (r) persistentemente mayor que el número de núcleos es saturación.

Memoria.

free -h
vmstat 1
cat /proc/pressure/memory

La presión de memoria se ve como actividad de reclamación y tiempo de parada en el fichero de presión. En una máquina virtual bien construida no hay swap donde esconderse, así que una carga de trabajo que de verdad necesita más memoria de la que tiene falla de forma ruidosa, que es el resultado honesto: la solución es más memoria o una aplicación más ligera.

Storage.

iostat -x 1
pidstat -d 1

Las columnas que importan son los tiempos medios de espera de lecturas y escrituras y el tamaño de la cola. %util engaña en volúmenes flash y SAN, que sirven muchas peticiones en paralelo y pueden mostrar una utilización alta mientras aún tienen margen de sobra. Los tiempos de espera que suben con una cola que crece son la señal real.

Red.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S  | grep -iE 'drop|err|discard'

Compare el tráfico por miembro de un bond: un miembro ocupado mientras el otro está ocioso es un problema de hashing, no de ancho de banda. Los descartes y errores en los contadores de interfaz apuntan por debajo del sistema operativo, a cables, ópticas o el switch.

Base de datos. Muchas plataformas lentas son una base de datos leyendo de disco lo que debería leer de memoria. En MySQL o MariaDB, compare las lecturas lógicas con las que tuvieron que ir a storage:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Si Innodb_buffer_pool_reads (lecturas que no encontraron en memoria) crece deprisa en relación con Innodb_buffer_pool_read_requests, el working set no cabe en el buffer pool. El slow query log, con un umbral sensato, le dice qué consultas lo están pagando.

Cambie una cosa

Una vez que un recurso destaca, forme una hipótesis que explique el número original, y haga un único cambio que la ponga a prueba: un buffer pool dimensionado al working set, una política de hash del bond, una caché delante de la página cara, una consulta con el índice que necesita, una VM redimensionada para caber en un solo socket de CPU. Un cambio cada vez, porque si cambia tres cosas y el número mejora, no sabe cuál ayudó, y puede haber conservado dos que empeoraron las cosas.

Vuelva a medir, de la misma manera

Repita la medición desde el principio, en las mismas condiciones: la misma hora del día o la misma carga sintética, la misma prueba, las mismas herramientas. Un cambio que no ayudó sigue siendo un resultado, porque descarta algo; reviértalo y vuelva a los recursos.

Repita hasta que el síntoma original haya desaparecido o el siguiente cuello de botella sea algo que de verdad deba resolverse con dinero. Ese es el momento en que comprar hardware es la respuesta correcta, y sabrá exactamente qué recurso comprar.

Cómo se ve en la práctica

Algunos de los ajustes más eficaces ocupan una línea. Dimensionamos los búferes de memoria de las bases de datos para que los datos calientes vivan en RAM y el flash sirva trabajo real, y cada servidor con bond que construimos hace hash por direcciones y puertos para que ambos enlaces lleven tráfico. Las dos son reglas fijas en cada plataforma que gestionamos.

Cómo lo hacemos nosotros

El trabajo de rendimiento es la forma en que operamos cada plataforma que gestionamos, no un producto aparte. Medimos en cada capa, desde la E/S por volumen en las cabinas y los contadores por puerto en bonds y switches hasta los slow logs de las bases de datos y la medición de fuera hacia dentro a través del CDN, antes de nombrar una causa. Las reglas fijas que aciertan de forma fiable, como bonds que usan ambos enlaces, flash tratado como flash y VM que caben dentro de un socket, se aplican a cada construcción. Cuando una plataforma sí necesita más capacidad, le decimos qué recurso, cuánto y por qué.

Si su plataforma va lenta y la única sugerencia hasta ahora ha sido un servidor más grande, deje que la midamos primero.

Hable con un ingeniero

Related

Relacionado: Ingeniería de rendimiento y capacidad · Servidores bare metal en HPE y Dell · Storage SAN enterprise en HPE 3PAR, all-flash