Orientación para Sizings

En esta entrada os instruiré con unos sencillos pasos para conseguir realizar un correcto"sizing" a la hora de escoger infraestructura y asignar recursos para vuestra aplicación, logrando así sacar el mayor rendimiento posible con su justo gasto.

Propondré un ejemplo práctico e instructivo con el que podréis haceros una idea clara.

Se nos encarga un proyecto, trata ni más ni menos de implantar un SAP Netweaver 7.0  + Oracle, destinado a ser un Business (BW).

Tendremos en juego muchos factores a la hora de escoger; CPU, memoria física, sistema operativo, espacio físico, creación de LUNs desde cabina de discos... entre muchos otros.

Pero por ahora nos centraremos en la arquitectura de datos del procesador, una vez habiendo considerado esto, ya podremos definir el resto de aspectos de nuestro proyecto. Vamos a ello.

Tendremos en cuenta lo siguiente acerca de nuestra aplicación SAP BW:

-El mínimo recomendado de memoria física para un SAP ABAP+JAVA son 6GB.

-Un SAP Netweaver BW consume grandes cantidades de memoria física.

-Oracle requerirá de amplios buffers para el correcto performance de la aplicación, con tal de evitar altos rangos de I/O (lecturas directas).

-Un proceso único, al realizar consultas costosas y de altos rangos de registros, puede llegar a consumir gran cantidad de memoria privada.

-Se trata de un entorno productivo, por lo cual, evolutivo y exigente de más recursos según usuarios funcionales activos.

Habiendo pues, visto a grandes rasgos las características que peculiarizan este proyecto, entenderemos que la opción más sensata es sin duda un entorno de x32bits bajo Windows 2003.

Composición:

-12GB de memoria RAM.

-x2 CPU de 2 núcleos a 1,80GHZ

-Windows 2003 Server (sin necesidad del útlimo SP)

-20GB de paginación.

Ventajas que nos ofrece las limitaciones del sistema operativo W2K2003 x32 bits:

-En un principio, sin especificar la opción /PAE el sistema no reconoce más de 4GB de memoria física.

-Un único proceso no puede alocatar más de 1GB de  memoria para el solo.

-Utilizando en el boot.ini la opción 3/GB se permite a los procesos alocatar 2GB más de la memoria virtual (SWAP).

-Esta limitación también aplica a buffers, los propios de SAP, y la suma total de los buffers de ORACLE.

-La gestión de memoria de Windows, SAP "zero memory administration" nos asegurará que tengamos que reiniciar casi diariamente, vaciando buffers y generando microcortes de servicio, estimulando así un ritmo más pausado del usuario.

Preguntas frecuentes:

P: ¿Qué conseguiremos gracias a estas limitaciones del sistema operativo? 

R: La respuesta está clara, limitaremos de manera efectiva la mala utilización de los recursos de la máquina, lo cual nos llevará a forzar a los usuarios a realizar trabajos de manera contenida, restringiendo así las consultas que es capaz ORACLE de soportar, y dándose el caso de haber peticiones excesivas (no a nivel funcional), se devolverá un dump desde SAP, el significativo SYSTEM_NO_TASK_STORAGE DUMP, el cual nos alertará que una tarea estaba intentando alocatar más de 1GB (roll area, heap y extended memory incluidos).

P: ¿Es posible lanzar correctamente programas pesados, como los designados para cierres de mes o nominales?

R: Por supuesto que es posible, pero para ello requeriremos instalar una instancia SAP paralela (DiagServer) sobre un servidor x64 bits conectada a nuestra instancia central (CI).

P: ¿Oracle no queda muy límitado al encontrarse corriendo sobre un sistema de 32bits?

R: Sí, pero es más una medida de seguridad que una restricción perjudicadora, esto obliga a que no se puedan realizar ciertas consultas directamente sobre la base de datos, ya que acabarían provocando el conocido ORA-04030 por falta de recursos, por lo cual siempre se tendrá que utilizar SAP, para aprovechar sus buffers como intermediarios.

P: ¿Obliga esto, entonces, a instalar una instancia adicional sobre x64 bits?

R: No, sólo conforme crezca el número de registros de las tablas, y siempre que las consultas sean referidas a éstas.

P: ¿Supone algún problema el tráfico adicional de red que se genera a la hora de realizar las consultas desde la instancia de diálogo a la máquina de x32 que contiene la base de datos?

R:  No, siempre que tengamos en cuenta el crear una red privada a GIGA entre ambas máquinas. No hacerlo se consideraría más un error de planning. Es algo que cualquiera se daría cuenta que es de cajón...

Alberto Mateos Blanco