Plataformas de datos de InterSystems y su rendimiento - Parte 4: Análisis de la memoria

Continuando con la serie de análisis de rendimiento, en este artículo voy a mostrar un método para dimensionar los requisitos de memoria compartida para aplicaciones de base de datos que se ejecutan en plataformas de datos de InterSystems, incluyendo los Global y Routine Buffers, gmheap y locksize. También daré algunos consejos de rendimiento que se deberían tener en cuenta al configurar servidores y al virtualizar aplicaciones de Iris. Como siempre, cuando hablo de Iris o Caché , me refiero a toda la plataforma de datos. Este artículo tiene algunos años pero mantiene su esencia, por lo que me referiré a Iris o Caché indistintamente ya que la teoría es exáctamente igual para todos los productos con kernel Caché/Iris. 

Cuando comencé a trabajar con Caché, la mayoría de los sistemas operativos de los clientes eran de 32 bits y la memoria para una aplicación de Caché era cara y limitada. Los servidores Intel más usados tenían apenas unos pocos núcleos y la única forma de escalar era usar grandes servidores físicos o usar ECP para escalar de forma horizontal. Ahora, incluso los servidores más básicos  tienen múltiples procesadores, docenas de núcleos y la memoria mínima es de 128 o 256 GB, con la posibilidad de TB. Para la mayoría de las instalaciones de bases de datos, ECP ha quedado olvidado y ahora podemos escalar los ratios de transacción de aplicaciones de forma masiva en un único servidor.

Una funcionalidad básica de Caché/Iris es la forma en que usamos datos en memoria compartida, lo que habitualmente se llama Database cache o Global Buffers También nos podemos referir como buffers de global o caché de base de datos. Lo prefiero usar Global Buffers. De igual manera, nos referiremos a los buffers de rutina como Routine Buffers. Los datos usaran Global Buffers y las aplicaciones (SQL queries, Clases, Rutinas) usaran Routine Buffers, pero lo iremos viendo a lo largo del artículo.

De forma resumida, si se puede dimensionar y asignar correctamente "más" memoria a Global Buffers, normalmente se logrará mejorar el rendimiento del sistema, ya que se accede mucho más rápido a los datos en memoria que a los que en disco. Hace mucho tiempo, cuando los sistemas de 32 bits eran la norma, la respuesta a la pregunta ¿cuánta memoria debo asignar a Global Buffers? era tan simple como: ¡toda la posible!  De todas formas no había demasiada disponible, por lo que había que esmerarse en hacer sumas para calcular los requerimientos del SO, la cantidad y tamaño de procesos del SO y de Caché y la memoria real utilizada por cada uno, para encontrar la restante y asignar toda la memoria restante. 

Los tiempos han cambiado

Si estáis ejecutando vuestra aplicación en un servidor actual, se pueden asignar enormes cantidades de memoria a la instancia de Iris porque la memoria es "barata" y abundante hoy en día. Sin embargo, los tiempos han vuelto a cambiar y prácticamente todos los sistemas que veo implementados, salvo los más grandes, están virtualizados. Así que si bien las máquinas virtuales "monstruo" pueden tener grandes cantidades de memoria de ser necesario, el foco vuelve a estar en dimensionar correctamente los sistemas. Para aprovechar al máximo la consolidación de servidores, se requiere una planificación de capacidad que optimice el uso de la memoria disponible en el servidor host.

¿Qué es lo que consume memoria?

Generalmente hay cuatro grandes consumidores de memoria en un servidor de base de datos Iris:

• Sistema operativo, incluido el caché del sistema de archivos
• Otras aplicaciones distintas a Iris, si las hay instaladas
• Procesos de Iris
• Memoria compartida de Iris (incluye global y routine buffers más GMHEAP)

En un primer vistazo, la cantidad de memoria física requerida se calcula simplemente sumando los requerimientos de cada uno de los elementos de la lista. Todos los anteriores usan memoria real, pero también pueden usar memoria virtual. Una parte esencial de la planificación de capacidad es dimensionar un sistema de forma que haya suficiente memoria física para evitar la paginación, o que sea mínima, o al menos para minimizar o eliminar los fallos de página en disco, donde la memoria debe recuperarse desde el disco.

En este artículo me centraré en dimensionar la memoria compartida de Iris y en algunas reglas generales para optimizar el rendimiento de la memoria. Los requerimientos del sistema operativo y del kernel varían por sistema operativo, pero en la mayoría de los casos serán varios GB. La caché del sistema de archivos varía, y será lo que esté disponible después de que los otros elementos de la lista tomen su asignación.

Iris consta principalmente de procesos. Si se observan las estadísticas del sistema operativo mientras se ejecuta una aplicación, se verán los procesos de Iris (p. ej. irisdb o irisdb.exe). Así que una forma simple de saber los requerimientos de memoria de la aplicación es mirar las métricas del sistema operativo. Por ejemplo, con vmstat o ps en Linux o con el Explorador de procesos de Windows, podemos calcular la cantidad total de memoria real en uso y extrapolar con los requerimientos de crecimiento deseados u horas pico. Hay que tener en cuenta que algunas métricas informan sobre la memoria virtual, que incluye la memoria compartida, por lo que hay que tener cuidado de obtener los requerimientos de memoria real.
 

Cómo dimensionar Global Buffers: una forma simplificada

Para una base de datos con muchas transacciones, uno de los objetivos de la planificación de la capacidad es dimensionar los Global Buffers de forma que la mayor parte posible del trabajo de la base de datos de la aplicación esté en memoria. Esto minimizará las IOPS de lectura y en general hará que la aplicación funcione mejor. También debemos lograr un equilibrio para que otros consumidores de memoria, como el sistema operativo y los procesos de Iris, no sean paginados a disco y haya suficiente memoria para el caché del sistema de archivos.

En la parte 2 de esta serie mostré un ejemplo de qué puede suceder si hay demasiadas lecturas de disco. En ese caso, las lecturas elevadas eran causadas por un informe o consulta deficiente, pero el mismo efecto se puede ver si los Global Buffers son demasiado pequeños, lo que fuerza a la aplicación a estar leyendo constantemente bloques de datos desde el disco. Como nota adicional, merece la pena puntualizar que el escenario del almacenamiento cambia constantemente - cada vez es más y más rápido gracias a los avances en las SSD, aunque por ahora lo mejor sigue siendo tener los datos en memoria cerca de los procesos en ejecución.

Por supuesto, cada aplicación es diferente, por lo que es importante aclarar que "los resultados pueden variar", pero hay algunas reglas generales que ayudan a empezar a planificar la capacidad de memoria compartida de una aplicación. Después de eso, se pueden realizar ajustes para satisfacer requerimientos específicos.

¿Por dónde empezar?

Desafortunadamente no hay una respuesta mágica... pero como comenté en artículos anteriores, una buena práctica es dimensionar la capacidad de la CPU de los sistemas de forma que, para un ratio máximo requerido de transacciones, la CPU tenga aproximadamente un 80% de uso en los momentos de mayor procesamiento. Esto nos deja un 20% de espacio libre para el crecimiento a corto plazo o picos inesperados de actividad.

Por ejemplo, cuando dimensiono sistemas TrakCare, conozco los requerimientos de la CPU para un ratio de transacciones conocido, en base a comparar y revisar métricas de sitios de clientes, y puedo usar una regla general para servidores basados en procesadores Intel:

Regla general: Dimensionar la memoria física en n GB por núcleo de CPU.

• Para servidores de base de datos TrakCare, n es 8 GB. Para servidores web menores, es 4 GB.

Regla general: Asignar n% de la memoria a los Global Buffers de Iris.

• Para sistemas TrakCare de pequeños a medianos, n% es 60%, lo que deja un 40% de la memoria para el sistema operativo, el caché del sistema de archivos y los procesos Caché. Esto se puede variar, por ejemplo a 50%, si se necesita mucho caché de sistema de archivos o se tienen muchos procesos. O se puede aumentar el % si se usan configuraciones de mucha memoria en sistemas de gran tamaño.
• Esta regla general asume que hay solo una instancia de Caché en el servidor.

Así, por ejemplo, si la aplicación necesita 10 núcleos de CPU, entonces la máquina virtual tendrá 80 GB de memoria, con 48 GB para Global Buffers y 32 GB para todo lo demás.

Las reglas de dimensionamiento de memoria aplican tanto a sistemas físicos como virtualizados, por lo que para máquinas virtuales TrakCare aplica la misma relación de 1 vCPU : 8 GB de memoria.
 

Ajuste de Global Buffers

Hay algunos elementos a observar para comprobar la efectividad del dimensionamiento realizado. Se puede observar la memoria libre fuera de Iris con herramientas del sistema operativo. Se hace la configuración según los mejores cálculos y se observa el uso de memoria a lo largo del tiempo. Si siempre hay memoria libre, se puede reconfigurar el sistema para aumentar los Global Buffers o para ajustar el tamaño de una máquina virtual.

Otro indicador clave de un buen dimensionamiento del buffer de global es tener la menor cantidad de IOPS de lectura, lo que significa que la eficiencia del caché de Iris será alta. Se puede observar el impacto de distintos tamaños de Global Buffer sobre PhyRds y RdRatio con mgstat. En la parte 2 de esta serie se muestra un ejemplo de cómo mirar estas métricas. A no ser que se tenga toda la base de datos en memoria, siempre habrá algunas lecturas de disco; el objetivo es simplemente mantener la cantidad de lecturas lo más baja posible.

Recordad cómo lograr un buen equilibrio: más memoria para los Global Buffers disminuirá los IOPS de lectura, pero posiblemente aumente el uso de CPU, ya que el sistema ahora puede hacer más trabajo en menos tiempo. Pero reducir los IOPS es casi siempre algo bueno: los usuarios estarán más contentos con tiempos de respuesta más cortos.

Consultad más abajo el apartado sobre cómo aplicar vuestros requerimientos a la configuración de la memoria física.

Para servidores virtuales, planificad para no sobreasignar la memoria de vuestras máquinas virtuales de producción, especialmente la memoria compartida de Iris (también se detalla más sobre esto a continuación).

¿El punto óptimo de vuestra aplicación es 8 GB de memoria física por cada núcleo de CPU? No sabría decirlo, pero probad si un método similar funciona para vuestra aplicación. Tanto si son 4GB o 10GB por núcleo. Si habéis encontrado otro método para dimensionar los Global Buffers, por favor dejad un comentario más abajo.
 

Cómo monitorizar el uso de Global Buffers

La herramienta de Caché ^GLOBUFF muestra estadísticas sobre lo que están haciendo los buffers globales en cualquier momento. Por ejemplo, para mostrar los 25 principales por porcentaje:

do display^GLOBUFF(25)

La salida podría verse así:

Total buffers: 2560000    Buffers in use: 2559981  PPG buffers: 1121 (0.044%)

Item  Global                             Database          Percentage (Count)
1     MyGlobal                           BUILD-MYDB1        29.283 (749651)
2     MyGlobal2                          BUILD-MYDB2        23.925 (612478)
3     CacheTemp.xxData                   CACHETEMP          19.974 (511335)
4     RTx                                BUILD-MYDB2        10.364 (265309)
5     TMP.CachedObjectD                  CACHETEMP          2.268 (58073)
6     TMP                                CACHETEMP          2.152 (55102)
7     RFRED                              BUILD-RB           2.087 (53428)
8     PANOTFRED                          BUILD-MYDB2        1.993 (51024)
9     PAPi                               BUILD-MYDB2        1.770 (45310)
10    HIT                                BUILD-MYDB2        1.396 (35727)
11    AHOMER                             BUILD-MYDB1        1.287 (32946)
12    IN                                 BUILD-DATA         0.803 (20550)
13    HIS                                BUILD-DATA         0.732 (18729)
14    FIRST                              BUILD-MYDB1        0.561 (14362)
15    GAMEi                              BUILD-DATA         0.264 (6748)
16    OF                                 BUILD-DATA         0.161 (4111)
17    HISLast                            BUILD-FROGS        0.102 (2616)
18    %Season                            CACHE              0.101 (2588)
19    WooHoo                             BUILD-DATA         0.101 (2573)
20    BLAHi                              BUILD-GECKOS       0.091 (2329)
21    CTPCP                              BUILD-DATA         0.059 (1505)
22    BLAHi                              BUILD-DATA         0.049 (1259)
23    Unknown                            CACHETEMP          0.048 (1222)
24    COD                                BUILD-DATA         0.047 (1192)
25    TMP.CachedObjectI                  CACHETEMP          0.032 (808)

Esto podría ser útil de muchas formas, por ejemplo para ver qué parte de vuestros conjuntos de trabajo se está guardando en memoria. Si os parece útil esta herramienta, dejad un comentario abajo para contar a otros usuarios de la Comunidad cómo os ayudó.
 

Cómo dimensionar las Routine Buffers

Las rutinas que ejecuta una aplicación, incluyendo las clases compiladas, se almacenan en buffers de rutinas que llamaremos Routine Buffers. El objetivo de dimensionar la memoria compartida para los buffers de rutinas es que todo el código de rutinas se cargue y quede residente en los búferes de rutinas. Al igual que con los Global Buffers, es caro e ineficiente leer rutinas desde el disco. El tamaño máximo de los buffers de rutinas es 1023 MB. Como regla general, es deseable tener más buffers de rutinas de los necesarios, ya que siempre se logra una gran mejora en el rendimiento al tener rutinas en caché.

Los buffers de rutinas son de distintos tamaños. De forma predeterminada, Caché determina el número de buffers de cada tamaño. Es posible cambiar la asignación de memoria para distintos tamaños, pero para empezar la planificación de capacidad se recomienda quedarse con los valores predeterminados de Caché a no ser que haya algún motivo especial para cambiarlos. Para más información, consultad el apartado sobre rutinas en el apéndice "config" de la documentación de Caché de la Referencia de archivos de parámetros de Caché (Caché Parameter File Reference) y Memoria y ajustes de inicio (Memory and Startup Settings) en el capítulo "Configuración de Caché" de la guía de administración del sistema Caché (Caché System Administration Guide).

A medida que la aplicación se ejecuta, las rutinas se cargan fuera de disco y se almacenan en el buffer más pequeño donde pueda entrar cada rutina. Por ejemplo, si una rutina tiene 3 KB, se almacenará idealmente en un buffer de 4 KB, pero si no hay buffers de 4 KB disponibles, se usará uno mayor. Una rutina mayor de 32 KB usará tantos buffers de rutinas de 64 KB como necesite.

Cómo comprobar el uso de Routine Buffers

métrica RouLas de mgstat

Una forma de entender si el buffer de rutinas es lo suficientemente grande es la métrica RouLas (routine loads and save) de mgstat. Un RouLas es una recuperación de, o almacenamiento en, el disco. Una cantidad elevada de cargas/almacenamientos de rutinas podría verse como un problema de rendimiento, en cuyo caso, para mejorar el rendimiento, se puede aumentar el número de buffers de rutinas.

cstat

Si se aumentaron los buffers de rutinas hasta el máximo de 1023 MB y aún se ve un RouLas alto, se puede realizar un análisis más detallado para ver qué rutinas están en buffers y cuánto usan, mediante el comando cstat.

ccontrol stat cache -R1

Esto generará una lista de métricas de rutinas, que incluye una lista de buffers de rutinas y todas las rutinas en caché. Por ejemplo, una lista parcial de una instalación de Caché con valores predeterminados es:

Number of rtn buf: 4 KB-> 9600, 16 KB-> 7200, 64 KB-> 2400,
gmaxrouvec (cache rtns/proc): 4 KB-> 276, 16 KB-> 276, 64 KB-> 276,
gmaxinitalrouvec: 4 KB-> 276, 16 KB-> 276, 64 KB-> 276,

Dumping Routine Buffer Pool Currently Inuse
 hash   buf  size sys sfn inuse old type   rcrc     rtime   rver rctentry rouname
   22: 8937  4096   0   1     1   0  D  6adcb49e  56e34d34    53 dcc5d477  %CSP.UI.Portal.ECP.0
   36: 9374  4096   0   1     1   0  M  5c384cae  56e34d88    13 908224b5  %SYSTEM.WorkMgr.1
   37: 9375  4096   0   1     1   0  D  a4d44485  56e34d88    22 91404e82  %SYSTEM.WorkMgr.0
   44: 9455  4096   0   0     1   0  D  9976745d  56e34ca0    57 9699a880  SYS.Monitor.Health.x
 2691:16802 16384   0   0     7   0  P  da8d596f  56e34c80    27 383da785  START
   etc
   etc  

"rtns/proc" en la segunda línea de arriba indica que se pueden guardar en caché 276 rutinas en cada tamaño de buffer de forma predeterminada.

Usando esta información, otra forma de dimensionar los buffers de rutinas es ejecutar la aplicación y listar las rutinas en ejecución con el comando cstat -R1. Entonces se pueden calcular los tamaños de las rutinas en uso. Por ejemplo, se pone esta lista en un Excel, se ordena por tamaño y se ve exactamente qué rutinas se están usando. Si no se están usando todos los buffers de cada tamaño, entonces se tienen suficientes buffers de rutinas. O, si se están usando todos los de cada tamaño, entonces hay que aumentar los buffers de rutinas o se puede configurar de forma más directa la cantidad de cada tamaño de buffer.
 

Tamaño de la tabla de bloqueo (Lock Table)

El parámetro de configuración locksiz es el tamaño (en bytes) de memoria asignada para gestionar bloqueos para el control de concurrencia, con el fin de evitar que distintos procesos cambien un elemento específico de datos a la vez. Internamente, la tabla de bloqueo "en memoria" contiene los bloqueos actuales, junto con la información sobre los procesos que mantienen esos bloqueos.

Como la memoria usada para asignar bloqueos se toma de GMHEAP, no se puede usar más memoria para bloqueos que la existente en GMHEAP. Si se aumenta el tamaño de locksiz, hay que aumentar el tamaño de GMHEAP para que coincida, según la fórmula de la sección GMHEAP que se describe a continuación. La información sobre el uso que la aplicación hace de la tabla de bloqueo puede monitorizarse desde el Portal de administración del sistema (SMP), o más directamente con la API:

Esta API devuelve tres valores: "Available Space, Usable Space, Used Space" (espacio disponible, espacio utilizable, espacio usado). Comprobad el espacio utilizable y el espacio usado para calcular aproximadamente los valores adecuados (se reserva algo de espacio de bloqueo para la estructura de bloqueo). Hay más información disponible en la documentación de Caché.

Nota: si se edita la configuración de locksiz, los cambios se aplicarán inmediatamente.

GMHEAP

Él parámetro de configuración GMHEAP (Generic Memory Heap) se define como: Tamaño (en kilobytes) del heap de memoria genérica para Iris. Esta es la asignación a partir de la cual se asignan también la tabla de bloqueo, las tablas NLS y la tabla de procesos PID.

Nota: cambiar el GMHEAP requiere reiniciar Iris.

Para ayudar a dimensionar la aplicación, se puede consultar información sobre el uso de GMHEAP usando la API:

%SYSTEM.Config.SharedMemoryHeap

Esta API también ofrece la posibilidad de obtener la memoria heap disponible y valor GMHEAP recomendado.. Por ejemplo, el método DisplayUsage muestra toda la memoria usada por cada uno de los componentes del sistema y la cantidad de memoria heap disponible. Hay más información disponible en la documentación de Caché.

write $system.Config.SharedMemoryHeap.DisplayUsage()

Para tener una idea del uso y recomendaciones de GMHEAP en cualquier momento, se puede usar el método RecommendedSize. Sin embargo, hay que ejecutar esto varias veces para generar un punto de partida y recomendaciones para el sistema.

write $system.Config.SharedMemoryHeap.RecommendedSize()

Regla general: una vez más, los resultados para una aplicación determinada pueden variar, pero los siguientes son buenos puntos de partida para vuestro dimensionamiento:

(Minimum 128MB) or (64 MB * number of cores) or (2x locksiz) or whichever is larger.

Recordad que hay que dimensionar GMHEAP para incluir la tabla de bloqueos.
 

Large/Huge pages

Mark Bolinsky escribió un excelente artículo en el que explica por qué activar Huge pages en Linux logra una gran mejora del rendimiento.

¡Atención! Large pages de Windows y memoria compartida

Iris usa memoria compartida en todas las plataformas y versiones y logra mejorar mucho el rendimiento, incluso en Windows, donde siempre se usa. Pero hay algunos problemas particulares con Windows que hay que conocer.

Cuando Iris se inicia, asigna una única y gran porción de memoria compartida para ser usada por la caché de la base de datos (Global Buffers), la caché de rutinas (Routine Buffers), el heap de memoria compartida, los buffers de journal y otras estructuras de control. Al iniciar Iris, la memoria compartida puede asignarse usando páginas pequeñas o grandes. En Windows 2008 R2 y posteriores, Caché usa páginas grandes de forma predeterminada. Pero si un sistema se ha estado ejecutando por un largo tiempo, debido a la fragmentación la memoria podría no ser capaz de asignarse al iniciar Iris, y Iris podría en su lugar usar páginas pequeñas.

Iniciar Iris de forma inesperada con páginas pequeñas puede hacer que Iris se inicie con menos memoria compartida que la definida en la configuración, o Iris podría tardar mucho tiempo en iniciar o fallar al intentar iniciar. He visto esto en sitios con Windows clúster , en los que el servidor de backup no se ha usado como servidor de base de datos durante mucho tiempo.

Consejo: Una estrategia de mitigación es reiniciar periódicamente el servidor de clúster Windows. Otra forma es usar Linux o usar Mirroring en vez de Windows clúster. Pero esto ya es otra historia...
 

Memoria física

La memoria física está determinada por la mejor configuración para el procesador. Una mala configuración de la memoria puede tener un impacto significativo sobre el rendimiento.
 

Mejores prácticas para la configuración de la memoria Intel

Esta información aplica únicamente a procesadores Intel. Comprobad con los proveedores qué reglas aplican a otros procesadores.

Algunos factores que determinan el rendimiento óptimo de los DIMM son:

• Tipo de DIMM
• Rango de DIMM
• Velocidad de reloj
• Posición con respecto al procesador (el más cercano/el más lejano)
• Número de canales de memoria
• Funcionalidades de redundancia deseadas.

Por ejemplo, en servidores Nehalem y Westmere (Xeon 5500 y 5600) hay tres canales de memoria por procesador y la memoria debe instalarse en conjuntos de tres por procesador. Para los procesadores actuales (por ejemplo el E5-2600), hay cuatro canales de memoria por procesador, por lo que la memoria debe instalarse en conjuntos de cuatro por procesador.

Cuando hay configuraciones de memoria no balanceada (cuando la memoria no está instalada en grupos de tres/cuatro, o los DIMM de memoria son de distintos tamaño), la memoria no balanceada puede resultar en una penalización del 23% en el rendimiento de la memoria.

Recordad que una de las funcionalidades de Iris es el procesamiento de datos en memoria, por lo que es importante obtener el mejor rendimiento de la memoria. También vale la pena señalar que para lograr el máximo ancho de banda, los servidores deben configurarse para la máxima velocidad de memoria. Para procesadores Xeon, el máximo rendimiento de memoria solo se logra con hasta 2 DIMM por canal, por lo que las configuraciones de memoria máxima para servidores comunes con 2 CPU estarán determinadas por factores como la frecuencia de CPU y el tamaño de DIMM (8 GB, 16 GB, etc).

Reglas generales:

• Usar una configuración de plataforma equilibrada: llenar la misma cantidad de DIMM para cada canal y cada socket
• Usar tipos de DIMM idénticos en toda la plataforma: igual tamaño, velocidad y cantidad de rangos.
• Para servidores físicos, redondear hacia arriba la memoria física total en un servidor host a los valores naturales:  64 GB, 128 GB, etc., de acuerdo a estas prácticas recomendadas para procesadores Intel.

Consideraciones para la virtualización con VMware

Más adelante escribiré una publicación con más pautas para cuando Iris se usa virtualizado. Sin embargo, se debería tener en cuenta la siguiente norma clave para la asignación de memoria:

Norma: Configurar una reserva de memoria de VMware en sistemas de producción.

Como hemos visto en este artículo, cuando Iris se inicia, asigna una única y gran porción de memoria compartida para ser usada por la caché de base de datos (Global Buffers), el caché de rutinas, GMHEAP, buffers de journal y otras estructuras de control.

Si se quiere evitar cualquier swapping de memoria compartida, hay que configurar la reserva de memoria de las máquinas virtuales de base de datos de producción a al menos el tamaño de la memoria compartida de Caché, más la memoria para los procesos de Caché y los servicios del sistema operativo y del kernel. Ante la duda, hay que reservar la memoria completa de la máquina virtual de la base de datos de producción.

Como regla general, si se mezclan servidores de producción y de no producción en los mismos sistemas, no hay que configurar reservas de memoria en sistemas de no producción. Hay que dejar que los servidores de no producción compitan por la memoria que sobre ;-D. VMware a menudo llama a las máquinas virtuales con más de 8 CPU "máquinas virtuales monstruo" (monster VM). Los servidores de base de datos de Iris con muchas transacciones a menudo son máquinas virtuales monstruo. Hay otras consideraciones a tener en cuenta para configurar las reservas de memoria en máquinas virtuales monstruo, como por ejemplo si una de ellas se va a migrar por mantenimiento o debido a un reinicio disparado por alta disponibilidad, entonces el servidor host debe contar con suficiente memoria. Existen estrategias para planificar esto, y hablaré de ellas en una publicación futura, junto con otras consideraciones de memoria, como planificar para optimizar el uso de NUMA.
 

Resumen

Esta es una introducción a la planificación de capacidad de memoria, una tarea compleja, sin duda no tan clara y simple como dimensionar una CPU. Si tenéis alguna duda, por favor escribid un comentario.