Investigación de regresión del rendimiento de la CPU

Si se encuentra una posible regresión del rendimiento de la CPU durante la migración a un nuevo release, las primeras dificultades son verificar que se ha producido realmente una regresión de la CPU e identificar los tipos de conexión, los planes y los paquetes específicos implicados.

Para determinar si se ha producido una regresión de la CPU en la migración:

1. Busque un intervalo de varios días que tenga un perfil SQL comparable en todas las versiones de Db2 .
   Para lograr una comparación válida, necesita un intervalo correspondiente que tenga un número similar de solicitudes de SQL totales y una distribución similar en los distintos tipos de sentencias SQL, como SELECT, INSERT, UPDATE, DELETE, etc.

   Si descubre que el perfil de SQL ha cambiado de forma notable, la carga de trabajo de las aplicaciones ha cambiado y no es posible una comparación válido para descubrir regresión de CPU.

2. Compare los datos de rendimiento correspondientes al periodo identificado del release anterior con el periodo correspondiente del nuevo release.
   Puede utilizar una combinación de estadísticas y rastreos de contabilidad para comprobar si tiene el mismo patrón en los releases de Db2.
   1. En los datos del rastreo de estadísticas, empiece por comparar los tiempos de CPU de los contextos siguientes:
      • Bloques de control de tareas (TCB) y bloques de solicitud de servicio (SRB) para el espacio de direcciones de servicios del sistema (ssnmMSTR).
      • Bloques de control de tareas (TCB), bloques de solicitud de servicio (SRB) y bloques de solicitud de servicio de motor especializado para el espacio de direcciones de servicios de base de datos (ssnmDBM1).
      • Tiempos de TCB (bloque de control de tareas) y de SRB (bloque de petición de servicio) para el espacio de direcciones de IRLM.
   2. En los datos de rastreo de contabilidad, compare los tiempos de CPU de clase 2 para cada tipo de conexión, para procesadores centrales y para motores especializados, y compruebe el número de solicitudes de SQL, incluidos los indicadores de carga de trabajo siguientes:
      • El número de sentencias SQL para manipulación de datos, por tipo de sentencia (SELECT, INSERT, UPDATE, FETCH, etc.).
      • El número de operaciones de confirmación, operaciones de retrotracción, operaciones de getpage y actualizaciones de agrupación de almacenamiento intermedio.
      • La cantidad de actividad de lectura y escritura en término de operaciones y páginas de E/S.
   3. Combine los datos de rastreo de estadísticas y los datos de rastreo de contabilidad:
      1. Normalice los valores mediante la división de los valores de tiempo de CPU por el número de operaciones de confirmación y de retrotracción. Los valores resultantes representan el promedio de milisegundos de CPU por transacción.
      2. Apile los distintos componentes del consumo de recursos de CPU y trace un gráfico de ellos.
      Por ejemplo:

      MSTR TCB cpu-time / (commits + rollbacks)
      MSTR SRB cpu-time / (commits + rollbacks)
      DBM1 TCB cpu-time / (commits + rollbacks)
      DBM1 SRB cpu-time / (commits + rollbacks)
      DBM1 IIP SRB cpu-time / (commits + rollbacks)
      IRLM TCB cpu-time / (commits + rollbacks)
      IRLM SRB cpu-time / (commits + rollbacks)
      Average Class 2 CP CPU * occurrences / (commits + rollbacks)
      Average Class 2 SE CPU * occurrences / (commits + rollbacks)

3. Compare el número de operaciones de getpage para los intervalos correspondientes.
   Si encuentra cambios significativos en los números de operaciones de getpage en distintos releases (para cargas de trabajo de aplicación comparables), los cambios de vía de acceso son la causa más probable de la regresión de CPU.