Premisas para tener en cuenta para obtener un buen performance en SAP, PARTE IV SISTEMA SAP (Instancia de SAP)

Para este rubro es importante identificar los factores más relevantes que se deben tener presente a la hora de analizar una degradación en el rendimiento (performance), entre los que están:

1.  Parámetros de la instancia, que estén acorde a las buenas prácticas basado en las recomendaciones que sugiere SAP. Estos van orientados al área de memoria en concordancia con el sistema operativo sobre el cual esta soportada la instancia do SAP.

2. Comportamiento de los buffers: Esto pueden ser validados a través de la transacción st02. Allí es importante enfocarse como primera medida en la columna denominada swap. Generalmente la regla indica que podría no tener más de 10.000 swaps por día. En caso de que esa cifra se desborde u observe valores triplicados, se debe revisar de acuerdo con la memoria disponible, los parámetros que tienen ese valor muy elevado y ajustarlos, puede empezar aumentándolos en un 20%. Es de anotar, por un lado, que los valores dependen del sistema operativo y del otro lado es una tarea que requiere y exige tiempo hasta llegar a un punto de equilibrio. A partir del reléase 740, el comportamiento del manejo de los swaps cambió.

Nota: Un volumen alto de swaps indica un problema relacionado con una insuficiencia de espacio en el área de swap o memoria virtual.

3. Revisar y chequear el número de work process que estén holgados y que estén acorde conforme a la memoria disponible para la instancia de SAP.

Para ello adjunto unas fórmulas que pueden servir de base para validarlos.

Procesos

Dialogo   = RAM / 256

Batch (background) = RAM / 1024

Update = RAM / 768

Update = RAM / 1024

Enqueue = 1

Spool = Mínimo 1.

Es de anotar que cuando hago referencia a la RAM, me refiero al espacio reservado para la instancia de SAP, no al valor total de la memoria física. Recuerde que la memoria física es divida tanto para la instancia de SAP como para la instancia de la base de datos que por lo general es un 60% para SAP y 40 % para base de datos, esto siempre y cuando el sistema no esté distribuido.

Para un mejor entendimiento un sistema distribuido se da cuando la instancia central se encuentra en un servidor A y la instancia de base de datos en un servidor B, allí aplica tomar como referencia el valor de la memoria física. Para un sistema no distribuido tanto la instancia central de SAP como la instancia de base de datos se encuentran en el mismo servidor.

4. Disponibilidad de la memoria virtual: Que tenga espacio suficiente para apoyar a la memoria principal en el momento que se requiera. Aquí debo enfatizar que el valor a configurar depende del sistema operativo. Cuando el sistema operativo es Windows, existe una recomendación particular, los valores inicio y final debe ser los mismos y puede ser calculado mediante una fórmula que se encuentra preparada en una hoja de Excel, esta se encuentra adjunta en la nota 1518419.

5. Work process en modo privado: Es uno de los puntos álgidos a chequear, ya que cuando un work process entra en este modo, agarra y/o sujeta el work process y no lo suelta hasta que termine, pero tiene como consecuencia que además de que toma ese work process puede también tomar recursos de memoria. Cuando pasa esto es debido a una mala configuración o definición en los parámetros de memoria de la instancia de SAP.

La mayoría de las veces el tener un work process en modo privado desencadena o está relacionado con el consumo de memoria que el proceso y/o tarea del usuario se encuentra haciendo y se refleja en la sm04.

En la imagen previa se observa que uno de los usuarios al ejecutar la transacción ME2M, está empezando a tomar recursos de memoria de manera inusual (columnas Memoria total y Mem privada), es un candidato para ir chequeando que está ejecutando y como lo está ejecutando.

6. Chequear el SAP Extended Memory que no esté full: Este parámetro es importante que se encuentre holgado, pues es uno de los que si no se encuentra bien configurado genera y desencadena una serie de eventos que apuntan a la degradación del rendimiento. Podríamos decir que esta es el CORE del sistema de gestión de memoria que utiliza SAP, que no son más que espacios que utiliza SAP para que cada work process pueda operar. 

7. Revisar si se observan Jobs del sistema de gestión de SAP (no los operativos), que estén consumiendo demasiado tiempo. En algunos casos o pueden estar mal programados a nivel de configuración o en su defecto pueden o estar obsoletos o existe algún bug que requiere ser resuelto con la aplicación de una nota OSS.

Si después de revisar y realizar los ajustes el rendimiento aun no mejora o los usuarios manifiestan que el sistema se encuentra muy lento, hay que revisar y analizar el comportamiento dado lo siguiente:

* El problema ocurre a una hora determinada?

* el problema se debe algún Job de la operación que está tomando mucho tiempo en ejecución?

• Se han implementado cambios recientes?
• El número de usuarios ha incrementado?
• Los work process de dialogo están siendo consumidos en su totalidad?
• Se observan en la sm50/sm66 muchos registros con “sequential reads” ?, estas dos últimas puedan estar relacionados con problemas en su base de datos.
• Una vez obtengas esas respuestas, sin duda alguna, le ayudarán a evaluar que puede estar ocasionando esa degradación.

Ilustraré con un ejemplo como se refleja los comportamientos tanto cuando se presenta un status en modo PRIVADO, como cuando se reflejan acciones de sequential read”.

En la imagen previa se observa por ejemplo que el work process 10 está en modo PRIVADO y el estatus es stopped, al igual que en la columna Action se refleja que el proceso está haciendo un llamado sequential read. Por un lado se evidencia un claro indicio de configuración a nivel parámetros de memoria, para lo relacionado con el modo privado y del otro lado, el proceso que se está ejecutando en modo fondo (background) por alguna razón,  está haciendo acciones de “sequential read” en la base de datos, que no queda más que investigar la razón que lo está ocasionando y que por lo general obedece o una posible falla a nivel de almacenamiento o la consulta tiene alguna sentencia que se encuentra mal construida y está ocasionando este fenómeno.