NumaRing: Topology-Aware Routing for NUMA-Local MPMC Queues, and What Broke When We Optimized It

Las computadoras modernas están construidas como ciudades bulliciosas con múltiples distritos, cada uno albergando su propia potencia de procesamiento y memoria. Cuando un programa necesita realizar un trabajo, envía una solicitud a un distrito específico. Si los datos que necesita ya se encuentran en la memoria local de ese distrito, la tarea ocurre instantáneamente. Pero si la solicitud debe viajar a un distrito diferente para buscar información, el viaje toma significamente más tiempo. Este retraso, causado por la distancia física entre los distritos, es un límite fundamental de cómo estas máquinas están construidas. Durante décadas, los ingenieros de software han intentado escribir programas que mantengan los datos y a los trabajadores que los usan en el mismo distrito, con la esperanza de evitar los viajes lentos de larga distancia. El desafío es que cuando muchos trabajadores intentan acceder a una lista compartida de tareas al mismo tiempo, los atascos de tráfico que crean pueden ser tan dañinos como la distancia misma.

Un investigador se propuso construir una mejor manera de gestionar estas listas compartidas, específicamente para computadoras con dos distritos distintos. Creó un sistema llamado NumaRing, diseñado para mantener a los trabajadores y sus datos locales en su propio distrito siempre que sea posible. La idea era simple: si un trabajador está en el primer distrito, solo debe mirar la lista en el primer distrito. Si esa lista se llena o se vacía, el sistema movería entonces un lote de tareas al otro distrito de un solo golpe, en lugar de moverlas una por una. Este enfoque prometía mantener el tráfico local rápido fluyendo mientras minimizaba los viajes lentos de larga distancia. Sin embargo, cuando el investigador puso su sistema a prueba, descubrió que sus mejores intenciones tenían trampas ocultas. Al medir el sistema con extrema precisión en lugar de suponer cómo funcionaba, descubrió que dos errores específicos estaban ralentizando el sistema más que el propio hardware, y que un consejo común para solucionar la lentitud de las computadoras era, en realidad, empeorar las cosas.

El investigador comenzó construyendo su sistema sobre una computadora en la nube con dos distritos, cada uno conteniendo dieciséis procesadores virtuales. La llenó con un flujo constante de tareas, observando cuánto tiempo le tomaba a una tarea ir desde el inicio de la línea hasta el final. Al principio, el sistema era sorprendentemente lento. El investigador se dio cuenta de que cada vez que un trabajador intentaba añadir o eliminar una tarea, el software hacía una pregunta: "¿En qué distrito estoy ahora mismo?". Esta pregunta parecía inofensiva, pero la respuesta tardaba mucho en computarse. El software estaba recalculando la ubicación desde cero cada vez, a pesar de que la ubicación del trabajador rara vez cambiaba. Este cálculo repetido era como un conductor que se detiene en cada intersección para pedir direcciones, a pesar de saber exactamente hacia dónde va. El costo de esta pregunta era tan alto que consumía más de once veces el esfuerzo de la tarea real de mover los datos.

Una vez que el investigador solucionó esto recordando la ubicación y verificándola solo cuando era necesario, el sistema se aceleró drásticamente. El número de tareas procesadas por segundo aumentó de seis a siete veces más. Pero la historia no terminó ahí. Cuando añadió más trabajadores a la máquina, el sistema chocó con un nuevo muro. Los trabajadores seguían esperando demasiado tiempo, especialmente cuando el sistema estaba bajo mucha presión. Investigando más a fondo, encontró un segundo problema en la forma en que los trabajadores compartían tareas entre distritos. Cuando un trabajador necesitaba tomar un lote de tareas de otro distrito, cada uno de los trabajadores estaba peleando por el mismo contador pequeño para decidir quién iría después. Esto creaba un enorme atasco en la puerta. Al darle a cada trabajador su propio contador privado para usar, el investigador eliminó este cuello de botella. Este cambio fue aún más dramático, reduciendo el tiempo que un trabajador tenía que esperar en la mitad de la línea en más de doscientas veces.

Con estas dos grandes correcciones implementadas, el investigador esperaba que su sistema fuera un campeón. Había eliminado los errores de software que lo estaban frenando. Sin embargo, cuando llevó la máquina a su límite absoluto con treinta y dos trabajadores, el sistema aún no podía alcanzar la velocidad que originalmente había esperado. El investigador luego probó una técnica estándar utilizada para resolver la lentitud de las computadoras llamada "backoff" (retroceso). La idea detrás del backoff es que si un trabajador falla al intentar agarrar una tarea, debería esperar un breve momento antes de intentarlo de nuevo, con la esperanza de que la línea se despeje. En muchas situaciones, esta pausa ayuda. Pero en este entorno específico de alta presión, la pausa fue un error. El investigador midió que esperar en realidad les costó entre un quince y un treinta por ciento de su velocidad total. El camino más rápido era seguir intentándolo inmediatamente, porque el hardware ya estaba manejando el conflicto de manera eficiente, de modo que esperar solo desperdiciaba tiempo.

La imagen final que surgió fue una de tanto éxito como de límites duros. El investigador construyó con éxito un sistema que mantenía los datos locales y corrigió dos errores de software importantes que causaban retrasos masivos. Demostró que una estrategia de optimización común podía ser perjudicial en ciertos escenarios de alta velocidad. Sin embargo, a pesar de estas victorias, el sistema aún no podía procesar tareas tan rápido como el objetivo de diseño original. El investigador concluyó que la lentitud restante no era un error de software que pudiera corregir, sino un límite físico de la propia máquina. La distancia entre los dos distritos y el ancho de banda de la carretera que los conecta crearon un techo que ninguna programación ingeniosa podría romper con este diseño. Reportó sus hallazgos honestamente, mostrando exactamente dónde tuvo éxito su sistema, dónde falló y por qué el hardware mismo era el juez final. Su trabajo sirve como un recordatorio de que, en el mundo de la computación de alta velocidad, entender la máquina física es tan importante como escribir el código.