Estudiando un caso de alto consumo de memoria en una servidor AIX6TL6SP4 con Oracle 11g, encontré estas recomendaciones que me parce muy útil tener en cuanta a la hora de estudiar este tipo de caso.
Fuente: notasdeaix
No existen unas reglas definitivas para el ajuste de rendimiento de un sistema, sino que consiste en un proceso cíclico de ajuste-análisis-ajuste-análisis-etc... De todas formas si que hay unas reglas básicas para el ajuste inicial, que en principio permiten empezar con un sistema bastante afinado. Además, entender los parámetros involucrados permite más adelante hacer los ajustes necesarios cuando se detectan problemas de rendimiento.
Los parámetros de las siguientes recomendaciones están basados en AIX 5.3 y Oracle 10.2. Ya sé que son versiones que se están dejando de instalar, pero todavía quedan muchas instalaciones con estas versiones, por lo que todavía puede ser útil en algunos casos.
Voy a una poner una lista de parámetros con sus valores, y luego explicaré que es cada parámetro, como se pueden ver y como se pueden modificar:
minfree=max(960;120*lcpus/mempools)
maxfree=minfree + max(j2_maxPageReadAhead;maxpgahead)*lcpus/mempools
minperm%=5 (<= 10)
maxperm%=80 (entre 70 y 90)
maxclient%=maxperm%
lru_file_repage=0
v_pinshm=1
maxpin%=max(80;SGA+10%RAM)
aio minservers=min(10;lcpus)
aio maxservers=10*LVs/lcpus
aio maxrequests=max(4096;4*LVs*queue_depth)
SMT activado
queue_depth
Los parámetros minfree, maxfree, minperm%, maxperm% y maclient% indican los valores de páginas de memoria por debajo y por encima de las cuales el sistema empieza a robar páginas activas de memoria, o deja de robarlas, pasando a paginación para liberar nuevas páginas de memoria. Estos parámetros inciden mucho en la paginación en general.Estos parámetros se visualizan y se modifican mediante vmo.
El parámetro lru_file_repage, con el valor puesto a 0, indica que se deben paginar preferentemente páginas de "file cache" (cache de los filesystems), en vez de páginas de "working storage" (el tipo de páginas utilizadas por Oracle).
Antes de la versión 5.3 no existía este parámetro, por lo que lo se hacía era poner en maxperm% un valor muy bajo, que indicaba la cantidad de memoria que se podía coger. Con la aparición de este parámetro ya no es necesario bajar el maxperm%, por lo que ahora el valor recomendado de maxperm% es entre 70 y 90. Este parámetro incide en la paginación de Oracle. Este parámetro se visualiza y se modifica mediante vmo.
El parámetro v_pinshm, con el valor puesto a 1, indica que el sistema permite a las aplicaciones utilizar un tipo de memoria no paginable, es decir páginas de memoria que no se van a seleccionar para bajar a paginación.
El parámetro maxpin% indica la cantidad máxima de memoria que se puede utilizar para memoria no paginable. Este parámetro en sí mismo no cambia nada, pero permite que se active la opción LOCK_SGA dentro de Oracle (en init.ora creo). Al parecer no es muy recomendable activar el LOCK_SGA, ya que puede afectar a otros procesos de usuario, pero dejar activo el parámetro v_pinshm no afecta al rendimiento, y permite más adelante activar el LOCK_SGA si se considera necesario. Estos parámetros inciden en la paginación de la SGA. Estos parámetros se visualizan y se modifican mediante vmo.
Los aioservers son procesos que utiliza Oracle para delegar las operaciones de I/O. El número de procesos aioserver determinan por lo tanto el número de operaciones de I/O concurrentes que puede realizar Oracle. El parámetro aio maxservers indica el número máximo de procesos aioserver POR LCPU. El valor propuesto para el parámetro aio maxservers es un valor inicial, que se tendrá que ir ampliando en función de las pruebas posteriores. Si al hacer pstat -a | grep -c aio vemos que se llegan a utilizar todos los aioservers (aio maxservers*lcpus) habrá que ampliar el valor. No me fio mucho de la formula de aio maxrequests (4*LVs*queue_depth) porque no le veo sentido, por lo que por defecto pongo 4096, y nunca he tenido que ampliarlo (por ahora). Estos parámetros inciden en la cantidad de operaciones de I/O que puede realizar Oracle, es decir inciden en el uso y la carga de los hdisks. Estos parámetros se visualizan mediante lsattr -El aio, y se modifican mediante chdev -l aio ... o bien mediante smit aio.
La funcionalidad SMT (Simultaneous Multi-Threading) de AIX muestra 2 CPUs lógicas (lcpus) por cada CPU física o virtual que tenga el servidor o la LPAR. Esto optimiza el uso de CPU de las aplicaciones, intercalando la ejecución de procesos en los tiempos "muertos" de CPU de otros procesos (por ejemplo cuando están en Wait IO). Este parámetro incide en la utilización real de las CPUs. Este parámetro se puede visualizar y modificar mediante smtctl o bien mediante smit smt.
En esta lista, además de los parámetros a modificar, aparecen otros parámetros o valores para realizar el cálculo del valor recomendado. Estos parámetros y valores son:
lcpus: número de cpus lógicas que ve el servidor o la LPAR. Con SMT activado es el doble de CPUs físicas o virtuales del servidor o la partición. Sin SMT activado coincide con el número de CPUs físicas o virtuales del servidor o la LPAR. Este parámetro se puede visualizar de distintas formas, por ejemplo en la salida del comando lparstat.
mempools: la verdad no tengo muy claro que es. Al parecer AIX separa la memoria disponible en distintos pools, en función de la cantidad de memoria y del número de CPUs. He visto algunas formulas que se supone indican el cálculo que realiza el sistema, pero no me coinciden con los valores que tengo. Este parámetro se visualiza con vmstat -v (también con vmo, pero puede no mostrar el valor real utilizado).
j2_maxPageReadAhead: el número máximo de páginas que se utilizan para lecturas secuenciales, en JFS2. Este parámetro se visualiza con ioo.
maxpgahead: lo mismo que el anterior, pero para JFS. Este parámetro se visualiza con ioo.
El cálculo de maxfree se realiza según estas recomendaciones con el máximo entre j2_maxPageReadAhead y maxpgahead, pero supongo que esto solo será en sistemas donde existan ambos tipos de filesystem (JFS y JFS2). En el caso de que solo tengamos JFS2 se debería utilizar directamente el primer valor.
SGA: el tamaño de la SGA. Este valor se tiene que mirar a nivel de Oracle.
LVs: el número de LVs de Oracle.
queue_depth: el tamaño de la cola de los hdisk, es decir el número máximo de operaciones de I/O que se pueden realizar de forma "concurrente" sobre el hdisk. No existen reglas bien definidas para ajustar este parámetro, pero más abajo pondré algún comentario. Este parámetro se visualiza mediante lsattr -El hdiskX.
Como ya he dicho, el proceso de ajuste del rendimiento es cíclico, por lo que una vez modificados los parámetros con un ajuste inicial tendremos que analizar el nuevo rendimiento y ver que parámetros necesitamos modificar de nuevo.
Por norma general, excepto en servidores muy sobredimensionados, siempre existe un cuello de botella en algún aspecto. Esto hace que si detectamos y solucionamos un cuello de botella nos encontremos con otro cuello de botella en otro aspecto.
Una vez ajustados perfectamente (cosa que no es posible) todos los parámetros, si sigue habiendo problemas de rendimiento la única solución es aumentar o mejorar los recursos (CPU, memoria, hbas, discos, etc...). Las buenas prácticas indican que este debería ser el último recurso pero, afortunadamente para los fabricantes, suele ser el primer o segundo paso cuando se detectan problemas de rendimiento. De hecho hablando con administradores de Oracle me han dicho que lo de tunear es una cutrada, y que si hay problemas de rendimiento lo suyo es aumentar memoria. Eso sería lo suyo si ese servidor solo tiene una instancia de Oracle y ninguna aplicación, y ya está bien tuneado, pero como no siempre es el caso hay que tunear un poco.
Nota: respecto al parámetro queue_depth, no he entrado en detalles para su ajuste ya que es uno de los parámetros más complicados de ajustar correctamente, sobre todo en entornos con VIO Server, donde se mezcla el tamaño de cola de los discos virtual scsi (de la LPAR cliente), con el tamaño de cola del hdisk correspondiente a nivel del VIO, y además el valor del parámetro num_cmd_elems de los puertos fcsX del VIO (parámetro más o menos equivalente al queue_depth de los hdisk, solo que a nivel del puerto de fibra). Por otra parte, en función del fabricante de la cabina existen varios valores de base recomendados para el queue_depth de los discos. Como única recomendación podría indicar que se puede aumentar el queue_depth de los discos de las LPAR (queue_depth=3 por defecto) para igualarlos con el queue_depth del disco equivalente en el VIO (creo que queue_depth=20 por defecto con discos IBM, aunque depende de la cabina). En mi caso por ejemplo, con los VIO Server tirando de una cabina HP EVA8400 tengo un queue_depth en los VIO de 8, y en las particiones el valor es 3. Lo que he hecho es aumentar el queue_depth de los discos de SAP/Oracle al mismo valor que en los VIO (8).
Esto solo se debe hacer si los hdisks en los VIO se asignan completos a las particiones, si hemos creado LVs y mapeamos los LVs entonces no debemos igualar los valores, porque le estarían llegando al hdisk del VIO un número de peticiones mayor que su queue_depth. Por otra parte el valor de qeueu_depth de las particiones condiciona el número máximo de hdisks permitidos a través de un único adaptador vscsi. Los vscsi cliente tienen una profundidad de cola fija de 512. De esos 512, 2 son para el adaptador, 3 están reservados para cada vscsi lun para recuperación de errores, y el resto es para operaciones de I/O. Con esto se obtiene la siguiente formula:(512 - 2)/(queue_depth_hdisk_cliente + 3) = Num máximo luns en adaptador vscsi Con el valor queue_depth_hdisk_cliente por defecto de 3 tenemos: (512 - 2)/(3 + 3) = 85 hdisks por vscsi/vhost Con una cabina IBM DS8000, que en el VIO tiene un queue_depth de 20, si igualamos el queue_depth en el cliente a 20 tenemos: (512 - 2)/(20 + 3) = 22,17 ==> es decir 22 hdisks por vscsi/vhost
En mi caso, que los discos tienen un queue_depth de 8 en los VIO, he puesto ese valor en el cliente y obtengo: (512 - 2)/(8 + 3) = 46,36 ==> es decir 46 hdisks por vscsi/vhost
Os pongo ahora el ejemplo de un cliente en el que acabo de ajustar estos valores.
Revisando los valores de los tunables hemos visto que algunos tienen los valores por defecto, y en cambio otros estaban con valores distintos de los de por defecto, pero no eran correctos. Esto indica que al instalar Oracle y SAP no se pusieron los valores recomendados, y luego alguien tocó algún parámetro intentando mejorar el rendimiento (pero de hecho era lo contrario).
La plataforma es Oracle 10.2.0.4 y SAP (no sé que versión), con AIX 5.3 TL9 SP5 (5300-09-05-0943).
Es una partición de un 550 POWER6, con 24GB de memoria, 2'4 de CPU (POWER6 a 3'5GHz), 8 procesadores virtuales, SMT activado (--> 16 lcpus). Tenían 80GB de swap (más los 24GB de memoria), y llegaban a tener más del 80% de la swap utilizada.
En aio maxservers tenían puesto 40, lo que hace un total de 640 (40 x 16 lcpus), y haciendo pstat -a | grep -c aio se veía que estaban usando el máximo (los 640). Como he dicho, los hdisks son luns de una HP EVA8400, a través de doble VIO (8 de queue_depth en los VIO) y con queue_depth=3 en la partición. Tenían bastante a menudo los hdisks al 100%. En cuanto a CPU tenían muy poco idle, y algunos procesos bloqueados (columna b de vmstat).
En cuanto a los tunables tenían puesto:
minfree=960 (valor por defecto)
maxfree=1088 (valor por defecto)
minperm%=3 (el valor por defecto es 20)
maxperm%=5 (el valor por defecto es 80)
maxclient%=5 (el valor por defecto es 80)
lru_file_repage=1 (valor por defecto)
v_pinshm=0 (valor por defecto)
maxpin%=80 (valor por defecto)
En base a las formulas que he puesto más arriba he modificado los siguientes valores:
maxfree=1643
maxperm%=70
maxclient%=70
lru_file_repage=0
v_pinshm=1 (pero no se ha activado el LOCK_SGA en Oracle)
aio maxservers=80 (==> 80 x 16 lcpus = 1280 de máximo)
queue_depth=8 (mismo valor que en los VIO, solo en los discos de Oracle/SAP, no en rootvg ni swapvg, aunque ahora que lo pienso igual debería haberlo aumentado también en swapvg por lo menos).
Ahora mismo están usando el 4% de la swap, tienen alrededor de un 60% de CPU idle, ningún proceso bloqueado (columna b de vmstat), están usando 728 aioservers (de los 1280 posibles) y los discos entre un 30% y 50%.