Cómo investigar cuellos de botella

En este tema se describe un proceso recomendado para investigar cuellos de botella.

¿Cuál es el origen del problema?

El origen del problema podría ser hardware o software relacionado. Cuando los recursos están infrautilizados, suele ser una indicación de un cuello de botella en algún lugar del sistema. Los cuellos de botella pueden deberse a limitaciones de hardware, a configuraciones de software ineficaces, o a una combinación de ambos.

La identificación de cuellos de botella es un proceso incremental por el que aliviar un cuello de botella puede dar lugar a la detección de la siguiente. La ciencia de identificar y aliviar estos cuellos de botella es el objetivo de este tema. Es posible que un sistema funcione a picos durante breves períodos de tiempo. Sin embargo, para un rendimiento sostenible, un sistema solo puede procesar tan rápido como su componente de rendimiento más lento.

Uso de un enfoque serie

Los cuellos de botella pueden producirse en los puntos finales (entrada/salida) del sistema o en algún punto intermedio (orquestación/base de datos). Una vez determinada la ubicación del cuello de botella, se puede aplicar un enfoque estructurado para identificar el origen. Después de aliviar los cuellos de botella, es esencial medir de nuevo el rendimiento para asegurarse de que no se ha introducido un nuevo cuello de botella en otro lugar del sistema más abajo de la línea.

El proceso de identificación y corrección de cuellos de botella debe realizarse de forma serial, por lo que solo se debe variar un parámetro a la vez y, a continuación, medir el rendimiento para comprobar el impacto de ese único cambio. Variar más de un parámetro a la vez podría ocultar el efecto del cambio.

Por ejemplo, cambiar el parámetro 1 podría mejorar el rendimiento, sin embargo, cambiar el parámetro 2 junto con el cambio del parámetro 1 podría tener un efecto perjudicial que niega las ventajas de cambiar el parámetro 1, lo que conduce a un efecto neto cero. Sin embargo, esto da como resultado un falso negativo en el efecto del parámetro 1 variable y un falso positivo en el efecto del parámetro 2 variable.

Probar la coherencia

La medición de las características de rendimiento después de cambiar la configuración es imperativa para validar el efecto del cambio.

• Hardware: es importante usar hardware coherente, ya que variar el hardware puede mostrar un comportamiento incoherente que produce resultados engañosos, por ejemplo, no usar un portátil.

• Duración de la ejecución de pruebas: también es importante medir el rendimiento durante un período mínimo fijo para garantizar que los resultados sean realmente sostenibles y no simplemente picos. Otra razón para ejecutar pruebas durante períodos más largos es asegurarse de que el sistema ha pasado por el período inicial de adaptación donde se rellenan todas las memorias caché, las tablas de base de datos han alcanzado los recuentos esperados y el control de velocidad tiene tiempo suficiente para entrar en acción y regular el caudal una vez que se alcanzan los umbrales predefinidos. Este enfoque ayudará a detectar un rendimiento sostenible óptimo.

• Parámetros de prueba: también es imperativo no variar los parámetros de prueba de una ejecución a otra. Por ejemplo, los distintos tamaños de documento o complejidad de mapa pueden generar diferentes resultados de rendimiento y latencia.

• Estado limpio: Una vez completada una prueba, es importante limpiar todos los estados antes de ejecutar la siguiente prueba. Por ejemplo, los datos históricos pueden acumularse en la base de datos, lo que afecta al rendimiento durante el tiempo de ejecución. El reciclaje de las instancias de servicio ayuda a liberar recursos almacenados en caché, como la memoria, las conexiones de base de datos y los subprocesos.

Expectativas: rendimiento frente a latencia

Es razonable esperar una cierta cantidad de rendimiento o latencia del sistema implementado. Intentar tener un alto rendimiento y una baja latencia es como tirar en dos direcciones opuestas. Sin embargo, es realista esperar un rendimiento óptimo con una latencia razonable. A medida que el rendimiento mejora, el estrés (mayor consumo de CPU, mayor contención de E/S de disco, presión de memoria, mayor contención de bloqueo) se ejerce sobre el sistema, lo que puede tener un impacto negativo en la latencia. Para detectar una capacidad óptima de un sistema, es imperativo identificar y aliviar todos los cuellos de botella.

Los cuellos de botella pueden deberse a datos heredados (instancias completadas) que residen en la base de datos sin ser depurados. Cuando esto ocurre, el rendimiento puede verse afectado. Dar al sistema tiempo suficiente para purgar puede ayudar a aliviar el problema. Sin embargo, detectar la causa de la acumulación del atraso y ayudar a aliviar el problema es importante.

Para detectar la causa del trabajo pendiente, es importante analizar los datos históricos, supervisar los contadores del Monitor de rendimiento (para detectar patrones de uso y diagnosticar el origen del trabajo pendiente). Se trata de una situación común en la que se procesan grandes volúmenes de datos de forma por lotes de forma nocturna. Descubrir la capacidad del sistema y su habilidad para recuperarse de una acumulación de tareas puede ser útil para estimar los requisitos de hardware para manejar escenarios de sobrecarga y la cantidad de margen de búfer para integrar dentro de un sistema y controlar picos imprevistos en el flujo de trabajo.

La optimización del sistema para lograr un rendimiento sostenible óptimo requiere una comprensión detallada de la aplicación que se está implementando, los puntos fuertes y débiles del sistema y los patrones de uso del escenario específico. La única manera de detectar cuellos de botella y predecir un rendimiento sostenible óptimo con certeza es mediante pruebas exhaustivas en una topología que coincida estrechamente con lo que se usará en producción.

Otros temas de esta sección le guían por el proceso de definición de esa topología y proporcionan instrucciones sobre cómo aliviar cuellos de botella y, con suerte, ayudar a evitar cuellos de botella en primer lugar.

Ampliación

Los cuellos de botella pueden ocurrir en varias etapas de la topología implementada. Algunos cuellos de botella se pueden solucionar mediante la actualización de hardware. El hardware se puede actualizar mediante el escalado vertical (más CPU, memoria o caché) o mediante el escalado horizontal (servidores adicionales). La decisión de escalar vertical u horizontalmente depende del tipo de cuello de botella que se haya encontrado y de la aplicación que se está configurando. Lo siguiente le ayudará con instrucciones sobre cómo cambiar las topologías de implementación de hardware en función de los cuellos de botella detectados. Una aplicación debe compilarse desde cero para poder aprovechar el escalado vertical o horizontal. Por ejemplo:

• Es posible que el escalado vertical de un servidor con cpu adicional o memoria no ayude a aliviar el problema si la aplicación se serializa y depende de un único subproceso de ejecución.

• Es posible que el escalado hacia afuera de un sistema con servidores adicionales no ayude si los servidores adicionales simplemente agregan contención en un recurso común que no puede ampliarse. Sin embargo, el escalado horizontal proporciona ventajas adicionales. La implementación de dos servidores de procesador dual en lugar de uno de procesador cuádruple ayuda a proporcionar un servidor redundante que cumple el doble propósito de escalar y manejar un rendimiento adicional y de ofrecer una topología altamente disponible.