Estrategias de análisis de rendimiento

Question

Estoy asignado a una tarea de solución de problemas de depuración de rendimiento.

Escenario: un entorno de aplicaciones múltiples que se ejecuta en varias máquinas en red utilizando bases de datos. OS es Unix, DB es Oracle. La lógica empresarial se implementa en todas las aplicaciones que utilizan comunicación síncrona/asíncrona. Las aplicaciones son multiusuario con varios cientos de usuarios de centros de llamadas en el momento pico. Las interfaces de usuario están basadas en la web.

Las aplicaciones son de terceros, puedo obtener acceso a desarrolladores y código fuente. Solo tengo el sistema de producción y un entorno de prueba funcional, sin entorno de prueba de carga.

Problema: ¡mal rendimiento! Necesito resultados rápidos. La administración se está volviendo loca.

Tengo ejemplos de síntomas como estos: las acciones de la interfaz de usuario tardan unos minutos en completarse. Seaching para un cliente por lo general toma 6 segundos, pero una búsqueda posterior inmediata con los mismos parámetros puede tomar 6 minutos.

¿Cuál sería su estrategia para encontrar las causas raíz?

Answer 1

Si se trata de un escenario de tipo de la undécima hora, y este es un sistema que está caminando sin conocimiento previo, aquí es cómo lo haría - las instrucciones específicas a continuación son para el newb de Unix, pero el los principios generales son válidos para cualquier clasificación del sistema:

1. Cree un archivo de texto con el nombre de cada uno de sus hosts de producción. Vamos a llamarlo prodhosts
2. Obtenga su clave pública ssh en ~/.ssh/authorized_keys en cada uno de prod_hosts. Si no está familiarizado con los agentes de ssh y cómo hacer que los inicios de sesión sean rápidos en todas partes, tómese 10 minutos y léalos, o use un script that handles it for you.

3. Comprobar la carga del sistema en todos los servidores

   for i in `cat prodhosts` ; do echo $i ; ssh $i uptime ; done 
   

   promedios de alta carga (muy en general, más que el número de núcleos que tiene) indican servidores de problemas. Tome nota de ellos; los verá pronto.

4. Compruebe si hay discos llenos - estos son muy comunes

   for i in `cat prodhosts` ; do echo $i ; ssh $i df -h ; done 
   

   Cualquier host que está en o cerca de uso de disco 100% va a ser un problema. Tome nota de cualquier servidor de problemas que encuentre de esta manera.

5. Verificar la actividad de intercambio: el intercambio es la causa más común de un mal rendimiento (y generalmente se combina con el indicador anterior de un promedio de carga elevado).

   for i in `cat prodhosts` ; do echo $i ; ssh $i free -m ; done 
   

   Eso te dirá cuánta memoria tienen todas tus cajas, y cuánto cambian cada una de ellas. Esto es lo que un sistema sano con alrededor de 16 GB de RAM podría ser:

      total  used  free  shared buffers  cached 
   Mem:   15884  15766  117   0   61  14928 
   -/+ buffers/cache:  776  15107 
   Swap:  31743   0  31743 
   

   Es probable que sus cajas de problemas tendrán un número alto de la columna used para Intercambiar. Esa es la cantidad de memoria que intentan usar sus aplicaciones que su máquina no tiene.

6. Armado con esta información, usted debe tener una mejor idea de dónde está el cuello de botella en el 95% de todos los sistemas (el 5% restante sería frenado por los recursos de red remotas o gremlins). Ahora haces triage estándar. Comience en la parte inferior de la pila, es decir, si tiene una carga alta y un rendimiento repugnante en todas partes, comience con su base de datos, porque es probable que sus problemas estén cayendo en cascada en cualquier otro lugar (si su DB suena bien, obviamente busque primero en otro lado), pero siempre sospechar de bases de datos cuando el rendimiento es en la línea):

   • Base de Datos - obtener un registro de todas las consultas que son ejecutados que se haga cargo, por ejemplo, 400 ms, en tan grande de un período de la muestra como se puede permitirse el lujo de tomar (idealmente estos registros ya existirán; de lo contrario, agrúpelos y deje que los datos se recopilen durante una hora más o menos). Hackear juntos algunos scripts que normalizan las consultas y averiguar qué consultas ocupan más tiempo en su sistema (también busque consultas de 1 apagado que tardan demasiado y desaceleran todo lo demás). Deseará analizar esas consultas con un plan de explicación y averiguar cómo lograr que muestren mejor los índices, o averiguar cómo eliminarlos de su sistema si es posible. Pídale ayuda a su DBA si tiene uno, y use un analizador de registro de consultas disponible si puede.
   • Aplicación: mire a través de los registros y esté atento a cualquier cosa loca. Las aplicaciones y el registro varían mucho, así que esto depende mucho del sistema.
   • Sistema operativo (utilízalo en cualquier caja) - mira la salida de dmesg en tu caja - ¿tiene alguna advertencia? Mire a través de los registros en/var/log - ¿ve algo interesante? Cualquier registro que está estallando en el parece? Esos son sus puntos problemáticos.

Después de haber hecho la piratería y afloja para obtener el sistema a un estado estable, sentarse y hablar a la "gestión" sobre el monitoreo, análisis de logs, y todas las herramientas estándar de el intercambio de administrador de sistemas que debería ayudar a evitar que ocurran escenarios como el que está ocurriendo.Lea en Nagios, Munin, rsyslog, etc., o contrate a alguien que pueda automatizar su centro de datos y su supervisión por usted. Además, si es el tercero de la aplicación, hable con ellos acerca de cómo esperan que maneje este tipo de situación: si se trata de un producto comercial, deben tener directrices sobre los requisitos necesarios para ejecutar su aplicación con éxito. Si es algo que contrató para construir una empresa contratista al azar, considere recomendar a la gerencia que contraten a personas que saben lo que están haciendo.

Answer 2

Compruebe la utilización de la CPU si es baja, parece ser un problema de base de datos, analice las consultas y busque escaneos secuenciales, tal vez solo falte un índice.

Compruebe qué componente está inactivo, podría haber algún tipo de tiempo de espera o recursos faltantes.

Cualquier otra cosa depende de la arquitectura de la aplicación. Definitivamente necesita un entorno de prueba para configurar un punto de referencia decente, o bien deje que los gerentes (que compraron esto) paguen por el soporte de terceros.

Answer 3

Ejecute el monitor de archivos sysinternals y el monitor de procesos para encontrar E/S excesivas. Más fácil de hacer cuando el rendimiento se reduce cuando ejecutan informes o programas particulares. Asóciese con su Oracle DBA para supervisar el rendimiento de la base de datos. Asóciese con sysadmin para supervisar los discos en los que residen las tablas de Oracle. Está buscando consultas mal ejecutadas que resulten en escaneos completos de tabla, resultados de matriz, etc. Haga que sysadmin/netadmin controle la saturación de la red.

Copie los datos de producción y el código a otro sistema de prueba aislado y mida el rendimiento. Vea dónde el rendimiento de la CPU y el disco van por el techo.

Tenga en cuenta que la salida de FileMonitor es formato .csv y abrumará rápidamente a Excel. Pero Excel puede tratar ese .csv como un origen de datos externo y puede conectarlo a una tabla dinámica. Simplemente use el asistente de Pivot Table, señale el archivo de informe (.txt) y mida el nombre de la aplicación, el nombre de archivo del dataset y los bytes leídos/escritos. Encontrará rápidamente los archivos que están siendo procesados ​​con E/S. Algunas veces las soluciones son simples, como incluir miles de actualizaciones de bases de datos con una transacción.

Answer 4

Vea en qué máquina (s) la carga de la CPU es alta - de esta manera usted probablemente podrá averiguar si el problema está en el lado de la base de datos o en el código UI (esto último es bastante improbable, pero vale la pena verificar) . También compruebe si alguna máquina tiene poca memoria (la forma de verificar esto depende del lenguaje de programación), es decir, si la ralentización es causada por el intercambio de memoria virtual constante.

Copie datos de producción al sistema de prueba y verifique si el acceso a los datos es lento incluso sin carga alta. Si es así, lo más probable es que sea un diseño de base de datos deficiente. Si no lo es (es decir, si se vuelve lento solo bajo carga), entonces las cosas son más complicadas. Si las cargas de la CPU son bajas, aunque la carga pesada del sistema causa una desaceleración, puede haber un problema con bloqueos y bloqueos innecesarios.Si las cargas de CPU son altas, esto probablemente indique un diseño de base de datos subóptimo o un pobre almacenamiento en memoria caché de resultados (aunque normalmente la base de datos debería hacerlo por sí misma).

Registre registros o solicite a los desarrolladores que registren todas las consultas de consultas SQL y su tiempo de ejecución. Si "todos" son demasiados, pídales que solo registren aquellos que requieren más de 3 s para completarse. Manualmente ejecute consultas lentas y pídale a Oracle que explique lo que está haciendo.

base de datos Comprobación manual de tablas con índices claramente ausente. Si no hay muchas tablas, puede hacer esto más rápido que encontrar qué consultas son lentas.

Answer 5

OK. He hecho esto y the basic method I use is this.

Aquí hay un ejemplo de the kind of results that are ultimately possible.

Dicho esto, eso es sólo el principio.

Habrá problemas múltiples, y cada uno que encuentre y arregle mejorará las cosas significativamente, pero no habrá terminado. Tienes que conseguir la mayoría de ellos.

El mayor problema será que aislará un motivo de bajo rendimiento, y requerirá que una o más de las aplicaciones se codifiquen un poco (o mucho) de manera diferente. Encontrarás resistencia por parte de los programadores que "poseen" el código para hacer esos cambios. Puede muy bien violar su sentido de código diseñado correctamente, y esa es una sensación difícil de superar.

Por ejemplo, trabajé en una aplicación con un problema de rendimiento severo que se consideraba una amenaza para la empresa. Como siempre sucede, hay Wild-XX-Guesses en cuanto a cuál es el problema, y ​​las personas solo están dispuestas a invertir tiempo y dinero en esas conjeturas. El problema real fue una decisión de usar XML como formato de comunicación entre partes de la aplicación, y la mayoría de las veces iba a generar y analizar XML, , aunque las dos partes de la aplicación estaban en el mismo proceso. y podría intercambiar información directamente. Para cambiar esto se requirió un cambio de diseño, que no fue tan difícil de hacer. Lo difícil fue hacer que el programador aceptara que esta parte debía hacerse de manera diferente.

En mi experiencia, los problemas de rendimiento más serios son causados ​​por enfoques generales sobre la abstracción y la estructura de datos, que se ha enseñado religiosamente, y que los programadores son extremadamente reacios a reconsiderar.

Esa es la parte que no he descubierto cómo superarla.