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

I computer moderni sono costruiti come città frenetiche con molteplici distretti, ognuno dei quali ospita la propria potenza di calcolo e la propria memoria. Quando un programma deve svolgere un lavoro, invia una richiesta a un distretto specifico. Se i dati di cui ha bisogno si trovano già nella memoria locale di quel distretto, il compito avviene istantaneamente. Ma se la richiesta deve viaggiare verso un altro distretto per recuperare informazioni, il viaggio richiede significativamente più tempo. Questo ritardo, causato dalla distanza fisica tra i distretti, è un limite fondamentale di come queste macchine sono costruite. Per decenni, gli ingegneri del software hanno cercato di scrivere programmi che mantenessero i dati e i lavoratori che li utilizzano nello stesso distretto, sperando di evitare i lenti viaggi interstatali. La sfida è che quando molti lavoratori cercano di accedere a una lista condivisa di compiti contemporaneamente, gli ingorghi che creano possono essere dannosi quanto la distanza stessa.

Un ricercatore si è messo in viaggio per costruire un modo migliore per gestire queste liste condivise, specificamente per computer con due distretti distinti. Ha creato un sistema chiamato NumaRing, progettato per mantenere lavoratori e dati locali al proprio distretto ogni volta che sia possibile. L'idea era semplice: se un lavoratore si trova nel primo distretto, deve guardare solo la lista nel primo distretto. Se quella lista si riempie o si svuota, il sistema sposterebbe poi un lotto di compiti nell'altro distretto tutto in una volta, invece di spostarli uno alla volta. Questo approccio prometteva di mantenere fluido il traffico locale veloce, minimizzando al contempo i lenti viaggi a lunga distanza. Tuttavia, quando il ricercatore ha messo alla prova il suo sistema, ha scoperto che le sue migliori intenzioni nascondevano delle trappole. Misurando il sistema con estrema precisione anziché supporre come funzionasse, ha scoperto che due errori specifici rallentavano il sistema più dell'hardware stesso, e che un comune consiglio per risolvere i rallentamenti informatici stava in realtà peggiorando le cose.

Il ricercatore ha iniziato costruendo il suo sistema su un computer cloud con due distretti, ciascuno contenente sedici processori virtuali. Lo ha riempito con un flusso costante di compiti, osservando quanto tempo impiegava un compito per andare dall'inizio della fila alla fine. All'inizio, il sistema era sorprendentemente lento. Il ricercatore si è reso conto che ogni singola volta che un lavoratore cercava di aggiungere o rimuovere un compito, il software poneva una domanda: "In quale distretto mi trovo in questo momento?". Questa domanda sembrava innocua, ma la risposta richiedeva molto tempo per essere calcolata. Il software ricalcolava la posizione da zero ogni singola volta, anche se la posizione del lavoratore cambiava raramente. Questa ripetuta operazione di calcolo era come un conducente che si ferma a ogni incrocio per chiedere indicazioni, anche se sapeva esattamente dove stava andando. Il costo di questa domanda era così alto che assorbiva più di undici volte lo sforzo del compito effettivo di spostamento dei dati.

Una volta che il ricercatore ha risolto questo problema ricordando la posizione e controllandola solo quando necessario, il sistema è accelerato drasticamente. Il numero di compiti elaborati al secondo è aumentato di sei o sette volte. Ma la storia non finiva qui. Quando ha aggiunto più lavoratori alla macchina, il sistema ha incontrato un nuovo muro. I lavoratori stavano ancora aspettando troppo a lungo, specialmente quando il sistema era sotto forte pressione. Scavando più a fondo, ha trovato un secondo problema nel modo in cui i lavoratori condividevano i compiti tra i distretti. Quando un lavoratore aveva bisogno di prendere un lotto di compiti da un altro distretto, ogni singolo lavoratore combatteva per lo stesso piccolo contatore per decidere chi dovesse procedere per primo. Questo creava un enorme ingorgo al cancello. Assegnando a ogni lavoratore il proprio contatore privato da utilizzare, il ricercatore ha rimosso questo collo di bottiglia. Questo cambiamento è stato ancora più drammatico, riducendo il tempo che un lavoratore doveva attendere a metà della fila di oltre duecento volte.

Con questi due grandi interventi in atto, il ricercatore si aspettava che il suo sistema fosse un campione. Aveva eliminato gli errori software che lo frenavano. Tuttavia, quando ha spinto la macchina al suo limite assoluto con trentadue lavoratori, il sistema non riusciva comunque a raggiungere la velocità che aveva originariamente sperato. Il ricercatore ha poi testato una tecnica standard utilizzata per risolvere i rallentamenti informatici chiamata "backoff". L'idea dietro il backoff è che se un lavoratore fallisce nel prendere un compito, dovrebbe attendere un breve momento prima di riprovare, sperando che la coda si diradi. In molte situazioni, questa pausa aiuta. Ma in questo scenario specifico, ad alta pressione, la pausa era un errore. Il ricercatore ha misurato che l'attesa costava effettivamente il quindici o il trenta per cento della velocità totale. La strada più veloce era continuare a provare immediatamente, perché l'hardware stava già gestendo il conflitto in modo efficiente e l'attesa non faceva altro che sprecare tempo.

L'immagine finale emersa è stata quella di un successo accompagnato da limiti invalicabili. Il ricercatore ha costruito con successo un sistema che manteneva i dati locali e ha corretto due bug software principali che causavano enormi ritardi. Ha dimostrato che una comune strategia di ottimizzazione può essere dannosa in determinati scenari ad alta velocità. Eppure, nonostante queste vittorie, il sistema non riusciva comunque a elaborare i compiti alla velocità del design originale. Il ricercatore ha concluso che il rallentamento rimanente non era un errore software che potesse correggere, ma un limite fisico della macchina stessa. La distanza tra i due distretti e la larghezza di banda della strada che li connetteva creavano un soffitto che nessun codice ingegnoso poteva abbattere con quel design. Ha riportato le sue scoperte onestamente, mostrando esattamente dove il suo sistema ha avuto successo, dove ha fallito e perché l'hardware stesso era il giudice finale. Il suo lavoro serve da promemoria che, nel mondo dell'informatica ad alta velocità, comprendere la macchina fisica è importante quanto scrivere il codice.