Equilibrio NUMA en Linux: ¿desactivarlo o dejarlo activado?

El equilibrio NUMA en Linux determina si el Núcleo Si los accesos a la memoria se localizan automáticamente o si yo mismo controlo la ubicación de forma específica. En esta guía te muestro cuándo dejo activado el «numa balancing» y cuándo lo desactivo para Latencia-Desactiva la seguridad.

Puntos centrales

• Automático Ayuda con cargas de trabajo mixtas sin necesidad de ajustar NUMA.
• Desactivar en casos de pinning, políticas estáticas o latencia elevada.
• Sobrecarga Se genera a raíz de escaneos, fallos y migraciones.
• Configuración controlarlo mediante sysctl o parámetros de arranque.
• Pruebas y medir en lugar de adivinar, y luego decidir.

NUMA en pocas palabras: latencias y localidad

En los sistemas NUMA, el hardware organiza la memoria en varios nodos, cada uno de los cuales CPUs están cerca geográficamente. Los accesos locales requieren menos tiempo que los remotos, lo cual me doy cuenta enseguida de Latencia y noto la falta de ancho de banda. Si un proceso se ejecuta en un nodo, pero los datos se encuentran en otro, pierdo valiosos microsegundos por cada acceso. Es precisamente aquí donde entra en acción el núcleo y optimiza la Localidad de páginas. Quien comprenda la idea básica se dará cuenta rápidamente de que la proximidad entre los núcleos de cálculo y los datos es el camino directo hacia una Actuación.

Cómo funciona el equilibrio automático NUMA

El núcleo observa desde qué núcleos un proceso accede a las páginas y activa de forma selectiva Pista-Faults. De este modo, detecta qué nodo recibe más accesos y, a continuación, traslada las páginas correspondientes a ese nodo. Estas migraciones reducen los accesos remotos y aumentan el tráfico local Tasa de aciertos. Observo este efecto especialmente en cargas de trabajo dinámicas, en las que los subprocesos se desplazan y la memoria se mueve. Quien quiera profundizar en el tema puede consultar las relaciones entre la proximidad de la CPU y la memoria a través de Afinidad de CPU/memoria comprenderlo en la práctica.

Cuándo mantenerlo activo: cargas de trabajo típicas

Dejo la función activa cuando las aplicaciones no tienen su propia lógica NUMA y los procesos suelen cambiar. Los candidatos más habituales son los servidores de aplicaciones, las bases de datos con carga variable y los hosts con muchos reciclaje de comida. En este tipo de configuraciones, el sistema automático acerca más las páginas y los hilos sin que tenga que fijarlos manualmente. Especialmente en servidores con múltiples sockets, el porcentaje de accesos locales aumenta notablemente. Para los administradores con servicios heterogéneos, esto supone una buena Compromiso por la rapidez y el esfuerzo que supone.

Cuándo desactivarlo: criterios claros

Desactivo el modo automático en cuanto me doy cuenta de que estoy haciendo pin o me estoy aclarando. Políticas establezco. Si utilizo numactl, cgroups o MPOL_BIND/MPOL_PREFERRED, ya existe una decisión definitiva sobre las rutas de memoria. En ese caso, los «hint faults» y las migraciones generan un consumo innecesario de Sobrecarga. Lo mismo ocurre en los escenarios en tiempo real o de negociación de alta frecuencia (HFT), en los que cada microsegundo cuenta y la previsibilidad es prioritaria. Quien se adentre más a fondo en la elección de las reglas de colocación, se beneficiará de un análisis de las opciones adecuadas Políticas de memoria.

Comprender y medir los gastos generales

El equilibrado automático genera trabajo: escaneos, Fallos y las migraciones de páginas consumen tiempo de CPU. Esto apenas se nota cuando los accesos remotos disminuyen considerablemente, pero no merece la pena si el diseño ya está almacenado localmente. Por eso, siempre compruebo el efecto real con numastat, perf y métricas significativas Puntos de referencia. Lo interesante es la evolución a lo largo de los minutos, no solo un pico breve. Solo cuando los valores de medición muestren de forma constante que el tráfico local aumenta y las latencias disminuyen, mantendré ese modo.

Configuración: Sysctl y parámetros de arranque

Compruebo el estado a través de /proc o Sysctl y, si es necesario, lo modifico de inmediato, sin un Reinicie. Para realizar pruebas, bastan comandos sencillos como los que aparecen a continuación, que ejecuto en la consola. De forma permanente, configuro el valor en un archivo sysctl para que se mantenga tras un reinicio. Quien quiera configurarlo ya durante el arranque, puede utilizar el parámetro del núcleo numa_balancing=enable o desactivar. Documento cada cambio y anoto en qué fase de la carga de trabajo lo he realizado.

cat /proc/sys/kernel/numa_balancing
echo 0 > /proc/sys/kernel/numa_balancing
sysctl -w kernel.numa_balancing=1
# /etc/sysctl.d/90-numa.conf
# kernel.numa_balancing = 0

Escenarios de contenedores y virtualización

En los servidores con muchas máquinas virtuales y contenedores, la automatización Localización a menudo sacan partido de sus puntos fuertes. Los procesos se inician y finalizan, los cgroups redistribuyen la carga, y el núcleo mantiene la memoria más cerca de los núcleos activos. Lo observo sobre todo en grandes servidores multisocket con varios Nodos. Los casos especiales en los que se aplica un «pinning» estricto a instancias concretas los separo claramente y desactivo allí de forma específica la función automática. Para una clasificación más detallada, resulta útil echar un vistazo a ejemplos prácticos Optimización NUMA en modo host.

Tabla de decisiones para la práctica

El siguiente resumen recoge los escenarios típicos, el efecto esperado y mi clara Recomendación. Las utilizo como punto de partida, pero nunca las sustituyo por los valores medidos en el sistema real. Cada entorno presenta sus propias particularidades, y solo tomo decisiones tras obtener resultados reproducibles Resultados sin duda. Quien actúe de forma sistemática ahorrará tiempo más adelante a la hora de detectar errores y realizar ajustes. Las pequeñas pruebas previas a una puesta en marcha casi siempre dan sus frutos en Constance y la previsibilidad.

Escenario	Efectos típicos	Mi recomendación
Cargas de trabajo estándar sin ajuste NUMA	Más accesos locales, menos accesos remotos Lee	Dejar activo
Bases de datos con carga variable	Localización dinámica de páginas, moderada Escaneos	Dejarlo activo, probarlo
Tiempo real estricto o HFT	La latencia de Hint-Fault es un problema Jitter-Objetivos	Desactivar, fijar manualmente
Asignación manual mediante numactl/cgroups	El sistema automático choca con los fijos Políticas	Desactivar
Políticas de memoria estáticas (MPOL_BIND, etc.)	Las migraciones no aportan ningún beneficio real Ventaja	Desactivar
Entorno de pruebas y análisis	Buena visión de la localidad y Efectos	Dejarlo activo, comprobar las variantes

Guía para las pruebas y la validación

Empiezo con el equilibrador activado y registro los datos locales frente a los remotos Accede a a través de Numastat. A continuación, desactivo la función y repito las mediciones tal y como las había realizado antes. No evalúo las diferencias únicamente en términos de valores medios, sino también en Percentiles. Las pruebas de regresión con perfiles de carga de la producción ofrecen los resultados más fiables. Solo entonces tomo la decisión definitiva sobre si optar por un servidor físico, una máquina virtual o un determinado Servicio.

Obstáculos habituales y mitos

Un error muy extendido es pensar que el modo automático sustituye a cualquier Pinning. Eso no es cierto, ya que los presupuestos de latencia rígidos apenas admiten fallos adicionales. Igualmente errónea es la suposición de que las migraciones siempre gratis... ocurrir. Precisamente en el caso de diseños que, de por sí, son locales, la sobrecarga suele tener un efecto más negativo que positivo. Quien evita los mitos y realiza mediciones precisas, toma decisiones con una precisión significativamente mayor Precisión.

Límites de la automatización e interacciones

AutoNUMA tiene un gran impacto en las páginas anónimas que un proceso asigna por sí mismo. Sin embargo, no todo se puede migrar de forma adecuada. Las páginas fijadas (mlock), la memoria DMA o de dispositivo, las áreas registradas por DAX o RDMA permanecen donde están. Asimismo, las páginas compartidas (por ejemplo, bibliotecas muy compartidas o la caché de páginas) solo aportan un beneficio limitado mediante la migración, ya que varios procesos compiten por Modelo de acceso generar. Además, tengo en cuenta los costes de Páginas enormes transparentes (THP): su migración resulta más costosa que en el caso de las páginas de 4 KiB y puede provocar picos de carga. Quienes persiguen objetivos estrictos de latencia suelen combinar THP=never o madvise con el equilibrio desactivado y un pinning limpio, para evitar sorpresas.

Otro aspecto es la interacción con el programador de la CPU. El programador intenta ubicar los subprocesos donde se encuentran sus datos, mientras que el equilibrador traslada los datos hasta donde se ejecutan los subprocesos. Ambos se complementan, pero en caso de carga irregular pueden provocar momentáneamente Oscilaciones provocar. En la práctica, los intervalos de escaneo atenúan estos efectos; quien observe perfiles de carga extremadamente inestables puede aliviar la situación mediante períodos de escaneo más largos o mediante una fijación de subprocesos más estable.

Ajuste preciso de los parámetros de escaneo

Además del interruptor global, existen parámetros del kernel con los que puedo ajustar con precisión el nivel de agresividad del sistema automático. Los nombres exactos pueden variar ligeramente según la versión del kernel, pero la finalidad sigue siendo la misma:

• kernel.numa_balancing_scan_delay_ms: Tiempo de espera tras un inicio, un «fork» o un «exec» hasta que comienza el primer escaneo.
• kernel.numa_balancing_scan_period_min_ms / _max_ms: Límites mínimo y máximo de la frecuencia de exploración por rango de direcciones de proceso.
• kernel.numa_balancing_rate_limit_mb: Límite máximo por intervalo de tiempo para las migraciones de páginas, con el fin de optimizar el ancho de banda de la memoria.
• kernel.numa_balancing_scan_size_mb: Cantidad de memoria que se marca por cada pasada de exploración (si está disponible).

En configuraciones en las que la latencia es crítica, prefiero aumentar de forma prudente los períodos mínimos y máximos y reducir los límites de frecuencia, en lugar de desactivar inmediatamente el modo automático. Esto suele ofrecer un buen término medio: menos errores de indicación, menos migraciones, pero aún con suficiente capacidad de respuesta ante errores de ubicación reales.

Ejemplos de # (temporales, hasta el reinicio)
sysctl -w kernel.numa_balancing_scan_period_min_ms=60000
sysctl -w kernel.numa_balancing_scan_period_max_ms=240000
sysctl -w kernel.numa_balancing_rate_limit_mb=64

Métricas y diagnóstico en profundidad

Para tomar decisiones bien fundamentadas, analizo métricas que ponen de manifiesto directamente el mecanismo. Utilizo tres fuentes de forma habitual:

• numastat: proporción de accesos locales y remotos en todo el sistema y por proceso.
• /proc//numa_maps: distribución de las páginas de memoria de un proceso entre los nodos, incluyendo indicadores como «active», «file» y «anon».
• /proc/vmstat: los contadores como numa_hint_faults, numa_hint_faults_local y numa_pages_migrated indican si el equilibrador está funcionando y si Éxito tiene.

Resumen de # por proceso
numastat -p 

Vista detallada de #: ¿qué áreas se encuentran en cada lugar?
grep -E 'anon|file' /proc//numa_maps | head

#: visión a nivel del núcleo de la actividad de AutoNUMA
grep -E 'numa_(hint_faults|pages_migrated)' /proc/vmstat

Busco tendencias en los resultados: ¿aumenta de forma constante el porcentaje de accesos locales? ¿Disminuyen al mismo tiempo los «hint faults»? En ese caso, el diseño funciona bien. Si la proporción de acceso local se mantiene estable a pesar de las numerosas migraciones, tiendo a desperdiciar ciclos. Para los objetivos de latencia, compruebo además los percentiles 95 y 99 de los tiempos de respuesta; las pequeñas mejoras en la media pueden verse contrarrestadas por Jitter quedar cubiertos.

Perfiles de carga de trabajo: lo que suele funcionar

La experiencia práctica ha puesto de manifiesto en qué casos AutoNUMA suele ser útil y en cuáles no:

• Servicios de la JVM y servidores de aplicaciones: suelen ofrecer ventajas siempre que no se aplique una estrategia estricta de fijación de subprocesos ni una lógica NUMA propia demasiado agresiva. Algunos entornos de ejecución ofrecen opciones NUMA; si las utilizo de forma estricta, reduzco la automatización o la desactivo.
• Bases de datos relacionales: con una carga variable y cachés mixtas, el sistema automático suele funcionar bien. Sin embargo, si configuro el «pinning» dedicado (de trabajador a nodo, con los búferes compartidos distribuidos de forma estricta), desactivo el equilibrio para garantizar una reproducibilidad clara.
• Almacenamientos en memoria y cachés: un conjunto de datos de trabajo grande y muy activo se beneficia de la ubicación local. Si la instancia funciona en un solo subproceso o está estrictamente fijada, evito migraciones innecesarias desactivando esta función.
• HPC/MPI y códigos científicos: en la mayoría de los casos existen reglas claras de ubicación y enlace (OpenMP/numactl). En este caso, la previsibilidad es más importante que la automatización; por lo tanto, omito el equilibrio NUMA.

Virtualización: vNUMA, «pinning» y migración en vivo

En la interacción entre anfitrión e invitado, tengo en cuenta ambos niveles:

• Si la topología vNUMA del invitado coincide con la topología NUMA física del anfitrión, el equilibrador del invitado puede tomar decisiones acertadas. Si se produce una desviación, surgen „vecindades erróneas“ que AutoNUMA solo compensa de forma limitada.
• Si asigno de forma fija las vCPU a las CPU del host y vinculo la memoria del sistema invitado a nodos concretos, se trata de una política explícita: reduzco o desactivo AutoNUMA a este nivel de máquina virtual para evitar migraciones duplicadas.
• Tras las migraciones en vivo, observo una fase de estabilización: los «hint-faults» aumentan hasta que se alcanza un nuevo equilibrio. Durante este tiempo, preveo un margen para Latencia-puntas.

En hosts de virtualización con alta densidad, donde las instancias se inician y se detienen y los cgroups redistribuyen la carga, la gestión automática en el host suele suponer una ventaja neta. Para máquinas virtuales dedicadas sensibles a los „vecinos ruidosos“, aíslo los recursos de forma clara y configuro las reglas de forma estática.

Valores objetivo pragmáticos y criterios de aceptación

Voy a definir de antemano qué significa „bueno“, para no estar ajustando los detalles sin fin:

• Servicios generales: 70–85%; los accesos locales suelen ser suficientes cuando la varianza es baja.
• SLA de latencia: objetivo >90% a nivel local, límites máximos claros para la tasa de fallos ocultos y percentiles del 99 % estables.
• Con gran consumo de ancho de banda: las migraciones no deben saturar los canales de almacenamiento; ajustar los límites de velocidad y los periodos en consecuencia.

Documento estos umbrales y evalúo pruebas A/B a lo largo de varias fases de carga. No tomo ninguna decisión hasta que los resultados sean repetibles.

Lista de comprobación para la resolución de problemas

• Picos repentinos de latencia: comprueba si hay una correlación entre las migraciones de THP y los picos en «numa_hint_faults». Medida correctiva: aumenta los periodos de escaneo, configura THP en «madvise/never» y, si es necesario, desactiva el equilibrio.
• Apenas se nota el efecto a pesar de la activación: ¿están los subprocesos muy fijados o existen políticas de memoria fijas? En ese caso, el sistema automático entra en conflicto con las especificaciones.
• Alto ritmo de migración, pero aun así muchos accesos remotos: comprobar y aumentar el límite de tasa; como alternativa, estabilizar la carga de trabajo (fijación de subprocesos, mantener las cachés en estado «caliente»).
• Valores de medición poco claros: utiliza la vista por proceso con numastat -p y /proc//numa_maps, no solo los valores globales del sistema.

Detalles que suelen pasarse por alto

• Cargas de trabajo que dependen en gran medida de la caché de páginas: AutoNUMA es especialmente eficaz en páginas anónimas. Quien trabaje principalmente con tareas limitadas por la E/S no debe esperar milagros del equilibrio de carga.
• Cgroups y cpusets: el archivo cpuset.mems limita los nodos a los que un grupo puede acceder. Se trata de un marco rígido dentro del cual actúa el sistema automático.
• Conexión en caliente de la memoria/desconexión de nodos: las topologías dinámicas modifican las distancias; tras los cambios, conviene realizar una nueva prueba y, si es necesario, ajustar los parámetros de escaneo.

Brevemente resumido

Para las cargas de trabajo generales del servidor, dejo activada la función automática, ya que, sin intervención manual, casi Datos lo que genera núcleos activos. En situaciones de tiempo real, trading de alta frecuencia (HFT), fijación manual o políticas fijas, los desactivo para evitar sobrecarga y fluctuaciones. En las fases de prueba, trabajo de forma iterativa: medir, decidir, volver a valide. Mantengo la configuración sencilla, documento cada cambio y compruebo el resultado con indicadores fiables. Así aprovecho las ventajas del hardware NUMA sin innecesarios Riesgos asumir.