Gracias Martí por la información, ya estaba en mi radar. El tema de los ciclos de commit no es el problema, no están registrados por diario los archivos.
¿Conoces alguna fuente que me oriente para ajustar los valores de los pool? Ya sé cómo hacer el cambio de los pools, pero no quiero darle a batch el 80% cuando con el 60% (es un ejemplo) es suficiente. Estoy buscando en manuales y en soporte de IBM pero no doy con la tecla. Gracias de nuevo. Javier Mora El jue, 24 feb 2022 a las 10:44, <[email protected]> escribió: > 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.
____________________________________________________ �nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 � Publicaciones Help400, S.L.
