Facebook ha rilasciato patch che migliorano il controller di memoria Slab in Linux

Romano Gushchin (un ingegnere del software di Facebook) ha pubblicato una serie di patch per l'applicazione di allocazione della memoria del driver slab (un controller di memoria) sulla mailing list di sviluppo del kernel Linux.

Il nuovo driver si distingue per aver spostato la gestione delle pagine di memoria (slab accounting) dal livello delle pagine di memoria al livello degli oggetti del kernel, rendendo possibile la condivisione delle pagine slab tra diversi c-group, anziché allocare cache slab separate per ciascun c-group.

Roman ha trovato quello che chiama un "difetto molto grave" nel controller di memoria slab esistente che porta a un basso utilizzo in questi giorni con i cgroup.

“La vera ragione per cui il design esistente porta a un utilizzo ridotto delle lastre è semplice: le pagine delle lastre vengono utilizzate esclusivamente da un pool di memoria.

Se ci sono solo poche allocazioni di una certa dimensione fatte da un cgroup, o se ci sono alcuni oggetti attivi rimasti dopo che il cgroup è stato rimosso, o il cgroup contiene una singola applicazione a thread che sta a malapena allocando oggetti del kernel, ma ogni volta una nuova CPU: in tutti questi casi l'utilizzo dello slab risultante è molto basso.

Se la contabilità kmem è disabilitata, il kernel può usare lo spazio libero sulle pagine slab per altre allocazioni. «

Il controller di memoria Slab proposto da Romano Gushchin lo scorso anno si è rivelato molto promettente, in quanto consente una maggiore efficienza nell'utilizzo dello slab, riduce la quantità di memoria utilizzata per lo slab del 30-45% e diminuisce significativamente il consumo totale di memoria del core.

Inoltre, le patch implementate hanno indicato che Facebook sta già utilizzando il codice in produzione sui suoi server e che ha ottenuto un risparmio di circa 650-700 MB per i server web front-end , la cache del database e i server DNS, tra gli altri vantaggi.

La riduzione del numero di blocchi non mobili ha anche un effetto positivo sulla frammentazione della memoria. Il nuovo controller di memoria semplifica notevolmente il codice per la gestione dei blocchi ed elimina la necessità di algoritmi complessi per la creazione e la cancellazione dinamica delle cache dei blocchi per ciascun c-group.

Tutti i cgroup per la memoria nella nuova implementazione utilizzano un insieme comune di cache slab e la durata delle cache slab non è più legata alla durata dei vincoli di memoria impostati tramite cgroup.

La contabilità delle risorse più precisa implementata nel nuovo controller slab dovrebbe teoricamente caricare di più la CPU, ma in pratica le differenze si sono rivelate trascurabili.

In particolare, il nuovo controller slab è stato utilizzato per diversi mesi sui server live di Facebook che gestiscono diverse tipologie di carico e finora non sono state rilevate regressioni significative.

La patch contiene un paio di parti semi-indipendenti, che possono anche trovare il loro utilizzo al di fuori del controller di memoria di slab:

  • L'API di caricamento della sottopagina, che può essere utilizzata in futuro per contare altri oggetti che non hanno le dimensioni di una pagina, ad esempio le allocazioni percpu
  • L'API mem_cgroup_ptr, dove vengono contati i puntatori a un memcg, può essere riutilizzata per un'efficiente riparazione di altri oggetti, ad esempio pagecache.

Allo stesso tempo, si registra una significativa riduzione del consumo di memoria : su alcuni host è stato possibile risparmiare fino a 1 GB di memoria, ma questo dato dipende in larga misura dalla natura del carico, dalla quantità totale di RAM, dalla potenza della CPU e dalle caratteristiche di utilizzo della memoria.

Invece di creare un set separato di kmem_caches per ogni cgroup di memoria, vengono utilizzati due set globali: il set root per le assegnazioni cgroup non contabilizzate e il gruppo root e il secondo set per tutti gli altri assegnamenti. Ciò consente di semplificare la gestione della vita dei singoli kmem_caches.

Infine, se siete interessati a saperne di più sulla nuova serie di 19 patch, potete trovarla nella mailing list del kernel.


Aggiungi come fonte preferita in Google