Servidor de equilibrio NUMA: Optimización del acceso a la memoria para hardware de alojamiento

Muestro cómo Servidor de equilibrio NUMA en el hardware de alojamiento agiliza el acceso a la memoria y reduce las latencias vinculando procesos y datos al nodo NUMA apropiado. El factor decisivo es la Optimización del acceso a la memoria mediante el acceso local, la colocación de tareas y la migración selectiva de páginas a hosts Linux con muchos núcleos.

Puntos centrales

• NUMA separa las CPU y la memoria en nodos; los accesos locales proporcionan bajo Latencia.
• Automático NUMA Balancing migra páginas y coloca tareas cerca del nodo.
• Tamaño de la máquina virtual por nodo, de lo contrario existe el riesgo Basura NUMA.
• Herramientas as numactl, lscpu, numad show Topología y uso.
• SintonizaciónEstados C, Intercalación de nodos de, Páginas enormes, afinidades.

Qué es NUMA y por qué es importante para el alojamiento

NUMA divide un sistema multiprocesador en Nodo, que contienen cada uno sus propias CPU y memoria local, lo que hace que los accesos cercanos sean más rápidos que los remotos. Mientras que UMA envía todos los núcleos a una ruta común, NUMA evita los cuellos de botella debidos a local canales de memoria por nodo. En entornos de alojamiento con muchas máquinas virtuales en paralelo, cada milisegundo de latencia se acumula, por lo que cada solicitud se beneficia de forma apreciable. Si desea más información de fondo, puede encontrar más información sobre Arquitectura NUMA. Para mí, una cosa es cierta: si entiendes y utilizas los nodos, obtienes más ancho de banda con el mismo hardware.

Equilibrado NUMA automático en el núcleo Linux: cómo funciona

El kernel escanea periódicamente partes del espacio de direcciones y „desmapea“ páginas para que un fallo de insinuación pueda óptimo nodo visible. Si se produce el fallo, el algoritmo evalúa si merece la pena migrar la página o mover la tarea y evita movimientos innecesarios. Migrar en caso de fallo aporta Datos más cerca de la CPU en ejecución, la colocación de tareas NUMA mueve los procesos más cerca de su memoria. El escáner distribuye su trabajo pieza a pieza para que la sobrecarga se mantenga dentro del ruido de la carga normal. De este modo, se consigue un ajuste continuo que reduce la latencia sin necesidad de reglas de fijación estrictas.

Optimización del acceso a la memoria: la local gana a la remota

Los accesos locales utilizan el Controlador de memoria de su propio nodo y minimizar los tiempos de espera de la interconexión. Los accesos remotos cuestan ciclos a través de QPI/UPI o Infinity Fabric y minimizan así el tiempo de acceso efectivo. Ancho de banda. Un número elevado de núcleos agrava este efecto porque cada vez hay más núcleos compitiendo por las mismas conexiones. Por lo tanto, planifico de modo que el código caliente y los datos activos se reúnan en un nodo. Si no se tiene esto en cuenta, se regalan puntos porcentuales que determinan el tiempo de respuesta o de espera durante los picos de carga.

Tamaño de las máquinas virtuales, NUMA trashing y recorte de hosts

Dimensiono las VMs de forma que las vCPUs y la RAM quepan en un nodo NUMA para evitar accesos cruzados entre nodos. A menudo, 4-8 vCPUs por nodo ofrecen un buen rendimiento. Índices de aciertos, dependiendo de la plataforma y la jerarquía de la caché. Las páginas enormes también ayudan porque el TLB funciona de forma más eficiente y las migraciones de página se producen con menos frecuencia. Si es necesario, configuro Afinidad CPU para que los procesos de latencia crítica vinculen los subprocesos a los núcleos adecuados (para obtener más información, consulte Afinidad CPU. Si se reparten las máquinas virtuales entre varios nodos, se corre el riesgo de que se produzca un trashing NUMA, es decir, un ping-pong de datos e hilos.

Herramientas en la práctica: numactl, lscpu, numad

Con „lscpu“ leo Topología y los nodos NUMA, incluida la asignación de los núcleos. „numactl -hardware“ me muestra la memoria por nodo y las distancias disponibles, lo que facilita la evaluación de las rutas. El demonio „numad“ supervisa la utilización y ajusta dinámicamente las afinidades cuando se mueven los centros de carga. Para escenarios fijos, utilizo „numactl -cpunodebind/-membind“ para fijar explícitamente los procesos y la memoria. De este modo, combino el equilibrio automático con especificaciones específicas y controlo el resultado mediante „perf“, „numastat“ y „/proc“.

Cómo mido el impacto: Cifras clave y mandos

Siempre califico NUMA-Tuning mediante Series de mediciones, no por intuición. Tres indicadores han demostrado su eficacia: Relación entre páginas vistas locales y remotas, tasa de migración y distribución de la latencia (P95/P99).

• En todo el sistemanumastat„ muestra los accesos locales/remotos y las páginas migradas por nodo.
• Relacionado con el proceso: „/proc//numa_maps“ revela dónde se encuentra la memoria y cómo se ha distribuido.
• Vista del programadorCpus_allowed_list„ y real “Cpus_allowed„ comprueban si se aplican las vinculaciones.

# Vista de todo el sistema
numastat
numastat -m

# Distribución y enlaces relacionados con el proceso
pid=$(pidof )
numastat -p "$pid"
cat /proc/"$pid"/numa_maps | head
cat /proc/"$pid"/status | grep -E 'Cpus_allowed_list|Mems_allowed_list'
taskset -cp "$pid"

# Contador del núcleo para la actividad NUMA
grep -E 'numa|migrate' /proc/vmstat

# Eventos de rastreo para análisis profundos (activar por poco tiempo)
echo 1 > /sys/kernel/debug/tracing/events/mm/enable
sleep 5; cat /sys/kernel/debug/tracing/trace | grep -i numa; echo 0 > /sys/kernel/debug/tracing/events/mm/enable

Comparo en cada caso A/B: unbound vs. bound, balanceo automático on/off y diferentes VM slices. El objetivo es una clara reducción de los accesos remotos y del ruido de migración, así como unas latencias P95/P99 más ajustadas. Sólo cuando los valores medidos mejoren de forma estable me encargaré del ajuste.

Ajustes de BIOS y firmware que funcionan de verdad

Desactivo „Node Interleaving“ en la BIOS para que la estructura NUMA permanezca visible y el kernel local puede planificar. Los estados C reducidos estabilizan los picos de latencia porque es menos probable que los núcleos caigan en estados de sueño profundo, lo que ahorra tiempo de activación. Asigno los canales de memoria simétricamente para que cada nodo pueda utilizar su máxima capacidad de memoria. Ancho de banda conseguido. Pruebo los prefijadores y las funciones RAS con perfiles de carga de trabajo, ya que ayudan o perjudican en función del patrón de acceso. Mido cada cambio con respecto a una línea de base y solo entonces adopto la configuración de forma permanente.

Parámetros del kernel y sysctl que marcan la diferencia

Afinar el núcleo me ayuda, Sobrecarga y Tiempo de respuesta del equilibrador para que coincida con la carga de trabajo. Empiezo con valores predeterminados conservadores y avanzo paso a paso.

• kernel.numa_balancingActivación/desactivación del equilibrado automático. Lo dejo activado para cargas en movimiento; lo desactivo para servicios especiales estrictamente con clavijas a modo de prueba.
• kernel.numa_balancing_scan_delay_msTiempo de espera antes de la primera exploración tras la creación del proceso. Seleccione mayor si se ejecutan muchas tareas de corta duración; menor para servicios de larga duración que requieren una proximidad rápida.
• kernel.numa_balancing_scan_period_min_ms / _max_msAncho de banda de los intervalos de escaneo. Los intervalos estrechos aumentan la capacidad de respuesta, pero también la carga de la CPU.
• kernel.numa_balancing_scan_size_mbProporción del espacio de direcciones por exploración. Demasiado grande genera tormentas de fallos indirectos, demasiado pequeño reacciona con lentitud.
• vm.zone_reclaim_modeCuando la memoria es escasa, el kernel favorece la recuperación local sobre la asignación remota. Para cargas de trabajo de alojamiento general suelo dejar 0; Para servicios de memoria local estrictamente sensibles a la latencia, pruebo cuidadosamente valores más altos.
• Páginas transparentes enormes (THP)En „/sys/kernel/mm/transparent_hugepage/{enabled,defrag}“ suelo poner a madvise y una desfragmentación conservadora. Los perfiles „siempre“ duros aportan ventajas a la TLB, pero corren el riesgo de atascarse debido a la compactación.
• sched_migration_cost_nsEstimación del coste de la migración de tareas. Los valores más altos amortiguan la redistribución de los planificadores agresivos.
• cgroups cpusetCon cpuset.cpus y cpuset.mems Separo los servicios limpiamente por nodos y me aseguro de que Primer toque permanece dentro de los nodos permitidos.

# Ejemplo: equilibrio conservador pero con capacidad de respuesta
sysctl -w kernel.numa_balancing=1
sysctl -w kernel.numa_balancing_scan_delay_ms=30000
sysctl -w kernel.numa_balancing_scan_period_min_ms=60000
sysctl -w kernel.numa_balancing_scan_period_max_ms=300000
sysctl -w kernel.numa_balancing_scan_size_mb=256

# Utilice THP con cuidado
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo defer > /sys/kernel/mm/transparent_hugepage/defrag

Sigue siendo importante: Cambie sólo un tornillo de ajuste por ronda de prueba y compruebe el efecto con la misma curva de carga. Así es como desentraño la causa y el efecto.

Posicionar correctamente las cargas de trabajo: Bases de datos, cachés, contenedores

Las bases de datos se benefician cuando los buffer pools permanecen locales por nodo NUMA y los threads están vinculados cerca de sus heaps. En las cachés en memoria, establezco la fragmentación en Nodo para evitar consultas remotas. Las plataformas de contenedores reciben límites y peticiones para que los pods no salten de un nodo a otro. Para las reservas de memoria, utilizo Huge Pages, que facilita el almacenamiento de hotsets en Cachés encajar. En el cuadro siguiente se resumen las estrategias y los efectos típicos.

Estrategia	Utilice	Efecto esperado	Nota
Primer toque	Bases de datos, JVM heaps	Asignación local	Ejecutar la inicialización en el nodo de destino
Intercalar	Carga ampliamente distribuida	Distribución uniforme	No es óptimo para puntos de acceso
Fijación de tareas	Servicios de latencia crítica	Latencia constante	Menos flexible durante los cambios de carga
Equilibrado automático	Cargas de trabajo mixtas	Proximidad dinámica	Sopesar los gastos generales con los beneficios
Páginas enormes	Grandes pilas, cachés	Menos fallos en la TLB	Planificar reservas limpias

Virtualización: NUMA virtual, programador y personalización de invitados

Virtual NUMA transmite la topología del host al sistema operativo huésped de forma simplificada, de modo que el primer toque y la Asignador trabajar con sensatez. Los programadores del hipervisor prestan atención a la proximidad de los nodos cuando distribuyen las vCPU y migran las máquinas virtuales. Rara vez alineo grandes máquinas virtuales en varios nodos a menos que la carga de trabajo se distribuya ampliamente y se beneficie del intercalado. En el invitado, personalizo los heaps de las JVM o las bases de datos para que permanezcan locales en los nodos NUMA visibles. Para la gestión de memoria en el huésped, un vistazo a Memoria virtual, para controlar el tamaño de las páginas y el intercambio.

Proximidad PCIe: NVMe y NIC en los nodos adecuados

Si es posible, asigno SSD NVMe y NIC rápidas al nodo en el que el Carga de trabajo se está ejecutando. Esto evita que las peticiones de E/S crucen la interconexión y añadan latencia. Vinculo las NIC multicola a conjuntos de núcleos de un nodo con RSS/RPS para que las IRQ permanezcan locales. Para las pilas de almacenamiento, merece la pena dividir los grupos de hilos nodo por nodo. Si prestas atención a esto, reducirás notablemente las latencias P99 y crearás margen para los picos de carga.

IRQ y afinidad de colas en la práctica

Primero compruebo en qué Nodo NUMA dispositivos y pin IRQs y colas apropiadamente. De este modo se garantiza el mantenimiento de la localidad de la ruta de datos.

# Asignación de dispositivo a nodo
cat /sys/class/net/eth0/dispositivo/nodo_numa
cat /sys/bloque/nvme0n1/dispositivo/nodo_numa

# Establecer afinidad IRQ específicamente (ejemplo: núcleos 0-7 de un nodo)
irq=
echo 0-7 > /proc/irq/$irq/smp_affinity_list

# Asignar colas NIC a núcleos (RPS/RFS)
for q in /sys/class/net/eth0/queues/rx-*; do echo 0-7 > "$q"/rps_cpus; done
sysctl -w net.core.rps_sock_flow_entries=32768
for q in /sys/class/net/eth0/queues/rx-*; do echo 4096 > "$q"/rps_flow_cnt; done

# Mejorar la afinidad de la cola NVMe
echo 2 > /sys/block/nvme0n1/queue/rq_affinity
cat /sys/block/nvme0n1/queue/scheduler # preferido "ninguno

„Ejecuto “irqbalance" con conocimiento del nodo o lo pongo en Excepciones para las interrupciones en caliente. El resultado son latencias más estables, menos saltos IRQ entre nodos y un aumento apreciable de los impactos de E/S locales.

Vinculación estática frente a equilibrio dinámico: el término medio

Utilizo „taskset“ y cgroups para establecer reglas duras cuando es determinista Latencia cuenta. Dejo activo el equilibrio NUMA automático cuando la carga se mueve y necesito proximidad adaptativa. Una mezcla suele funcionar mejor: pines duros para los hotpaths, límites más abiertos para el trabajo auxiliar. Compruebo regularmente si las migraciones aumentan notablemente, ya que esto indica una mala planificación. El objetivo sigue siendo elegir las ubicaciones de los datos y los hilos de tal manera que la migración siga siendo rara pero posible.

NUMA en contenedores y Kubernetes

Traigo un contenedor cpusets y Páginas enormes en línea. Asigno pods/contenedores a un nodo NUMA almacenando cantidades coherentes de CPU y memoria. En las orquestaciones, establezco políticas que favorecen las asignaciones a un único nodo y respetan así el primer toque.

• Tiempo de ejecución del contenedor: „-cpuset-cpus“ y „-cpuset-mems“ mantienen juntas las tareas y la memoria; asignan páginas enormes como recursos.
• Topología/Gestor de CPULas asignaciones estrictas o preferentes garantizan que se asignen núcleos y áreas de memoria relacionados.
• Calidad de servicio garantizadaLas solicitudes/límites fijos minimizan la redistribución por parte del planificador.

Dividí conscientemente sidecars y procesos auxiliares a otros núcleos en del mismo nodo para que el hotpath permanezca inalterado pero no entre en la carrera entre nodos.

Comprensión de las topologías de CPU: CCD/CCX, SNC y Cluster-on-Die

Las CPU de servidor actuales dividen los zócalos en Subdominios con sus propias cachés y rutas. Esto lo tengo en cuenta a la hora de recortar núcleos/juntas:

• AMD EPYCCCD/CCX y „NUMA por zócalo“ (NPS=1/2/4) influyen en la finura de NUMA. Más nodos (NPS=4) aumentan la localidad, pero requieren un pinning limpio.
• IntelSub-NUMA Clustering (SNC2/4) divide LLC en clusters. Bueno para cargas con memoria limitada, siempre que el SO y la carga de trabajo sean conscientes de los nodos.
• L3 proximidadVinculo hilos que utilizan los mismos heaps en el mismo cluster L3 para ahorrar tráfico de coherencia y saltos entre clusters.

Estas opciones actúan como un multiplicador: si se utilizan correctamente, aumentan Localidad Además, si no se configuran correctamente, aumentan la fragmentación y el tráfico remoto.

Introducción paso a paso y plan de desmantelamiento

Nunca introduzco el ajuste NUMA „big bang“. Un resistente Plan evita sorpresas:

1. Línea de baseTopología de hardware, latencias P50/P95/P99, rendimiento, captura de tasas numastat.
2. HipótesisFormular un objetivo específico (por ejemplo, acceso remoto -30%, P99 -20%).
3. Un pasoCambie sólo un tornillo de ajuste (por ejemplo, corte VM, cpuset, política THP, intervalos de exploración).
4. CanariasPrueba en 5-10% de la flota bajo carga real, mantener rollback listo.
5. ValoraciónComparar valores medidos, definir ventanas de regresión, registrar efectos secundarios.
6. DespliegueDesenrollar eje por eje, medir de nuevo después de cada eje.
7. MantenimientoVuelva a medir trimestralmente (las actualizaciones del kernel, el firmware y la carga de trabajo modifican el óptimo).

Esto garantiza que las mejoras sean reproducibles y puedan revertirse en cuestión de minutos en caso de error.

Errores comunes y cómo evitarlos

Un paso en falso típico es activar el intercalado de nodos en la BIOS, lo que oculta la topología NUMA y Equilibrio más difícil. Igualmente desfavorable: VMs con más vCPUs de las que ofrece un nodo, además de páginas enormes reservadas de forma poco limpia. Algunos administradores fijan todo a cal y canto y pierden así toda flexibilidad cuando cambian las cargas de trabajo. Otros confían completamente en el kernel, aunque los hotspots duros requieren reglas claras. Yo registro series de mediciones, reconozco los valores atípicos desde el principio y ajusto la configuración y las políticas paso a paso.

• THP „siempre“ sin control: la compactación imprevista altera la latencia. Prefiero utilizar „madvise“ y reservar específicamente páginas enormes.
• vm.zone_reclaim_mode Demasiado agresivo: la recuperación local puede hacer más mal que bien en el momento equivocado. Primero medir, luego afinar.
• irqbalance ciegoLas IRQs no críticas se mueven a través de los nodos. Establezco excepciones o máscaras fijas para hotpaths.
• Mezcla de intercalado + hard pinningLas políticas contradictorias crean ping-pong. Me decido por una línea clara para cada servicio.
• Cpusets suciosLos contenedores ven un nodo, pero asignan memoria a otros nodos. Establezca siempre „cpuset.mems“ de forma coherente con el conjunto de CPU.
• Características Sub-NUMA activados pero no utilizados: Más nodos sin planificación aumentan la fragmentación. Activar solo después de las pruebas.

Brevemente resumido

NUMA Balancing Server reúne procesos y datos de forma selectiva, haciendo que los accesos locales sean más frecuentes y eficientes. Latencias se acortan. Con un tamaño de máquina virtual adecuado, una configuración de BIOS limpia y herramientas como numactl, se crea una topología clara que el núcleo utiliza. NUMA virtual, páginas enormes y afinidades complementan el equilibrio automático en lugar de sustituirlo. La conexión de dispositivos de E/S cerca de los nodos y el uso de hotpaths eliminan el costoso acceso remoto. De este modo, el hardware de alojamiento se escala de forma fiable y cada segundo de CPU proporciona más carga útil.