Al utilizar emulador zPDT, las aplicaciones que utilizan Java tienen un rendimiento inferior al que tendrían en una máquina real. Este problema puede ocurrir con el arranque de tareas como: z/OSMF, z/OS Connect, z/OS Explorer…
Por suerte, hay personas que ya han investigado esto y han tratado de mejorar el tiempo de arranque de estas tareas.
Como esta entrada está basada en la documentación que han aportado esas personas que han investigado este problema, me gustaría que, igual que estáis leyendo este contenido, les deis una oportunidad y leáis su trabajo:
THE MAIN FRAME – Autor: Greg Keuken
ColinPaice – Autor: Colin Paice
Why do they ship java products on z/OS with the handbrake on? And how to take the brake off.
Taking the brakes off ZFS on z/OS – move it to OMVS
El proceso consiste en configurar la caché de Java para que se guarde en disco y cargar ese “snapshot” antes del arranque de la tarea. De esta forma, se reduce el tiempo de arranque.
También hay otra configuración adicional (aportada por Colin Paice) que consiste que la tarea zFS se ejecute bajo OMVS (esto es posible desde z/OS 2.2). Esto debería mejorar el rendimiento de aquellas tareas que utilizan ficheros zFS en puntos de montaje de OMVS.
En mi caso, si he notado una mejora gracias a esto en el sentido de velocidad de arranque de la tarea o en que el sistema no se quede “pillado” por el uso de CPU o de “IOs”.
zFS running in the z/OS UNIX address space
Voy a explicar cómo he hecho la configuración y luego añadiré unos pantallazos en los que se puede ver la diferencia de tiempos de arranque, según la configuración.
En el caso de esta instalación, la caché ya estaba configurada en z/OSMF en este fichero:
/global/zosmf/configuration/local_override.cfg
Xshareclasses:cacheDir=/javasc/izusvr1,name=izusvr1cache
También podemos comprobar en el arranque de la tarea z/OSMF que esta configuración está en uso.
Una vez tenemos configurada esta parte y hemos arrancado la tarea, debemos sacar un “snapshot”. Esto se puede hacer en cualquier momento antes de parar el sistema. Por ejemplo, ejecutar el siguiente job de forma manual o que se lance de forma automática cuando empezamos a parar el sistema.
Para hacer esto, yo uso una utilidad REXX (creada por Greg Keuken) llamada JCACHER:
Simplemente, lo guardé en una librería haciendo el siguiente nombre ya que mi caché se llama izusvr1:
sfwc.4 = 'zosmf'
Por:
sfwc.4 = 'izusvr1'
El siguiente job crea el snapshot (se puede descargar al principio de la entrada):
Finalmente, tenemos que añadir un paso previo en el arranque de la tarea para cargar el “snapshot”.
Habría que añadir este paso en la tarea IZUSRV1.
//STEP1 EXEC PGM=IRXJCL,PARM='JCACHER izusvr1 restoreFromSnapshot'
//SYSEXEC DD DSN=IBMUSER.REXX,DISP=SHR
//SYSTSPRT DD SYSOUT=*
Después de un IPL, cuando arranquemos la tarea, deberíamos ver el siguiente mensaje:
Attempting restoreFromSnapshot for: izusvr1
JVMSHRC698I Non-persistent shared cache "izusvr1cache" has been restored successfully from the snapshot
El siguiente cambio que podemos realizar es hacer que ZFS se ejecute por OMVS.
El cambio no se puede hacer de forma dinámica. Es necesario hacer IPL.
Antes de realizarlo, debemos comprobar a qué cosas de nuestro sistema puede afectar. En mi caso, es un sistema emulado de pruebas y el riesgo de realizar este tipo de cambios es mucho menor.
Para identificar si ZFS se está ejecutando en OMVS o no, usaremos el siguiente comando. Si en “ASNAME” aparece algún valor diferente a N/A, no se está ejecutando en OMVS.
D OMVS,PFS
Para realizar los cambios, he copiado BPXPRM00 desde ADCD.Z24C.PARMLIB a USER.Z24C.PARMLIB.
El primer parámetro que he añadido es:
KERNELSTACKS(ABOVE)
Esto sirve para tener más capacidad de hilos (threads). En el siguiente enlace hay una explicación sobre esto:
z/OS V2R2 z/OS UNIX Increase Kernel Thread Capacity Option KERNELSTACKS()
El segundo cambio es modificar la definición de ZFS para quitar el parámetro “ASNAME”.
FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM) ASNAME(ZFS)
Por:
FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM)
Una vez hecho el IPL, podemos comprobar el resultado con el comando (ASNAME = N/A):
D OMVS,PFS
El resultado del parámetro KERNELSTACKS(ABOVE) lo veremos con el comando (parámetro MAXIMUM THREADS):
D OMVS,STORAGE
La comparación de tiempos de arranque de z/OSMF.
Sin cargar el “snapshot” y sin el cambio del OMVS, tardó unos 262 segundos.
Cargando el “snapshot” y sin el cambio del OMVS, tardó unos 211 segundos.
Cargando el “snapshot” y con el cambio del OMVS, tardó unos 171 segundos.
Queda comprobado que, con estos cambios, la mejora es evidente.
En cuanto a ZOWE, el cambio en el ZFS no ha reducido el tiempo de arranque, pero si mejora la respuesta del sistema. Cuando se arranca ZOWE en el emulador, suele ocurrir que el sistema no responde mientras se produce el arranque (pueden ser unos 10 minutos).
También intenté configurar la caché y hacer snapshot en las tareas de ZOWE que usan Java, ya que son las que más tardan en arrancar, pero no afectó al tiempo de arranque. Quizá lo hice mal…
Los scripts que habría que modificar serían:
/Z24C/usr/lpp/zowe/components/api-mediation/bin/start.sh
/Z24C/usr/lpp/zowe/components/files-api/bin/start.sh
/Z24C/usr/lpp/zowe/components/jobs-api/bin/start.sh
Añadí lo siguiente:
-Xshareclasses:nonFatal \
-Xshareclasses:groupAccess \
-Xshareclasses:cacheDirPerm=0777 \
-Xshareclasses:cacheDir=/javasc/zwe1ad,name=zwe1adcache \
-Xscmx50m \
-Xlp:objectheap:pagesize=1m,warn,pageable \
-Xlp:codecache:pagesize=1m,pageable \
Modificando el directorio de caché en cada tarea:
-Xshareclasses:cacheDir=/javasc/zwe1ad,name=zwe1adcache \
-Xshareclasses:cacheDir=/javasc/zwe1ac,name=zwe1accache \
-Xshareclasses:cacheDir=/javasc/zwe1ag,name=zwe1agcache \
-Xshareclasses:cacheDir=/javasc/zwe1ef,name=zwe1efcache \
-Xshareclasses:cacheDir=/javasc/zwe1ej,name=zwe1ejcache \
Quizá en el futuro vuelva a probar. Espero que os haya gustado esta entrada y os parezca interesante esta mejora de rendimiento.