Premisas a tener en cuenta para obtener un buen performance en SAP, PARTE I SISTEMA OPERATIVO.

Premisas a tener en cuenta para obtener un buen performance en SAP

PARTE I SISTEMA OPERATIVO.

En este punto inicio mi análisis, en la configuración y distribución de los discos o al menos lo que el almacenamiento le presenta al sistema operativo y sobre todo que estén definidos y cumplan con las buenas prácticas, a saber:

Windows

a.       SWAP: Que el swap se encuentre localizado en una unidad de disco independiente al igual que el sistema operativo y ojalá en raid 1, ya que esta tecnología da el mejor acceso y rendimiento de lectura y escritura.

b.       SOFTWARE DE SAP y BD: Que el software de SAP y BD se encuentren en una unidad independiente con tecnología RAID 1, pues allí por lo general se almacenan los logs, que escribe SAP en el directorio work.

c.       DATA  DE LA BASE DE DATOS: Que los archivos que conforman la base de datos además de tener su propio espacio físico cuenten con una buena tecnología de escritura y que lo ofrece la  tecnología raid 5, entre otros  y lo más importante que se encuentren separados de los logs de la base de datos.

d.       LOGS DE LA BASE DE DATOS: Que los logs de la BD al igual que el swap queden almacenados en una unidad independiente con tecnología RAID 1 ya que dan el mejor desempeño de IO (Lectura/Escritura).

Nota: En el ámbito de Windows, uno de los errores que se suelen cometer o con frecuencia más se comenten y más en los sistemas productivos, ya sea por desconocimiento y por el afán de salir del paso o por ahorrar en costos, son:

a.       Colocar el swap donde se encuentra el sistema operativo.

b.       Crear particiones en una sola unidad de disco físico (donde colocan la DATA, LOGS BD y logs de SAP) creyendo que es capaz de soportar la carga, GRAVISIMO ERROR, pues es una sola cabeza tratando de realizar muchas tareas al mismo tiempo, entre las que están (soportar el acceso a la BD, escribiendo al logs de la BD y además escribir logs a nivel de SAP), este es uno de los comportamientos que más degradan el performance en forma notoria.

LINUX

En Linux es diferente, muchas veces o mejor la mayoría de las veces no se tiene el panorama grafico como en Windows, pero igual aplica la estrategia y eso hay que exigírselo al fabricante del HW que al menos te garantice esas configuraciones que son los requerimientos mínimos que exige SAP para su operación.

Otro frente que suelo atacar es a nivel de configuración en el sistema operativo, para el caso de Windows, existen notas que te ayudan a chequear los requerimientos mínimos que se requieren para que SAP pueda operar. En Linux al igual que Windows existen notas que te permiten chequear, validar y configurar algunos parámetros que deben tener el sistema operativo. Esto también aplica tanto para HP-UX, AIX y los demás sistemas operativos que SAP ha certificado para tal fin.

Adicional a lo anterior también concentro mi atención en 2 elementos de gran importancia y que se deben tener en cuenta como son la memoria y la CPU.

Con respecto a la memoria, se debe chequear su porcentaje total de ocupación, un sistema bien afinado, la memoria debe estar por debajo del 60%, en estas condiciones un sistema puede trabajar muy bien y además holgado. Pues me he encontrado sistemas con memoria que supera el 90% en medio de la operación. En estos casos se le debe asignar al menos un 50% más de su tamaño actual, de esta forma se procede a monitorear su comportamiento para luego realizar los ajustes tanto a nivel de BD como en SAP. Realizando los ajustes correspondientes se tiene como   resultado un mejor rendimiento. Como mencione previamente un tamaño ideal es estar por debajo del 60%, aceptable por debajo del 75%, pero cuando supera el 80% hay que monitorearlo e ir preparando la ventana y recursos para aumentarla, puede ser un proceso fortuito o algún programa y/o transacción que se está utilizando sin los filtros adecuados. Aquí es bueno destacar que este comportamiento este sujeto al buen uso que se le dé al sistema, eso que quiere decir, que a pesar de que tengas un buen sistema afinado no faltará el usuario o usuarios que por desconocimiento o por error manden una consulta sin los filtros adecuados por ende tengamos como consecuencia un sistema que esté, además de lento, colgado o en el peor de los escenarios colapsado.

La memoria junto con el swap digamos que trabajan de la mano, en un sistema donde la memoria se encuentra comprometida, lo que hace el sistema es trabajar con la paginación (swap) que cuando esta última excede o supera el 50% demuestra que la memoria principal tiene un cuello de botella que debe revisarse con detenimiento para tomar las medidas preventivas.

En relación con la CPU, es otro punto álgido que se debe monitorear, en este ítem, lo ideal es que la CPU, siempre se encuentre por debajo del 50% para que un sistema vuele, aunque por debajo del 70% también es bueno solo que ya no te va a volar, lo máximo que puede hacer es correr, lo cual no es que sea malo, solo que es bueno identificar que lo lleva a ese límite. Pasado este límite es un fuerte indicador de cuello de botella que debe ser analizado o en su defecto corregido, ya que puede impactar el performance o rendimiento del sistema. Puede pasar que debido a las nuevas operaciones que son muy exigentes están consumiendo más CPU o por la mala construcción de una consulta lo lleve a ese estado.

Todo es cuestión de analizar el escenario y tomar la vía de las medidas preventivas y no esperar hasta lo último para aplicar los controles correctivos que ocasionan malestar y desconfianza en el usuario final, ya que puede estar afectando sus actividades diarias y ellos en últimas son nuestros clientes a quienes debemos tener satisfechos.