Ir al contenido 
Memoria NUMA En el caso de los grandes servidores de bases de datos, esto determina la proximidad con la que los subprocesos operan respecto a la memoria necesaria y en qué medida las latencias influyen en los tiempos de respuesta y el rendimiento. Ajusto de forma específica la asignación de la CPU, la ubicación de la memoria y el tamaño de la carga de trabajo, reduzco los accesos a distancia y, de este modo, consigo un sistema fiable y predecible Actuación.
Puntos centrales
- Topología Comprender: tener en cuenta de forma específica los nodos, los núcleos, la RAM y las interconexiones.
- Políticas Seleccionar la opción adecuada: «Strict», «Preferred» o «Interleave», según el objetivo de la carga de trabajo.
- afinidad Implementar: vincular localmente los subprocesos, las IRQ y la memoria.
- VMs A nivel de nodo: asignar la vCPU y la RAM a un nodo NUMA.
- Monitoreo Realizar: medir las lecturas remotas, la latencia P99 y la carga de los nodos.
Entender la topología NUMA
Empiezo cada optimización con la Topología: ¿Cuántos nodos NUMA hay?, ¿cómo se distribuyen los núcleos?, ¿cómo está conectada la RAM a los zócalos? y ¿cuánto cuestan los accesos a la interconexión? El acceso a la memoria local requiere mucho menos tiempo que un acceso que traspasa los límites de los nodos, por lo que evito los accesos innecesarios Remoto-Métodos. Los grandes servidores de bases de datos se benefician si planifico los volúmenes de trabajo de tal forma que los hilos y los datos permanezcan en el mismo nodo. Si el volumen de datos activos no cabe en un solo nodo, planifico la distribución de forma deliberada en lugar de dejarla en manos del comportamiento predeterminado. De este modo, mantengo la Latencia es baja y permite un caudal constante incluso con una carga elevada.
Seleccionar correctamente la configuración del BIOS y del hardware
Compruebo en la BIOS que Intercalación de nodos está desactivada, para que se mantenga la separación NUMA. Asigno los canales de memoria de forma simétrica por zócalo y presto atención a la configuración (1DPC frente a 2DPC), para que la frecuencia y el ancho de banda no se vean reducidos innecesariamente. Funciones como Estados C Y en los modos de ahorro de energía más agresivos, ajusto los objetivos de latencia de forma más conservadora, para que los núcleos no tengan que activarse constantemente. SMT/Hiperroscado Lo evalúo en función de cada carga de trabajo: para cargas de trabajo OLTP muy dependientes de la memoria, limito el número de subprocesos SMT activos en paralelo por núcleo, con el fin de reducir la presión sobre la caché y la variabilidad. Además, compruebo que los dispositivos PCIe (NIC, NVMe) estén conectados localmente por zócalo, para que su IRQs y que las rutas DMA no atraviesen la interconexión. Quien establezca aquí una base sólida, sentará las bases sobre las que las políticas y las afinidades surtirán efecto.
Elegir correctamente las políticas de memoria
La elección de Política determina desde qué nodo del núcleo se asigna la memoria y cómo se gestionan los planes alternativos. La opción «Strict» establece límites estrictos e interrumpe las asignaciones si el nodo de destino no dispone de espacio; esto da prioridad a Actuación sobre la flexibilidad. «Preferred» mantiene un nodo preferido, pero en caso de escasez recurre a otros, ofreciendo así un término medio. Interleave distribuye las páginas entre varios nodos mediante el método «round-robin», lo que puede resultar útil en el caso de grandes volúmenes de datos con una carga de trabajo uniforme. Para muchas bases de datos, una estrategia local con «Preferred» o «Strict» suele ser la mejor opción. Elección.
| Política | Conducta | Uso típico | Ventajas | Riesgos |
|---|---|---|---|---|
| Estricto | Solo utiliza la memoria del nodo de destino; de lo contrario, se produce un error. | Crítica latente Bases de datos con una planificación clara de los nudos | Lo más local posible Accede a, latencias previsibles | La asignación puede fallar si el nodo está lleno |
| Preferido | Nodo preferido; es posible recurrir a otros | General Cargas de trabajo con carga variable | Buena proximidad con una flexibilidad aceptable | Mayor proporción de teletrabajo en situaciones de escasez |
| Intercalar | Round-robin a través de varios nodos | Muy grande, de uso generalizado Datos | Distribución de la carga entre varios nodos | Ubicación menos favorable, latencia potencialmente mayor |
Hilos, afinidad de CPU y asignación de memoria
Asigno subprocesos a los núcleos del nodo de destino, asigno memoria con numactl y alineo las IRQ de manera que Datos Permanecer a nivel local. Esta combinación de afinidad de CPU y vinculación de memoria reduce las costosas lecturas remotas y hace que la distribución del tiempo de ejecución sea más compacta. Para un control más detallado, utilizo políticas a nivel de proceso o de hilo y mantengo el pool de búferes lo más cerca posible de los hilos de trabajo activos. Quien quiera profundizar más, encontrará pasos prácticos para Afinidad CPU, que se pueden aplicar directamente en servidores de producción. Así es como garantizo la coherencia Latencias incluso cuando el sistema está muy saturado.
Dar prioridad a los «hotsets» locales
Identifico los «hotsets» de la Carga de trabajo y los coloco estrictamente a nivel local, mientras que los datos inactivos pueden almacenarse de forma más flexible. Gracias a esta priorización, mantengo las rutas principales cerca de la RAM del nodo. Si la carga aumenta, la solución se escala correctamente, ya que las rutas más costosas siguen ejecutándose localmente. Sin este orden, la curva de latencia se desestabiliza en cuanto los hilos empiezan a acceder cada vez más a través de los nodos. Una clara Encuadernación Evita de forma fiable precisamente este comportamiento.
Fusionar NUMA de almacenamiento y de red
Organizo NICs y NVMeAsigno los dispositivos de forma específica a los zócalos y dirijo sus IRQ a los núcleos locales. Mantengo la dirección de recepción/transmisión (RSS/RPS/XPS) de forma coherente por cada nodo, para que los paquetes se procesen allí donde se ejecutan los hilos de la base de datos. En el caso de NVMe, utilizo varias colas por núcleo y asigno los hilos de E/S localmente, de modo que las rutas de registro y de datos no oscilen a través de la interconexión. Para la replicación, separo las rutas de red por nodo, de modo que los flujos WAL/Redo entrantes lleguen a nivel local. De este modo, se mantiene IO– y las rutas de la CPU son congruentes, y la base de datos no desperdicia ciclos en copias innecesarias a través del sistema de memoria.
Planificar máquinas virtuales según el tamaño de los nodos
Dimensiono las máquinas virtuales de manera que el número de vCPU y la memoria RAM quepan en un nodo NUMA físico, ya que eso reduce Latencia y el tráfico de interconexión. Las máquinas virtuales (VM) de gran tamaño, que superan el tamaño de un nodo, distribuyen inevitablemente los accesos a la memoria y, por lo tanto, pierden previsibilidad. Si una máquina virtual debe ser más grande, planifico explícitamente el vNUMA y me aseguro de que la distribución sea simétrica entre los nodos. En cuanto al lado del host, evito la sobresuscripción en cargas de trabajo con latencia y mantengo reservada la memoria local por máquina virtual. „» ofrece una visión general rápida de la estructura física de los nodos.„Planificación de nodos NUMA“, lo que facilita la toma de decisiones sobre el tamaño de la máquina virtual y Error evita que se desplace.
Tener en cuenta la configuración del hipervisor
Compruebo cómo presenta el hipervisor el vNUMA y mantengo la asignación de los grupos de vCPU a los Núcleos De forma coherente. Además, me aseguro de que la topología NUMA de la máquina virtual coincida con la del host, para que el programador pueda permanecer en el entorno local. Mantengo las reservas de memoria y las reglas de anti-afinidad lo más reducidas posible, pero tan estrictas como sea necesario. Prefiero sustituir una alta densidad de máquinas virtuales en un zócalo por una distribución cercana a los nodos. Así, resto Remoto-Reduce al mínimo los accesos y mantén estables las rutas de E/S.
Práctica de contenedores y orquestación
En recipientes coloco cpuset-Límites coherentes: CPU y máscaras de memoria asociadas (cpuset.cpus, cpuset.mems) van de la mano. Las «slices» y las «units» de Systemd tienen afinidades de CPU fijas, para que el núcleo aplique realmente la priorización de memoria. En las capas de orquestación, tengo previsto utilizar pods/servicios cerca del nodo, utilizo evaluaciones de topología y asignación estática de CPU para que una carga de trabajo no oscile entre nodos. Declaro explícitamente las Huge Pages por pod/contenedor y mantengo estables su tamaño y número por nodo. Importante: asigno los procesos de infraestructura y secundarios (registro, sidecars, copias de seguridad) a otros núcleos o incluso al otro nodo NUMA, para no interferir en los conjuntos activos de la base de datos.
Equilibrio NUMA y optimización del sistema operativo
El equilibrio automático de NUMA puede optimizar Accede a mejorar cuando las cargas de trabajo se desplazan o las fases cambian considerablemente. Lo utilizo de forma selectiva, pero observo si el desplazamiento de páginas de un lado a otro resulta más perjudicial que beneficioso. Los procesos fijos con una afinidad clara suelen beneficiarse más de políticas configuradas manualmente que de reasignaciones constantes. Compruebo los parámetros del núcleo, la gestión de IRQ y las Huge Pages transparentes en el contexto de la base de datos y la plataforma. Como punto de partida, me sirve de ayuda este Equilibrio NUMA-Guía para probar los ajustes paso a paso y la dispersión reducir las latencias.
Utilizar las «Huge Pages» de forma selectiva
Utilizo Huge Pages para reducir las faltas de acierto de la TLB y grandes Memoriaabordar estas áreas de forma más eficiente. Para los servidores de bases de datos, reservo las páginas por adelantado, las asigno a los nodos y compruebo si la instancia las utiliza realmente. A menudo desactivo las «Transparent Huge Pages» cuando hay objetivos de latencia y configuro «Huge Pages» estáticas para que la asignación siga siendo determinista. Sin embargo, la proximidad al nodo NUMA sigue siendo decisiva; las Huge Pages refuerzan una buena estrategia, pero no la sustituyen. Quien ignore esto, difícilmente obtendrá beneficios. Actuación y se corre el riesgo de que se produzcan efectos secundarios durante la paginación.
Dimensionamiento de bases de datos: pool de búfer y volumen de trabajo
Planifico el volumen de trabajo activo de tal forma que el buffer pool, las cachés de bloqueo y de planificación, y los elementos más solicitados tablas que quepa en un nodo. En el caso de instancias muy grandes, divido los servicios o fragmentos entre los distintos nodos, en lugar de crear una única instancia monolítica enorme que abarque todos los nodos. En los casos de OLTP, mantengo el buffer pool por nodo compacto y doy prioridad a las tasas de aciertos locales. Para los escaneos OLAP, el intercalado puede resultar útil en casos especiales, cuando el volumen de datos es gigantesco y uniforme. Sin esta disciplina, el Interconexión-El tráfico y el consumo de reservas se producen precisamente cuando se registran picos de demanda.
Trucos específicos de bases de datos
Tengo en cuenta el modelo de procesos y subprocesos del motor: PostgreSQL Utiliza procesos, por lo que configuro la instancia principal, Autovacuum y Checkpointer por separado para cada nodo y mantengo búferes compartidos localmente por fragmento. En MySQL/InnoDB clasifico instancias del grupo de búferes en los nodos y configura los hilos de E/S y los escritores de registro de forma local. Servidor SQL se beneficia de un Soft-NUMA adaptado y de una asignación que organiza los programadores y los grupos de memoria a lo largo de los nodos físicos. Oracle-Configuré las instancias con «Large Pages» locales y segmenté los servidores de trabajo y de E/S entre los distintos nodos. En general, reduzco la contienda de arena del asignador (por ejemplo, jemalloc) mediante arenas adaptadas a NUMA y me aseguro de que Gestor de bloqueos y que los puntos críticos de bloqueo se mantengan locales, distribuyendo la partición y el sharding a lo largo de los nodos.
Seguimiento: métricas que realmente importan
Mido las lecturas remotas, el tráfico de interconexión entre nodos, los errores de página por nodo y el P99-Latencia las consultas relevantes. Además, superviso la carga de la CPU por nodo, los índices de fallos NUMA y el porcentaje de accesos a la memoria local. Esta vista muestra si la política es eficaz o si los hilos acceden de forma descontrolada a páginas remotas. Correlaciono los picos con las decisiones del programador, los eventos de migración y los errores de asignación. Solo estas métricas confirman que la Política no solo en el laboratorio, sino de forma permanente en el sistema productivo.
Estrategia de pruebas e implementación
Realizo las pruebas por etapas: primero, microbenchmarks para Ancho de banda y la latencia por nodo; a continuación, aplico cargas de trabajo realistas con cachés frías y calientes. Aumento la carga de forma gradual, mido los valores P95/P99/P99,9 y observo la distribución, no solo los valores medios. Documento cada cambio (políticas, afinidades, páginas enormes, redireccionamiento de IRQ) y realizo comparaciones A/B en condiciones idénticas. Antes de la implementación, defino Criterios de anulación y un plan de reversión, para poder volver rápidamente a la configuración anterior en caso de regresiones. Una breve prueba de resistencia bajo carga continua permite detectar Deriva y las migraciones que pasan desapercibidas a corto plazo.
Procedimiento paso a paso
En primer lugar, registro la Topología: Número de nodos, asignación de núcleos, canales de memoria e interconexión. A continuación, determino la carga de trabajo objetivo por nodo y compruebo si los «hotsets» encajan en ellos. En el siguiente paso, configuro la afinidad de la CPU, el enrutamiento de IRQ y la vinculación de memoria a nivel de proceso o de hilo. A continuación, activo o desactivo el equilibrio NUMA en función de la dinámica de la carga de trabajo y, si es necesario, reservo páginas enormes por nodo. Por último, verifico el resultado con pruebas de carga repetibles y superviso Cifras clave en funcionamiento continuo.
Ejemplos prácticos y dificultades
Una instancia OLTP con muchas transacciones cortas mejora de forma apreciable si configuro los hilos de trabajo y el búfer de memoria en un Nodo y establezca los valores „Strict“ o «Preferred». Un almacén de datos con escaneos amplios puede beneficiarse de «Interleave» si los datos se utilizan de forma muy uniforme y los nodos están bien aprovechados. Las máquinas virtuales pierden notablemente su previsibilidad en cuanto traspasan los límites de los nodos y el hipervisor asigna la memoria de forma escalonada. A menudo observo que una sola máquina virtual «extensa» sobrecarga la interconexión y, con ello, ralentiza también a las máquinas virtuales vecinas. Estos efectos desaparecen en cuanto paso a Asignación y vuelva a una configuración vNUMA limpia.
Escenarios de error y antipatrones
Con Estricto aumentaría el riesgo de que las asignaciones fallaran y se activara el OOM-Killer. Por eso mantengo espacio libre en el nodo de destino, superviso los intentos fallidos y defino soluciones alternativas (por ejemplo, un redimensionamiento selectivo fuera de las horas de mayor carga). Las páginas enormes transparentes en el siempre-Modo que provoca rutas de latencia Desfragmentación y establos: utilizo reservas fijas o activo THP madvise. El equilibrio automático de NUMA puede mover las páginas de un lado a otro cuando la carga oscila; si detecto patrones de «rebote de páginas», vuelvo a configurar las políticas manualmente. En las máquinas virtuales, Vuelo en globo Y la compresión de memoria es perjudicial para la previsibilidad; desactivo estas funciones en las bases de datos críticas. Las migraciones en vivo entre nodos solo las planifico durante ventanas de inactividad o, primero, traslado los datos por parte de la base de datos, para que la interconexión no se sature de forma secundaria.
Planificación de la capacidad y crecimiento
Tengo previsto una por cada nodo Reserva Establezco valores de entre 10 y 20 % para picos de carga, Autovacuum/Compaction y tareas de mantenimiento periódicas. Si el volumen de datos aumenta, primero escalo a lo largo de los nodos (shards/servicios), en lugar de ampliar a ciegas todo el buffer pool. Evito el „crecimiento silencioso“ estableciendo límites estrictos por nodo y activando alertas tan pronto como disminuyan las tasas de aciertos locales o aumenten las proporciones remotas. En las proyecciones para los próximos trimestres, no solo tengo en cuenta el volumen de datos, sino también Tasas de transacción y cambios en la distribución de los accesos, ya que estos suelen desplazar los conjuntos activos (hotsets) más rápidamente que las propias necesidades de memoria. De este modo, la plataforma se mantiene estable y las ampliaciones se llevan a cabo de forma controlada, sin sacrificar la localidad NUMA.
Balance corto
Optimizo grandes servidores de bases de datos mediante NUMA-Combinar de forma óptima la topología, las políticas y el tamaño de la carga de trabajo. La asignación de memoria local aporta esos milisegundos decisivos, mientras que los accesos remotos no planificados aumentan la latencia P99. En el futuro, planificaré las máquinas virtuales de tal forma que quepan en los nodos o aprovechen claramente el vNUMA. Utilizo de forma selectiva la configuración del sistema operativo, las afinidades y las Huge Pages, compruebo su efecto y solo implemento los cambios tras realizar mediciones. Quien siga estos pasos, obtendrá el rendimiento esperado Actuación con hardware moderno y garantiza un funcionamiento rápido y fiable de las plataformas incluso bajo una carga elevada.
