Come risolvere il rompicapo dell'out-of-memory killer

Recentemente abbiamo introdotto IBM Instana Crash Detector, che rileva e segnala automaticamente le interruzioni anomale dei processi su tutte le macchine Linux che eseguono il kernel Linux 4.8 o superiore. La piattaforma IBM Instana utilizza le funzionalità Extended Berkeley Packet Filter (eBPF) del kernel Linux per collegarsi al kernel stesso e iniziare ad ascoltare le terminazioni dei processi. Eventuali terminazioni anomale vengono segnalate all'agente host, che le confronta con i processi monitorati per evitare rumori relativi a processi non pertinenti e quindi invia le informazioni a monte al backend IBM Instana. Questa funzionalità ha dimostrato di essere un punto di svolta per i nostri clienti che si occupano della risoluzione dei problemi.

Con Crash Detector, il software IBM Instana fornisce i dati critici per molti dei problemi che influiscono sulle prestazioni delle applicazioni dei nostri clienti. Ora stiamo migliorando questa funzionalità aggiungendo a Crash Detector gli eventi out-of-memory killer (OOM killer) e si tratta di un'aggiunta incredibilmente preziosa data la sua rilevanza per le applicazioni containerizzate.

Il cloud può far sembrare che, se si dispone di un budget sufficiente, si abbia a disposizione una potenza di calcolo infinita. Tuttavia, questa potenza di calcolo è disponibile "a fette". Gli host (fisici e virtuali), i container e le funzioni sono tutti soggetti a limitazioni sulla quantità di memoria che è possibile allocare.

Su Linux, l'out-of-memory killer (OOM) è un processo incaricato di impedire ad altri processi di esaurire collettivamente la memoria dell'host. Quando un processo tenta di allocare più memoria di quella disponibile, il processo che ha il punteggio di inattendibilità più alto, in base ad esempio alla quantità di memoria allocata al di sopra di quella consentita, riceverà un segnale OOM. Fondamentalmente, ciò significa: "Così non va bene. Interrompi ciò che stai facendo o fai in modo che alcuni dei tuoi processi secondari si fermino, altrimenti non potrai più proseguire".

Si noti che il processo che attiva l'OOM potrebbe non essere il processo che riceve il segnale OOM. Un'applicazione che non ha aumentato di recente l'utilizzo della memoria può ricevere all'improvviso un segnale OOM perché troppe altre applicazioni sono state avviate sullo stesso host.

La meccanica di un segnale OOM sembra dura, ma in realtà è un meccanismo molto efficace per prevenire l'esaurimento della memoria sugli host, soprattutto nel caso di applicazioni non dimensionate correttamente o di troppe applicazioni in esecuzione in parallelo (ad esempio, gli host non sono dimensionati correttamente per il carico di lavoro).

Per piattaforme containerizzate come Kubernetes, Cloud Foundry e Nomad, l'uso della memoria, sia in termini di dimensionamento appropriato delle applicazioni sia di quante applicazioni eseguire contemporaneamente su un host, è ancora più importante. In genere, non si pianifica nel dettaglio quali applicazioni saranno in esecuzione su un dato nodo. In molte configurazioni, i container verranno assegnati in base a una certa logica dall'orchestratore. L'imposizione del consumo massimo di memoria è fondamentale per i container e i gruppi di controllo (cgroup), che sono alla base di quasi tutte le tecnologie di container su Linux. Utilizzano anche il sistema OOM killer per garantire che i processi in esecuzione nello stesso gruppo (ad esempio un container) non allochino più memoria di quella consentita. Quando i processi nei container tentano di allocare più memoria di quella consentita, alcuni vengono terminati, spesso portando con sé anche i container corrispondenti.

Su larga scala, tutto è più difficile, compreso il dimensionamento. Più container vengono eseguiti nei propri ambienti, più è difficile capire quando, come e perché alcuni di essi si bloccano. L'OOM killer può creare situazioni malsane per le tue applicazioni in cui qualcosa si blocca sempre da qualche parte e poi viene riavviato, creando una serie continua di errori per gli utenti finali che alterano i tuoi obiettivi di livello di servizio (SLO) e sono davvero difficili da risolvere.

Scoprire perché un singolo processo è stato eliminato dall'OOM killer dipende molto dalla tecnologia utilizzata. Alcuni pacchetti software lo registreranno nei propri registri. Oppure si può finire per eseguire un comando come il seguente sui propri host, su ciascuno di essi:

     #CentOS
     grep -i "out of memory" /var/log/messages
     #Debian / Ubuntu
     grep -i "out of memory" /var/log/kern.log

Sembra una cosa semplice, ma non è certo il tipo di operazione che si vuole eseguire sul proprio parco macchine di produzione per cercare di capire perché MySQL non funziona più alle 03:00 del mattino. Soprattutto quando si tratta di un'intuizione, dal momento che nient'altro sembra spiegare perché il processo del database non è più presente.

In altre parole, l'OOM killer è un sistema di innegabile importanza ed efficacia per l'affidabilità che, però, non riesce a fornire un'osservabilità sufficiente. Ma la piattaforma IBM Instana è qui per risolvere il problema.

Basandosi ulteriormente sulle fondamenta di eBPF che hanno portato a Crash Detector, il software IBM Instana è ora dotato di un rilevatore di OOM killer pronto all'uso. Quando il processo viene monitorato dal software IBM Instana, riceve un segnale OOM in tempo reale. Non solo il fatto che sia accaduto, ma anche come è stata risolta la situazione (cioè, quale processo è stato interrotto).

Come per la maggior parte delle funzioni di IBM Instana, è sufficiente installare l'agente host di IBM Instana e osservare OOM killer mentre svolge la sua cupa attività. Il programma mostra anche la quantità di memoria allocata dal processo interrotto al momento dell'evento, in modo da poter capire perché è stato contrassegnato da OOM killer come “cattivo”.

Senza gli strumenti adeguati, determinare come e perché un processo è stato terminato o perché un processo è stato interrotto con un OOM killer può richiedere ore, se non giorni. Con IBM Instana Crash Detector, gli utenti ora hanno immediatamente la causa principale di ogni interruzione anomala del processo e di ogni processo OOM killer andato a buon fine.

Hai bisogno di capire perché un container è "morto"? Nessun problema. Con IBM Instana Crash Detector OOM killer, saprai che forse la tua Java Virtual Machine (JVM), che esegue un lavoro batch molto importante, ha allocato più risorse di quelle consentite. O forse devi determinare la causa del fallimento di un gran numero di richieste del preprocessore ipertestuale (PHP) o della scomparsa del database. Anche in questo caso, con IBM Instana Crash Detector OOM killer, avrai un accesso immediato alla causa principale di questi problemi.

Affinché tu e i tuoi team DevOps possiate iniziare a risparmiare tempo nella risoluzione dei problemi degli eventi killer OOM, è sufficiente installare oggi stesso l'agente IBM Instana sul vostro sistema operativo Linux. Se non disponi già di un'istanza IBM Instana, puoi vedere come funziona IBM Instana Crash Detector con rilevamento OOM killer con una versione di prova gratuita.