{"id":21443,"date":"2026-09-16T08:36:31","date_gmt":"2026-09-16T06:36:31","guid":{"rendered":"https:\/\/webhosting.de\/linux-numa-statistiken-auswerten\/"},"modified":"2026-09-16T08:36:31","modified_gmt":"2026-09-16T06:36:31","slug":"analizar-las-estadisticas-de-numa-en-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-numa-statistiken-auswerten\/","title":{"rendered":"C\u00f3mo interpretar correctamente las estad\u00edsticas NUMA de Linux"},"content":{"rendered":"<p><strong>Linux NUMA<\/strong> Las estad\u00edsticas me muestran en qu\u00e9 medida los procesos conservan su memoria de forma local y d\u00f3nde los accesos remotos aumentan la latencia. Explico c\u00f3mo interpreto estas cifras de forma espec\u00edfica, eval\u00fao las tendencias a lo largo del tiempo y, a partir de ah\u00ed, defino medidas claras de optimizaci\u00f3n para <strong>Actuaci\u00f3n<\/strong> derivar.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>Entender los contadores<\/strong>: numa_hit, numa_miss, numa_foreign, local_node, other_node, interleave_hit<\/li>\n  <li><strong>Evaluar el contexto<\/strong>: Perfil de carga, topolog\u00eda, tipo de carga de trabajo<\/li>\n  <li><strong>Medir las tendencias<\/strong>: Antes\/despu\u00e9s y por intervalos<\/li>\n  <li><strong>Comprobar los procesos<\/strong>: A nivel de todo el sistema frente a por proceso<\/li>\n  <li><strong>Aplicar ajustes<\/strong>: Afinidad, pol\u00edticas, ubicaci\u00f3n<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-analyse-8293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lo que realmente muestran las estad\u00edsticas NUMA<\/h2>\n\n<p>Interpreto las cifras de NUMA como un mapa de <strong>Almac\u00e9n<\/strong> y v\u00edas de transmisi\u00f3n de datos. Un alto <strong>numa_hit<\/strong> significa que las asignaciones se han realizado en el nodo deseado. Por el contrario, \u00abnuma_miss\u00bb indica que el n\u00facleo ha tenido que recurrir a otro nodo. El contador \u00abnuma_foreign\u00bb muestra el equivalente en el nodo de destino y completa el panorama. Con local_node y other_node puedo saber si los accesos se han realizado de forma local o si se ha utilizado memoria remota.<\/p>\n\n<p>Estos valores nunca deben interpretarse de forma aislada, porque <strong>Cargas de trabajo<\/strong> reaccionan de forma muy diferente. Los procesos cortos generan fallos aislados, sin alterar de forma apreciable el rendimiento global. Las pol\u00edticas de intercalaci\u00f3n, por su parte, generan asignaciones distribuidas de forma intencionada, lo que hace que aumente el indicador \u00abinterleave_hit\u00bb. Por eso, siempre compruebo la pol\u00edtica prevista y la carga actual. Solo entonces decido si un valor requiere una intervenci\u00f3n o si se ajusta al dise\u00f1o.<\/p>\n\n<p>Para m\u00ed, la idea central es la siguiente: <strong>Contador<\/strong> Proporcionan se\u00f1ales, no juicios. Busco patrones a lo largo del tiempo, no cifras aisladas. As\u00ed es como detecto si un cambio en el sistema desplaza la localidad. Solo a partir de este panorama de tendencias eval\u00fao si debo reubicar procesos, ajustar pol\u00edticas o establecer restricciones de CPU. Por lo tanto, todo an\u00e1lisis NUMA comienza con una pregunta clara y puntos de medici\u00f3n repetibles.<\/p>\n\n<h2>Interpretar los recuentos de n\u00facleos en su contexto<\/h2>\n\n<p>Siempre comparo <strong>numa_hit<\/strong> y compara \u00abnuma_miss\u00bb entre s\u00ed, en lugar de evaluar valores absolutos. Si aumentan los errores, compruebo al mismo tiempo la evoluci\u00f3n de \u00abnuma_foreign\u00bb en los posibles nodos de destino. Si ambos coinciden, esto indica un desplazamiento real y no un mero artefacto de lectura. \u00ablocal_node\u00bb y \u00abother_node\u00bb completan este panorama con los accesos reales. As\u00ed puedo detectar si una asignaci\u00f3n comenz\u00f3 a nivel local, pero la operaci\u00f3n ley\u00f3 posteriormente memoria m\u00e1s alejada.<\/p>\n\n<p>Un \u00fanico alto <strong>other_node<\/strong> No me molesta que la carga de trabajo se distribuya de forma deliberada. En cambio, los servidores web con muchos trabajadores se benefician de una localizaci\u00f3n consistente. Por eso me fijo en los procesos, no solo en la visi\u00f3n global. En cuanto alg\u00fan servicio se sale de la norma, reviso su ubicaci\u00f3n. Solo cuando aumentan los fallos en todo el sistema busco causas relacionadas con la topolog\u00eda o la carga de trabajo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_numa_meeting_8326.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaciones a lo largo del tiempo: una rutina de medici\u00f3n que da resultados<\/h2>\n\n<p>Tomo las lecturas de los contadores al principio y al final de una <strong>Fase final<\/strong> y calculo la diferencia. Los valores individuales ocultan los efectos, mientras que las diferencias revelan la evoluci\u00f3n. A menudo bastan intervalos repetidos, por ejemplo, de 30 a 60 segundos, para detectar tendencias. Tras implementaciones, actualizaciones del kernel o cambios de hardware, vuelvo a comparar los mismos intervalos. Si entonces se producen m\u00e1s fallos o se desplaza \u00ablocal_node\u00bb, se trata de un cambio real.<\/p>\n\n<p>Estas series temporales abarcan <strong>Error de colocaci\u00f3n<\/strong> m\u00e1s r\u00e1pido que las instant\u00e1neas. Correlaciono las l\u00edneas con la carga de la CPU, los cambios de contexto y el uso de memoria por nodo. As\u00ed puedo ver si los cuellos de botella en la RAM de un nodo provocan movimientos de evasi\u00f3n. O si los nuevos procesos alteran el equilibrio de los nodos. La proporci\u00f3n pura de aciertos y fallos siempre la presento como una evoluci\u00f3n, no como una cifra aislada.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-stat-analysis-4857.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Analizar el sistema en su conjunto y, a continuaci\u00f3n, profundizar en los procesos<\/h2>\n\n<p>Empiezo con la visi\u00f3n general desde <strong>numastat<\/strong> y solo despu\u00e9s compruebo los procesos individuales. Este orden ahorra tiempo, ya que muchos efectos se hacen visibles a nivel global. Para la vista de procesos, utilizo la salida espec\u00edfica de cada proceso con el fin de aislar los servicios que llaman la atenci\u00f3n. En cuanto se identifican los candidatos, ajusto el <strong>Colocaci\u00f3n<\/strong> sobre la asignaci\u00f3n de CPU y memoria. El art\u00edculo sobre este tema recoge una serie de consejos pr\u00e1cticos al respecto: <a href=\"https:\/\/webhosting.de\/es\/servidor-numa-localidad-cpu-memoria-afinidad-optimizacion-nucleo\/\">Afinidad de CPU y memoria<\/a>.<\/p>\n\n<p>Precisamente en el caso de los servicios Java, PHP-FPM o las bases de datos, a menudo basta con una <strong>Afinidad<\/strong>, para reducir significativamente los errores. La orquestaci\u00f3n de contenedores tiende a ocultar estos problemas, ya que los programadores distribuyen los recursos sin tener en cuenta la arquitectura NUMA. Por eso, controlo la asignaci\u00f3n de nodos por pod o m\u00e1quina virtual. Si los conjuntos de CPU y la asignaci\u00f3n de RAM coinciden, el valor de \u00ablocal_node\u00bb aumenta de forma apreciable. Algunos problemas se resuelven en cuanto el proceso se ejecuta cerca del conjunto de datos necesario.<\/p>\n\n<h2>Resumen de los contadores NUMA (tabla)<\/h2>\n\n<p>Cuando eval\u00fao un nuevo sistema, utilizo la siguiente tabla para poder tener en cuenta cada <strong>Cifra clave<\/strong> la clasifico r\u00e1pidamente. En ella se indican el significado, la interpretaci\u00f3n t\u00edpica y las posibles medidas. No la interpreto como un esquema r\u00edgido, sino como una lista de comprobaci\u00f3n. Lo fundamental sigue siendo la comparaci\u00f3n con el perfil de carga y la topolog\u00eda del servidor. Solo en este contexto puedo tomar una decisi\u00f3n acertada.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Contador<\/strong><\/th>\n      <th><strong>Significado<\/strong><\/th>\n      <th><strong>interpretaci\u00f3n<\/strong><\/th>\n      <th><strong>Ac\u00e9rquese a<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>numa_hit<\/td>\n      <td>Asignaci\u00f3n en el nodo deseado<\/td>\n      <td>Un valor alto es positivo<\/td>\n      <td>Mantener la posici\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_miss<\/td>\n      <td>La asignaci\u00f3n se ha desviado a otros nodos<\/td>\n      <td>Mayor riesgo de latencias<\/td>\n      <td>Comprobar la afinidad\/pol\u00edtica<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_foreign<\/td>\n      <td>Asignaci\u00f3n externa en este nodo<\/td>\n      <td>Contraparte de numa_miss<\/td>\n      <td>Analizar los nodos de destino<\/td>\n    <\/tr>\n    <tr>\n      <td>local_node<\/td>\n      <td>Accesos a la memoria local<\/td>\n      <td>Cuanto m\u00e1s alto, m\u00e1s barato<\/td>\n      <td>Proceso m\u00e1s cercano a la RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>other_node<\/td>\n      <td>Accesos a la memoria remota<\/td>\n      <td>Solo es preocupante si no es intencionado<\/td>\n      <td>Comprobar la topolog\u00eda y la carga<\/td>\n    <\/tr>\n    <tr>\n      <td>interleave_hit<\/td>\n      <td>Coincidencias en la distribuci\u00f3n intercalada<\/td>\n      <td>Lo que cabe esperar de la pol\u00edtica de intercalaci\u00f3n<\/td>\n      <td>Evaluar la uniformidad<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Con este <strong>Visi\u00f3n general<\/strong> Decido m\u00e1s r\u00e1pido cu\u00e1ndo intervenir. Un aumento de \u00abnuma_miss\u00bb sin un cambio explicable desencadena un an\u00e1lisis de las causas. Si los valores de interleave_hit se mantienen altos, compruebo si la pol\u00edtica est\u00e1 activa tal y como est\u00e1 previsto. Si other_node muestra un aumento sin que haya aumentado la carga, compruebo si hay cargas de trabajo que lo est\u00e1n desplazando. De este modo, la tabla se convierte en el punto de partida para tomar medidas espec\u00edficas.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprender y utilizar la topolog\u00eda NUMA<\/h2>\n\n<p>Antes de hacer el tuning, compruebo el <strong>Topolog\u00eda<\/strong> del servidor: z\u00f3calos, n\u00facleos, canales de memoria, rutas de latencia. Si un proceso se ejecuta en el z\u00f3calo 0, pero los bloques de trabajo se encuentran en el z\u00f3calo 1, aumenta el tiempo de acceso. Esto reduce el rendimiento y provoca fluctuaciones en los tiempos de respuesta. Los servicios que consumen mucha memoria notan especialmente cualquier distancia innecesaria. Por eso, asigno los procesos que consumen muchos datos a nodos con suficiente RAM libre.<\/p>\n\n<p>Asim\u00e9tricas <strong>Conexiones<\/strong> potencian los efectos, por ejemplo, cuando un nodo utiliza menos canales. En esos casos, traslado de forma selectiva los datos almacenados en cach\u00e9, en lugar de distribuir el proceso. Configuro los hosts de m\u00e1quinas virtuales y contenedores de tal manera que cada instancia tenga una asignaci\u00f3n de nodo coherente. De este modo, reduzco el tr\u00e1fico de datos remoto sin limitar las cuotas. Las caracter\u00edsticas f\u00edsicas de la m\u00e1quina marcan los l\u00edmites, y yo me atengo a ellos.<\/p>\n\n<h2>Entender correctamente los conceptos de \u00abinterleave\u00bb y \u00abbalancing\u00bb<\/h2>\n\n<p>Las pol\u00edticas de intercalaci\u00f3n distribuyen la memoria de forma deliberada entre los nodos, de modo que <strong>Rendimiento<\/strong> aumenta por proceso o disminuyen los puntos cr\u00edticos. En esta configuraci\u00f3n, los valores altos de interleave_hit se consideran deseables. En ese caso, compruebo sobre todo la uniformidad, no la localidad absoluta. AutoNUMA o el equilibrio NUMA pueden ayudar, pero no en todas las situaciones.<\/p>\n\n<p>Decido seg\u00fan la situaci\u00f3n si utilizar la funci\u00f3n autom\u00e1tica <strong>Equilibrio<\/strong> permanece activo. En el caso de servicios consistentes y de larga duraci\u00f3n, suelo optar por enlaces fijos. Ante cargas variables, AutoNUMA puede ofrecer una respuesta adecuada. En el art\u00edculo se ofrece una buena visi\u00f3n general de las ventajas y los riesgos <a href=\"https:\/\/webhosting.de\/es\/desactivar-o-mantener-activado-el-equilibrio-de-numa-para-un-rendimiento-optimo-en-linux\/\">Equilibrio NUMA<\/a>. Solo cuando tengo claros el objetivo y el contexto, elijo el modo adecuado.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Patrones de carga de trabajo: bases de datos, m\u00e1quinas virtuales, servicios web<\/h2>\n\n<p>Las bases de datos son muy sensibles a <strong>Latencia<\/strong> entre la CPU y la RAM. Por eso mantengo la instancia, la cach\u00e9 de b\u00fafer y los fragmentos activos en el mismo nodo. Las m\u00e1quinas virtuales se benefician de conjuntos de CPU bien definidos, adem\u00e1s de la memoria RAM del nodo, para que los sistemas operativos invitados vean rutas consistentes. Los servicios web con muchos trabajadores funcionan mejor cuando los grupos de trabajadores permanecen vinculados a un \u00fanico nodo. Para la estrategia de almacenamiento, utilizo, seg\u00fan el caso, medidas espec\u00edficas <a href=\"https:\/\/webhosting.de\/es\/politicas-de-memoria-numa-servidores-de-bases-de-datos-optimizacion-de-servidores\/\">Pol\u00edticas de memoria NUMA<\/a>.<\/p>\n\n<p>En cambio, los trabajos anal\u00edticos y los escaneos de gran envergadura los realizo en parte <strong>distribuido<\/strong> . En este caso, el interleave suele ofrecer mejores anchos de banda que la localidad estricta. Lo importante es analizar con objetividad los patrones de E\/S de la carga de trabajo. Las operaciones de escritura predominan frente a las de lectura, y los accesos aleatorios frente a los secuenciales. Elijo la pol\u00edtica que se adapta al patr\u00f3n de acceso, no la que suena bien en los libros de texto.<\/p>\n\n<h2>Rutina pr\u00e1ctica de medici\u00f3n y herramientas<\/h2>\n\n<p>Para empezar, me basta con <strong>numastat<\/strong> y la vista de procesos. Anoto las lecturas de los contadores con la fecha, el PID y los indicadores de carga. Es importante realizar las mediciones en intervalos de tiempo id\u00e9nticos. De este modo, se pueden representar con claridad las diferencias entre el antes y el despu\u00e9s. En los intervalos productivos, anoto las diferencias y las correlaciono con las fechas de lanzamiento.<\/p>\n\n<p>En caso de que se observen <strong>Servicios<\/strong> Adem\u00e1s, compruebo la asignaci\u00f3n de la CPU y la visibilidad de los nodos con herramientas como lscpu, numactl y la vista de perf sobre la carga remota. Documento la pol\u00edtica elegida en cada ronda de mediciones. Tras un cambio, vuelvo a realizar las mediciones. Solo cuando las l\u00edneas de tendencia se estabilizan, considero que el efecto ha sido satisfactorio. Cambiar a ciegas puede dar lugar f\u00e1cilmente a mejoras aparentes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_numa_auswertung_7463.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Evitar las interpretaciones err\u00f3neas m\u00e1s comunes<\/h2>\n\n<p>Un alto <strong>interleave_hit<\/strong> No es un error si el intercalado est\u00e1 activado de forma intencionada. Del mismo modo, un \u00fanico fallo es insignificante si el tiempo de ejecuci\u00f3n es largo. Siempre compruebo la densidad y la distribuci\u00f3n a lo largo del intervalo, no solo los picos. Hay quien interpreta \u00abother_node\u00bb como algo negativo en general y pasa por alto el car\u00e1cter de la carga de trabajo. Por eso, primero analizo el objetivo de dise\u00f1o y luego eval\u00fao las cifras.<\/p>\n\n<p>Otro error: <strong>Panorama general<\/strong> Bien, as\u00ed todo va bien. A menudo, los valores at\u00edpicos solo se ocultan en algunos PID. O bien, los programadores de contenedores distribuyen los pods por todos los nodos, aunque lo l\u00f3gico ser\u00eda agruparlos localmente. Solo detecto este tipo de efectos cuando mido por proceso. Sin este nivel de detalle, el an\u00e1lisis queda a medias.<\/p>\n\n<h2>Pasos de puesta a punto que marcan la diferencia<\/h2>\n\n<p>Empiezo con <strong>Colocaci\u00f3n<\/strong>: Procesos en los nodos donde se encuentran o deben encontrarse los datos. A continuaci\u00f3n, configuro la afinidad de la CPU para que los hilos no salten de un z\u00f3calo a otro. A continuaci\u00f3n, configuro la vinculaci\u00f3n de memoria para que el n\u00facleo asigne memoria en la ubicaci\u00f3n deseada. Para cargas variables, compruebo las pol\u00edticas y, si es adecuado, utilizo AutoNUMA.<\/p>\n\n<p>A continuaci\u00f3n, me encargo de <strong>Coherencia<\/strong> En el ciclo de vida: los reinicios, las implementaciones y los ajustes de escala no deben modificar aleatoriamente las referencias entre nodos. Documento las vinculaciones en forma de c\u00f3digo para que sigan siendo reproducibles. A continuaci\u00f3n, vuelvo a realizar mediciones, eval\u00fao las variaciones y decido si es necesario realizar ajustes precisos. Cada cambio merece una prueba clara basada en mediciones.<\/p>\n\n<h2>Ejemplo pr\u00e1ctico: de fracaso a \u00e9xito<\/h2>\n\n<p>Supongamos que una <strong>Base de datos<\/strong> Muestra un mayor valor de \u00abnuma_miss\u00bb y un aumento de \u00abother_node\u00bb bajo carga. La latencia de las consultas fluct\u00faa m\u00e1s. Primero compruebo la asignaci\u00f3n de procesos y observo que, tras una implementaci\u00f3n, el servicio se ejecuta en el nodo A, pero la cach\u00e9 se ha asignado al nodo B. Tras asignar de forma fija la CPU y la memoria al nodo B, la proporci\u00f3n se invierte: el \u00abnuma_hit\u00bb aumenta y los \u00abmisses\u00bb disminuyen. Los tiempos de respuesta se vuelven m\u00e1s constantes y la carga de la CPU desciende ligeramente, ya que desaparecen los accesos remotos.<\/p>\n\n<p>Al mismo tiempo, compruebo la <strong>Pol\u00edtica<\/strong>. La funci\u00f3n \u00abInterleave\u00bb se activ\u00f3 de forma involuntaria y distribuy\u00f3 las asignaciones. Tras cambiar al nodo preferido, la cach\u00e9 permanece cerrada y local. Tras una hora de mediciones, las diferencias confirman la mejora. Solo entonces considerar\u00e9 que el ajuste ha sido un \u00e9xito. Sin esta comprobaci\u00f3n cruzada, una instant\u00e1nea habr\u00eda sido enga\u00f1osa.<\/p>\n\n<h2>M\u00e9tricas y valores de referencia para la pr\u00e1ctica<\/h2>\n\n<p>Para tomar decisiones, utilizo criterios s\u00f3lidos <strong>Probabilidades<\/strong> en lugar de valores brutos individuales. Calculo para cada proceso la tasa de asignaci\u00f3n local_alloc = numa_hit \/ (numa_hit + numa_miss). Adem\u00e1s, eval\u00fao la <strong>\u00cdndice de acceso<\/strong> local_access = local_node \/ (local_node + other_node). Ambos valores juntos indican si la memoria sigue utiliz\u00e1ndose de forma local incluso despu\u00e9s de la asignaci\u00f3n. Como valores orientativos aproximados, me gu\u00edo por lo siguiente: en el caso de servicios en los que la latencia es cr\u00edtica, mi objetivo es que los accesos remotos se mantengan por debajo de 5-10 %. En cargas de trabajo anal\u00edticas de ancho de banda, tolero entre 20 y 30 %, siempre que aumente el rendimiento. Lo decisivo es la <strong>Estabilidad<\/strong> a lo largo del tiempo. Prefiero un valor que se mantenga estable bajo carga a un pico breve con valores perfectos. Anoto estos rangos objetivo en cada revisi\u00f3n, para poder clasificar claramente las mediciones posteriores.<\/p>\n\n<h2>Cgroups, contenedores y problemas con el programador<\/h2>\n\n<p>En entornos de contenedores, lo primero que compruebo es el <strong>cpuset<\/strong>\u2011Asignaci\u00f3n: conjuntos de CPU y <em>cpuset.mems<\/em> Deben abarcar el mismo espacio de nodos; de lo contrario, se producir\u00e1n inevitablemente fallos. Me aseguro de que los pods con solicitudes fijas de CPU no se extiendan a trav\u00e9s de varios nodos NUMA, y de que el programador no distribuya los trabajadores de una misma aplicaci\u00f3n de forma dispersa. En el caso de los tipos \u00abburst\u00bb, limito el n\u00famero m\u00e1ximo de subprocesos por pod de manera que se mantengan dentro de un mismo nodo. Documento el <strong>Dominio NUMA<\/strong> por implementaci\u00f3n y exijo r\u00e9plicas coherentes (un grupo de trabajadores por nodo, no medios grupos repartidos entre dos nodos). Si calculo al l\u00edmite el tama\u00f1o de almacenamiento por pod, me genero una presi\u00f3n innecesaria: un peque\u00f1o margen por nodo evita que el kernel tenga que recurrir prematuramente a otros nodos. Si los contenedores se reinician con frecuencia, me aseguro de que el enlace sea determinista, para que <strong>Arranques en fr\u00edo<\/strong> No es casualidad que le hayan asignado una ubicaci\u00f3n peor.<\/p>\n\n<h2>Alinear de forma coherente las m\u00e1quinas virtuales y vNUMA<\/h2>\n\n<p>En el caso de las m\u00e1quinas virtuales, me centro en <strong>vNUMA<\/strong>: La topolog\u00eda virtual debe coincidir con la f\u00edsica. Distribuyo las vCPU de tal forma que cada nodo vNUMA quede asignado a un \u00fanico nodo NUMA f\u00edsico. Por parte del host, asigno los subprocesos de QEMU\/hipervisor a este dominio y me aseguro de que la memoria RAM asignada se proporcione \u00edntegramente desde este nodo. <strong>Vuelo en globo<\/strong> Y acepto el overcommit con cautela en m\u00e1quinas virtuales en las que la latencia es cr\u00edtica; un ballooning agresivo puede expulsar los hotsets del nodo y disparar los accesos remotos. En el caso de la migraci\u00f3n en vivo, vuelvo a verificar las asignaciones tras el traslado, ya que algunos entornos pierden la asignaci\u00f3n precisa de CPU y memoria. Solo cuando la alineaci\u00f3n vNUMA est\u00e1 correcta, eval\u00fao numastat en todo el sistema; de lo contrario, estar\u00eda solucionando los s\u00edntomas, no la causa.<\/p>\n\n<h2>THP, Hugepages y migraci\u00f3n de p\u00e1ginas<\/h2>\n\n<p><strong>P\u00e1ginas enormes transparentes<\/strong> (THP) pueden ser tanto de ayuda como un obst\u00e1culo. Las p\u00e1ginas m\u00e1s grandes reducen las faltas de TLB y mejoran el ancho de banda, pero si el n\u00facleo no activa las Hugepages hasta m\u00e1s tarde <em>se derrumba<\/em> o se migren, pueden aparecer <strong>Distancias a gran escala<\/strong> surgen. Me gu\u00edo por dos reglas: en primer lugar, la <strong>Pol\u00edtica<\/strong> Definir claramente (por ejemplo, nodo preferido) y, en la medida de lo posible, realizar asignaciones locales de gran tama\u00f1o desde el principio. En segundo lugar, en el caso de cargas de trabajo con cach\u00e9s fijas y de gran tama\u00f1o, configuro, siempre que sea posible, \u00abhugepages\u00bb est\u00e1ticas (hugetlb), que reservo expl\u00edcitamente en un nodo. Esto reduce la fragmentaci\u00f3n y los movimientos de compensaci\u00f3n. Si observo en las series temporales que, tras un tiempo de ejecuci\u00f3n prolongado, el <em>other_node<\/em>\u2011A medida que aumenta la proporci\u00f3n, compruebo si <strong>Migraci\u00f3n de p\u00e1ginas<\/strong> o si se produce compactaci\u00f3n y si los ajustes de THP se ajustan al patr\u00f3n. Para m\u00ed es importante no desactivarlo ni activarlo de forma global: lo decido servicio por servicio y mido el efecto en la localidad y la latencia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-numa-analyse-4746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo interpretar correctamente los conceptos de \u00abReclaim\u00bb, \u00abSwap\u00bb y \u00abMemory\u2011Pressure\u00bb<\/h2>\n\n<p>Si las \u00abMisses\u00bb suben sin que haya un cambio evidente en su posici\u00f3n, busco <strong>presi\u00f3n de almacenamiento<\/strong> por nodo. Los nodos llenos obligan al n\u00facleo a realizar operaciones de recuperaci\u00f3n y compactaci\u00f3n, en parte provocadas por <em>kswapd<\/em> en otro nodo, lo que provoca efectos secundarios en los contadores. Compruebo, para cada nodo, la memoria libre y la carga de la cach\u00e9 de p\u00e1ginas. Activado <strong>Intercambiar<\/strong> puede desplazar los hotsets y hacer que las latencias se disparen; para servicios especialmente sensibles, desactivo el swap o lo limito estrictamente. En los registros y las vistas de \u00abperf\u00bb, busco picos de \u00abReclaim\u00bb durante los picos de carga. El objetivo es disponer de suficiente espacio libre, <strong>locales<\/strong> Mantener la RAM en el nodo de destino para que las asignaciones no se desplacen. Si para ello es necesario reducir las cach\u00e9s, doy prioridad al conjunto de trabajo del servicio frente a la cach\u00e9 de p\u00e1ginas gen\u00e9rica.<\/p>\n\n<h2>Comandos pr\u00e1cticos y an\u00e1lisis<\/h2>\n\n<p>Para la visi\u00f3n del proceso utilizo <code>numastat -p<\/code> y a\u00f1ado: <code>cat \/proc\/\/numa_maps<\/code>, para ver las asignaciones por \u00e1rea (an\u00f3nimas, respaldadas por archivos) y por nodo. <code>numactl --hardware<\/code> me proporciona matrices de latencia y tama\u00f1os de nodos, <code>lscpu --extended<\/code> muestra la asignaci\u00f3n de la CPU a los nodos. Para los accesos a la memoria centrados en rutas remotas, establezco <code>memoria de rendimiento<\/code> para verificar los patrones de carga. Recopilo los deltas de forma reproducible, por ejemplo:<\/p>\n\n<p><em>Rutina de medici\u00f3n<\/em><\/p>\n<ul>\n  <li>t0: guardar numastat (total) y numastat -p para los PID principales<\/li>\n  <li>30-60 s de ejercicio de esfuerzo, fase de carga id\u00e9ntica<\/li>\n  <li>t1: volver a leer numastat, calcular los deltas por contador<\/li>\n  <li>Registrar los valores de la CPU en paralelo, los cambios de contexto y los valores de la memoria de los nodos<\/li>\n<\/ul>\n\n<p>A continuaci\u00f3n, calculo la <strong>Probabilidades<\/strong> y se\u00f1alo qu\u00e9 procesos se desv\u00edan significativamente de las tendencias generales del sistema. Cuando persiste la incertidumbre, repito la medici\u00f3n al menos tres veces. Solo considero fiables los desv\u00edos que son consistentes. Para una supervisi\u00f3n continua, asocio los contadores a series temporales y los vinculo con los metadatos de las versiones; de este modo, puedo detectar <strong>Puntos de regresi\u00f3n<\/strong> inmediatamente.<\/p>\n\n<h2>Lista de comprobaci\u00f3n para un ajuste NUMA sistem\u00e1tico<\/h2>\n\n<ul>\n  <li>Definir el objetivo: latencia frente a rendimiento, carga fija frente a variable<\/li>\n  <li>Captura de la topolog\u00eda: nodos, latencias, reservas de RAM libre por nodo<\/li>\n  <li>Medir los valores de referencia: numastat total y por proceso; calcular los porcentajes<\/li>\n  <li>Corregir la asignaci\u00f3n: afinidad de la CPU, vinculaci\u00f3n de memoria, pol\u00edticas<\/li>\n  <li>Configurar contenedores\/m\u00e1quinas virtuales: cpuset.cpus = nodo, cpuset.mems seg\u00fan corresponda; asignar correctamente vNUMA<\/li>\n  <li>Elegir THP\/Hugepages de forma consciente, sin perder de vista la fragmentaci\u00f3n<\/li>\n  <li>Reducir la presi\u00f3n de memoria: comprobar el margen de memoria por nodo y la estrategia de intercambio<\/li>\n  <li>Medici\u00f3n posterior: comparar los deltas, garantizar la estabilidad a lo largo del tiempo<\/li>\n  <li>Documentaci\u00f3n: Enlaces como c\u00f3digo, notas de la versi\u00f3n con contexto NUMA<\/li>\n<\/ul>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Analizo los datos NUMA mediante <strong>Se\u00f1ales<\/strong> En este contexto, v\u00e9ase: pares de contadores, series temporales y vista de procesos. Los valores clave \u00abnuma_hit\u00bb, \u00abnuma_miss\u00bb, \u00abnuma_foreign\u00bb, \u00ablocal_node\u00bb, \u00abother_node\u00bb e \u00abinterleave_hit\u00bb me indican la localidad, los movimientos de evasi\u00f3n y las estrategias de distribuci\u00f3n. Tomo mis decisiones bas\u00e1ndome en la topolog\u00eda y la carga de trabajo, no en valores l\u00edmite r\u00edgidos. El ajuste comienza con la ubicaci\u00f3n, la afinidad, una pol\u00edtica adecuada y una rutina de medici\u00f3n rigurosa. As\u00ed consigo un rendimiento constante <strong>Actuaci\u00f3n<\/strong>, porque la CPU y la RAM se adaptan a la aplicaci\u00f3n y los accesos a datos remotos son poco frecuentes.<\/p>","protected":false},"excerpt":{"rendered":"<p>C\u00f3mo interpretar correctamente las estad\u00edsticas NUMA de Linux: comprender las estad\u00edsticas NUMA, comprobar la localidad de la memoria y mejorar de forma espec\u00edfica el rendimiento del servidor.<\/p>","protected":false},"author":1,"featured_media":21436,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21443","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"73","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux NUMA","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21436","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21443","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21443"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21443\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21436"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}