Che la mia stima per linux sia notevolmente scemata nel tempo è cosa risaputa a chi mi conosce, a contribure a questa perdita di fiducia c'è indubbiamente la gestione della Memoria...
Come ai tempi del kernel 2.0 l'ultima versione di linux ha una pessima abitudine di tirare fuori il suo instinto omicida..L'allocazione di memoria di linux per questione di performance viene "sovrastimata", non sto qui a spiegare il perchè, ma sembra che di default Linux faccia OVERBOOKING della memoria, un po come le compagnie aeree fanno con i posti a bordo di un aeroplano e finchè la statistica è a favore ne raccoglie i vantaggi.
Viceversa quando la statistica fallisce,il dolce pinguino una volta ultimato lo spazio a disposizione si comporta un po più bruscamente di una compagnia aerea: UCCIDE.
Incaricato di questo delicato compito è l'OOM-Kill, la gestione della memoria messa alle strette dai processi si comporta come un sicario: sceglie a caso tra i processi più scomodi e gli fa un offerta che non può rifiutare: SIGKILL.
La strategia potrebbe essere sostenibile fino a quando quando oggetto di un KILL e' un child apache, in altre situazioni con altri tipi di applicazioni potrebbe generare un vero problema.
L'episodio che mi ha sinceramente urtato è stato causato dall'azione dell'OOM-Kill, scatenato probabilmente da un browser che aveva fagocitato tutta la memoria disponibile, che ha deciso di fare omaggio di un KILL allo screensaver, lasciando la mia workstation a disposizione di chiunque avesse voluto prenderne possesso: trovare la propria workstation con dei terminali in SSH su altre macchine in bella vista e a disposizione di tutti sinceramente non è un esperienza che ripeterei.Questa strategia di gestione della memoria non è nata di certo con linux ed ha già avuto implementazioni su unix commerciali: IBM con AIX 2.3.xx ed una volta sperimentato questi tipo di problemi, big blue è tornata sui suoi passi.
In sintesi i Linux Kernel developer non solo hanno reinventato la ruota, ma hanno reinventato la ruota quadrata.Sui newsgroup si trovano le informazioni più varie, parecchi suggeriscono a ragione che è possibile disabilitare l' OOM-kill con l'apposito comando:
sysctl -w vm.oom-kill=0
Peccato, che da quel momento è effettivamente vero che il killer sarà a riposo, ma in questo modo nel migliore dei casi si arriverà al kill del primo processo che utilizzerà/richiederà memoria invece di ritornare NULL al malloc o di fargli usare la memoria che aveva richiesto (Riferimento). Cosa non documentata o comunque poco risaputa sono invece i valori di vm.overcommit_memory (Riferimento) che è la variabile di sistema destinata a selezionare le strategie di allocazione della memoria.
#define OVERCOMMIT_GUESS 0
#define OVERCOMMIT_ALWAYS 1
#define OVERCOMMIT_NEVER 2
Il primo, il default è un algoritmo euristico, cioè Linux ci proverà secondo le più recenti statistiche a fare del suo meglio nel overbooking di memoria se poi siamo sfortunati...
Il secondo farà del vostro kernel un perfetto piazzista: assegnerà memoria a tutti anche quando non ne ha più disponibile: un milione di MB per tutti !
Il terzo è quello che dei kernel developer seri avrebbero messo come default: il kernel vi dirà che ha memoria fino a che ne ha, dopo di che da bravo padre di famiglia ve la negherà .
Morale della favola sysctl -w vm.overcommit_memory=2 è; l'opzione più conservativa tra queste e secondo me la giusta candidata al default.
Nella speranza che i developer di applicazioni imparino a gestire gli errori di allocazione, spero nel contempo che almeno i Linux Kernel developer si ravvedano.
Chi vive di speranze, disperato muore
La opzione 2 deve essere accompagnata da un sysctl -w vm.overcommit_ratio=0 per far diventare veramente civile il pinguino.
Continue reading "L'istinto omicida del pinguino"
