Hola,

Por referencias, tienes una entrada en mi glog www.as400howto.com donde
resumo todo lo publicado en la gestión subsistemas, pools de memoria y
trabajos:
http://as400howto.blogspot.com/2011/03/gestionar-mejor-la-configuracion-de.html

También pueden influir los ciclos de commit del trabajo que realiza la
supresión de entradas de la tabla; te recomendaria leerte la siguiente
entrada de mi blog:
http://as400howto.blogspot.com/2008/09/como-gestionar-receptores-de-diario.html

Suerte!!

Martí Riera
www.as400howto.com



Missatge de datil400 <[email protected]> del dia dc., 23 de febr. 2022 a
les 10:48:

> Hola Alex,
>
> gracias por tu ayuda.
>
> El fichero en cuestión tiene sólo tres índices y están de actualización
> inmediata. Es un archivo de estadísticas que se utiliza constantemente y
> los índices se crearon para optimizar las distintas consultas.
>
> Voy a ver el tema del pool. Estoy leyendo alguna documentación de Martí
> Riera sobre este tema y estoy buscando más información.
>
> Javier Mora
>
> El mié, 23 feb 2022 a las 10:11, Alex Martínez (<[email protected]>)
> escribió:
>
>> Hola
>>
>> Así rápidamente lo primero que se me ocurre es si se puede realizar
>> alguna optimización sobre el proceso y sus índices:
>> puedes cambiar los indices que no se utilizan en el proceso a CHGLF
>> MAINT(*DLY)  y cuando acabe volver a cambiarlos a *IMMED
>> ten en cuenta que si tienes mucho indices con mantenimiento *IMMED es una
>> parte costosa del proceso
>>
>> Aqui comentan un técnica similar con SQL y unas tablas temporales
>>
>> https://www.ibm.com/mysupport/s/question/0D50z000060GJyMCAW/stopstart-index-update-beforeafter-table-purge?language=es
>>
>> Otra medida puede ser indicar en el WRKSHRPOOL  + INTRO + F11 y revisar
>> el % mínimo/máximo de memoria para el pool de +INTERACT o para *BASE y
>> evitar que se resientan
>>
>> Tambien lo puedes ajustar con CHGSHRPOOL POOL(*INTERACT) MINPCT(20)
>> MAXPCT(80)  por ejemplo
>>
>> Ya nos comentas
>>
>> SAlu2
>>
>>
>>
>> El mié, 23 feb 2022 a las 9:39, datil400 (<[email protected]>) escribió:
>>
>>> Hola a tod@s,
>>>
>>> tengo que reconocer que después de 30 años trabajando en la plataforma
>>> no he sido capaz de entender/aprender cómo gestiona los trabajos el IBM i.
>>> Os planteo un problema que tengo relacionado con este tema.
>>>
>>> Tengo muchos procesos muy pesados que se ejecutan por lotes, normalmente
>>> por la noche para molestar lo menos posible. En la empresa se trabaja las
>>> 24 horas y estos procesos (aunque tardan mucho y se llevan mucho
>>> procesador) nunca han interferido con el tiempo de respuesta de los
>>> trabajos interactivos.
>>>
>>> En cambio, tengo un proceso muy concreto, que hace algo muy simple que
>>> es una limpieza de un archivo con millones de registros. Cada x tiempo se
>>> ejecuta para seleccionar una serie de registros, que se procesan uno a uno
>>> (se lee el original, se graba en otro archivo y se borrar del origen).
>>> Resumiento, es un bucle READ/WRITE/DELETE sobre unos cientos de miles de
>>> registros.
>>>
>>> Pues cuando se ejecuta este trabajo, el tiempo de respuesta de los
>>> trabajos interactivos se resiente muchísimo (varios segundos) y el resto de
>>> trabajos batch se retrasan incluso horas.
>>>
>>> Actualmente mi configuración es la estándar: pools de memoria *INTERACT
>>> y *BASE. Al trabajo en cuestión le he bajado la prioridad y la porción de
>>> tiempo (TIMESLICE) a niveles de risa. Además el trabajo se lleva muy poco
>>> procesador y muy poca memoria temporal. Aún así, no consigo mejorar los
>>> tiempos de respuesta.
>>>
>>> Tengo la sospecha que podría estar relacionado con los pools de memoria,
>>> ya que veo que *BASE está muy inflado (80-90% de la memoria) e *INTERACT el
>>> resto. Mientras que cuando este programa no está en ejecución los pools
>>> están repartidos a la mitad (aprox).
>>>
>>> ¿Alguna idea para conseguir un mejor tiempo de respuesta?
>>>
>>> Saludos y gracias por vuestros comentarios.
>>>
>>> Javier Mora
>>> ____________________________________________________
>>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
>>> Forum.Help400 © Publicaciones Help400, S.L.
>>
>> ____________________________________________________
>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
>> Forum.Help400 © Publicaciones Help400, S.L.
>
> ____________________________________________________
> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
> Forum.Help400 © Publicaciones Help400, S.L.
____________________________________________________
�nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 � Publicaciones Help400, S.L.

Reply via email to