Optimización de entrada / salida

Hay muchas formas de realizar análisis de entrada / salida. Normalmente es una combinación de dos o más enfoques que dependen de:

La urgencia o importancia de la mejora del rendimiento
El tiempo disponible para el análisis
El nivel de detalle de la información de rendimiento de entrada / salida
El conocimiento de los procesos y de cómo utilizan ficheros

Los enfoques más relevantes para atacar el problema incluyen:

Análisis orientado al proceso (Job-driven analysis). Este enfoque se utiliza cuando tenemos detectado un proceso crítico con un rendimiento bajo y necesitamos mejorarlo
Análisis orientado a ficheros (dataset-driven analysis). Esto enfoque se utiliza cuando un fichero es crítico en la cadena de procesos batch o puede causar contención
Análisis orientado a volúmenes de disco (Volume-driven analysis). Este enfoque se utiliza cuando se ha identificado que un volumen de disco produce embotellamiento (demasiados procesos haciendo un uso intenso del volumen).
Análisis orientado a la ventana batch( Window-level analysis). Este enfoque se utiliza como parte de los análisis periódicos de rendimiento sobre la ventana batch y es necesario para poder comparar en tiempo como mejora o empeora el procesamiento.

Análisis orientado al proceso

Determinar cuál es el proceso crítico más costoso realizando las mediciones a lo largo de varias ventanas batch
Identificar la contribución que hace la entrada / salida al tiempo de proceso transcurrido (elapsed time)
Identificar la contribución que hacen ficheros individuales al tiempo de proceso transcurrido
Seleccionar los ficheros que tienen más tiempo de proceso, tiempos de respuesta pobres u otros problemas
Analizar cuál es el impacto real de estos ficheros en el rendimiento de todo el proceso
Evaluar alternativas para reducir el tiempo de respuesta

Consideremos lo siguiente:

¿Como accede el proceso a cada fichero?
¿Puede reducirse el tiempo de proceso mejorando un fichero o tenemos que mejorarlos todos?
¿Con qué frecuencia se ejecuta el proceso? Si se ejecuta varias veces al día, incluso una pequeña reducción del tiempo de entrada / salida valdría la pena
¿Cuál es la dependencia que tienen otros procesos de los ficheros del proceso que estamos estudiando?
Mejorando el proceso, ¿podríamos mejorar la ventana batch?

Un factor que puede influenciar en el tiempo de ejecución del proceso son las escrituras de mensajes en la clase de salida. A menudo nos concentramos en optimizar los ficheros de entrada / salida y olvidamos cuando escribimos información por consola o en la clase de salida de mensajes.

Lo primero es que un proceso no debe escribir nada que salga en la consola de control de los operadores.

Lo segundo es que un proceso solo debe escribir en la clase de salida dos tipos de informaciones:

Estadísticas de proceso, obligatorias para comprender como ha ido el tratamiento de los datos, contabilizar registros rechazados, etc.
Información que ayude a clarificar un error que impida que el proceso pueda continuar. No estamos hablando de un ABEND, estamos hablando por ejemplo de que si un proceso no recibe datos de entrada, debería interrumpir su ejecución indicando en la clase de salida de mensajes su nivel de criticidad, el error de “no tengo datos de entrada” y alguna recomendación a realizar por el personal de operaciones (“Avise al teléfono nnnnnn, reinicie el proceso pppppp, etc.)

En ocasiones algunos programas incluyen muchas sentencias DISPLAY que muestran información que ayuda a su puesta a punto y a las pruebas en desarrollo.

Esta información debe eliminarse completamente o al menos convertirse en comentarios una vez que el programa pasa al entorno de Preproducción para pruebas de aceptación de usuario o definitivamente a Producción.

A veces los desarrolladores no son conscientes de que unas pocas sentencias DISPLAY UPON CONSOLE ejecutadas en desarrollo con un centenar de registros de un fichero de entrada, pueden convertirse en millones de escrituras en consola al tratar un fichero de movimientos contables, o que el uso de DISPLAY por SYSOUT para indicar determinado tratamiento o informar algo, es completamente inútil cuando se procesan grandes volúmenes de datos (con tres DISPLAY y un millón de registros de entrada, tenemos unos tres millones de líneas que revisar en el spool)

Por si fuera poco crear un archivo en SYSOUT de varios megas o gigas, la ejecución de sentencias DISPLAY que no cumplen ningún objetivo, penaliza el tiempo de ejecución del programa y por ende el tiempo de ejecución del proceso y puede que de toda la ventana batch si el proceso forma parte de la ruta crítica.

Análisis orientado a ficheros(datasets)

El análisis orientado a procesos es bueno para mejorar la ventana batch, pero no tan importante para mejorar un solo proceso en particular.

Consideremos lo siguiente:

¿Cómo se accede a un fichero desde diferentes procesos? ¿Puede nuestra mejora beneficiar a cada uno de estos procesos?
¿Es válido el diseño del fichero para cada uno de los procesos que lo utilizan?
Si este fichero es utilizado por procesos con carácter mensual o anual ¿Sigue siendo válido su diseño?
¿Está desplegado el fichero en el almacenamiento correcto (disco o cartucho)?
¿Pueden ejecutarse en paralelo los procesos que utilizan este fichero?

Pongamos un ejemplo de mejora de fichero. Por lo general se realizan numerosas descargas de tablas DB2 que luego son utilizadas por una gran cantidad de procesos batch.

Por lo general, las descargas de tabla se utilizan en consultas, porque la actualización de las tablas suele realizarse con DB2.

Muchas tablas además de información útil incluyen información de control o auditoría, por ejemplo campos como las fecha de alta o actualización (FECHA_ALTA, FECHA_ACTZ).

Estas fechas ocupan un espacio que en muchas ocasiones no aportan información útil.

Por regla general, los desarrolladores suelen leer y procesar el registro entero de la descarga de tabla.

Un rápido estudio de los procesos que consumen la descarga de la tabla nos indica que los campos de fecha de BDG no se utilizan nunca por los procesos, con lo que la descarga aporta un registro de 20 caracteres extra que nunca son leídos.

Si la tabla tiene 100,000 filas, es evidente que se dejarán de leer 20 caracteres por registro o 2,000,000 de bytes.

Esto permitiría una estructura de datos para tratar el fichero mucho más compacta, con ahorro de memoria y de tiempo de proceso al tratarla.

Si queremos hacer un estudio más completo y revisar todos los procesos que consumen la descarga, podríamos determinar cuáles son los campos del registro de la descarga que consumen en común. Con esta información utilizando un simple DFSORT, podemos obtener un fichero de proceso que quizás tiene un registro no de 2000 caracteres, sino quizás de 800.

Este esfuerzo de modificar todos los programas impactados para leer el registro reducido de una descarga de tabla (quizás solo hay que cambiar el nombre de la copy del fichero manteniendo los mismos nombres de campo para no tener que reprogramar) y luego tocar las DD de los procesos donde se consume el fichero, puede reducir drásticamente el tiempo de proceso del JCL que estamos estudiando.

Si por casualidad, otro proceso que no tenga el mismo nivel de criticidad necesitara los datos originales siempre podría acceder a la descarga de datos original.

Otro paso importante es determinar si un fichero se coloca en el tipo correcto de almacenamiento: cartucho (tape) o disco (DASD).

Los ficheros muy grandes son pasados a cartucho como normal general en cualquier instalación.

Pero, ¿siempre tiene que ser el criterio de tamaño lo más importante?

Esta claro que ficheros de datos históricos con millones de registros son candidatos probables a ser almacenados en cartucho. Por lo general se consultan muy poco por el resto de los procesos y solo el acto de ser guardados penaliza grandemente el proceso batch que los ha generado.

Si el proceso está en la ruta crítica de la ventana batch, no debería de escribir ni leer ficheros almacenados en cartucho.

Se supone que los discos DASD tienen la suficiente capacidad como para tratar y almacenar datos de poca duración (horarios, diarios o semanales).

El tratamiento de datos en cartucho debería realizarse fuera de esta ruta crítica por el alto nivel de penalizaciones que tiene la lectura /escritura de datos en este tipo de dispositivos.

Hay varias soluciones si la ruta crítica necesita datos de cartucho. Una solución es recuperar los datos de cartucho en un proceso previo guardándolos en disco antes de iniciar el proceso.

Lo mismo ocurriría al guardar en cartucho. Primero se genera el fichero en disco, se consume durante la ruta crítica de la venta batch y al final de esta ruta, un proceso extra guarda en cartucho los ficheros que se deseen, borrándolos del DASD y liberando el espacio.

Análisis orientado al volumen de disco

Cuando analizamos las estadísticas de rendimiento de un fichero en particular, no debemos olvidar que otros ficheros conviven junto a este en el mismo volumen y que su entrada / salida puede impactar significativamente sobre la entrada / salida del fichero que estamos analizando.

Consideremos lo siguiente:

¿Cuánta entrada / salida es realizada en otros ficheros en el mismo volumen? El impacto puede ser significativo si el acceso a estos ficheros es realizado por procesos que tienen mayor prioridad dentro de la carga de trabajo batch
¿Qué procesos están accediendo a otros ficheros en el mismo volumen? Las acciones de mejoras pudieran provocar contención con estos procesos
¿Están provocando contención estos ficheros en la ruta crítica de proceso de la ventana batch?

Análisis orientado a la ventana batch

En ocasiones, si no tenemos tiempo podemos identificar los volúmenes con mas carga o accesos de entrada / salida en toda la ventana batch e incluso obtener un dato por hora.

Cuando estos volúmenes hayan sido seleccionados, identificar los ficheros con mayor cantidad de accesos de entrada / salida en cada uno de estos volúmenes.

Esto puede ser suficiente para identificar embotellamientos de entrada / salida que puedan perjudicar a aplicaciones críticas de negocio.