Esta entrada va muy relacionada con el post anterior, ya que explicaré los diferentes estados por los que puede pasar un concurrente y qué se puede hacer para disminuir los tiempos de espera.
Primero que nada, recordemos que los administradores de concurrentes son unas colas con reglas definidas para ejecuciones de programas concurrentes.
Existen diferentes tipos de concurrentes y esta nota sólo explicará los 3 más comunes.
Internal Manager
Éste manager es quizás el más importante de todos, ya que funciona como el orquestador de todos los demás managers. Dentro de sus actividades más importantes están:
Interactuar con el administrador (subir y bajar concurrentes).
Subir y bajar el resto de administradores concurrentes.
Reiniciar procesos fallidos de administradores concurrentes.
Monitoreo básico de estado.
Algo interesante es que, si este proceso concurrente llegara a caerse, los demás administradores de concurrentes seguirían procesando requests, sólo requests relacionados a los queues dejarán de funcionar (stop, verify, etc...)
Conflict Resolution Manager
Debido a que los programas concurrentes se pueden definir con ciertas incompatibilidades, este concurrente es el que se encarga de tratar todas estas reglas de incompatibilidad y de liberar a los administradores de concurrentes los programas concurrentes que hayan pasado las reglas de incompatibilidad. Un ejemplo claro es el siguiente:
Si tuviéramos un concurrente que insertara datos en una tabla y otro concurrente que borrara datos de la misma, quisiéramos una incompatibilidad para que no corrieran al mismo tiempo para evitar una pérdida de registros (un borrado mientras insertamos).
Este manager, recibe todos los concurrentes con incompatibilidad (STATUS_CODE=Q) y evita que los administradores de concurrentes estándar los ejecuten, al revisar que un concurrente puede correr libremente, cambia el estado del request a pendiente (STATUS_CODE=I), es hasta este momento que un administrador estándar lo puede procesar.
Standard Manager
Los administradores de concurrentes estándar son los que realmente procesan los programas concurrentes solicitados. Leen de la tabla FND_CONCURRENT_REQUESTS todo lo que esté pendiente de procesar STATUS_CODE=I.
Es importante notar algunas de las propiedades de los administradores de concurrentes antes de seguir adelante.
Processes: Es el número de procesos que tendrá el administrador de concurrente. Entre más procesos se tengan definidos, más concurrentes se podrán ejecutar al mismo tiempo. Es importante recordar que cada proceso es una sesión a la base de dtaos, y que en caso de estar ejecutando un programa concurrente, es una sesión activa.
Sleep Time: El administrador de concurrente, al ser una cola, deberá de tener un tiempo de poleo para saber qué es lo que tiene por procesar, este parámetro es el tiempo en segundos que realiza el poleo. Un sleep time pequeño, representa esperas pequeñas, sin embargo, puede tener un overhead muy grande por queries muy constantes a la tabla de FND_CONCURRENT_REQUETS.
Cache Size: Este parámetro es el que nos indica la cantidad de requests por procesar que una cola puede guardar en memoria sin tener que ir a buscar nuevamente a la tabla. Es decir, cuántos programas es capaz de procesar un concurrente sin incurrir nuevamente en un sleep time.
Todo lo anterior nos sirve para poder diagnosticar bien un problema de desempeño en los programas concurrentes.
Usando el query en la nota anterior, nos da un resultado similar al siguiente:
Aplicación: GL
Programa: Journal Import
Ejecutable: GLLEZL
Número de ejecuciones: 8770
Tiempo Tanscurrido: 05:57:11
Tiempo Promedio: 00:00:02
Tiempo Maximo: 00:00:10
Tiempo Mínimo: 00:00:00
Esperas: 20d 07:09:45
Espera Promedio: 00:05:33
A simple vista, podemos ver lo siguiente:
El concurrente cuando se ejecuta, corre muy rápido, un tiempo máximo de 10 segundos y en promedio 2 segundos, por lo cual, no existe un problema de desempeño.
En este caso en particular vemos que se tienen más de 20 días de espera para el procesamiento de los cocnurrentes. Recordemos que este tiempo es el sumarizado de todos los concurrentes esperando submitidos, es decir, si se submiten 101, 1 está corriendo, y los otros 100 cada segundo suman 100 segundos de espera.
¿Qué ocasiona esta espera tan elevada? En este caso, es la incompatibilidad del Journal import. ¿Por qué?
Al tener una incompatibilidad (incompatible con él mismo), el programa concurrente se calndariza con estado incompatible. En este punto, y en el peor de los casos, debemos de esperar el sleep time del conflict resolution manager para que lo evalúe y lo pase a un estado de pending normal. Una vez que está en ese estado, en el peor de los casos, debemos de esperar al sleep time del standard manager para que lo tome y lo procese. En este ejemplo, si los sleep times de los managers están a 60 segundos, el tiempo de ejecución es de 2 segundos, sin embargo el tiempo de procesamiento + esperas es de 2 minutos y 2 segundos.
Aquí lo que vale la pena es identificar las esperas más fuertes y ver de qué forma podemos atacar el problema real. Una probable solución en este caso, sería la de quitar la incompatibilidad consigo mismo. y crear una cola especializada que sólo procese journal imports y que tenga sólo 1 proceso, de esta forma se evita que corran dos a la vez. Al hacer esta cola especializada y eliminar la incompatibilidad, nos evitamos el sleep time del conflict resolution manager. Adicionalmente, podemos poner un sleep time de nuestra nueva cola en 10 segundos, y un caché de por lo menos 20.
Haciendo esto, el tiempo de espera para el procesamiento, se puede reducir en un 80%. En este caso es un Journal Import, pero imaginemos que fuera un posteo, o simplemente un concurrente que tiene a un usuario esperando a que termine, los beneficios pueden ser muy grandes.
Algo más que se pudiera revisar, es si realmente se necesitan más de 8,000 ejecuciones del concurrente, esto, aunque es un tema más funcional, muchas veces vale la pena cuestionarlo, hay ocasiones en que de 35,000 ejecuciones diarias de un concurrente, he logrado que se disminuya a 10 ejecuciones al día por tan sólo cuestionar e ir un poco más a fondo en la lógica del negocio.
Los concurrentes que tengan pocas ejecuciones y un alto consumo de tiempo de ejecución se les debe de habilitar un trace y hacer un tuning de manera ordinaria, si es un estándar de Oracle, segúramente ya existe un parche.
En general, es una forma muy sencilla de empezar con un tuning a los concurrentes de e-business, ya que nos muestra de forma clara la pérdida de tiempo en la ejecución de concurrentes.
En el siguiente post hablaré un poco sobre los traces a reportes.
Del color de la leche
Hace 9 años
