riceve il segnale prima che il processo venga ucciso dal killer / cgroups di OOM

11

Nel nostro cluster, stiamo limitando le risorse dei nostri processi, ad esempio memory ( memory.limit_in_bytes).

Penso che, alla fine, anche questo sia gestito tramite il killer OOM nel kernel Linux (sembra leggerlo il codice sorgente ).

C'è un modo per ricevere un segnale prima che il mio processo venga ucciso? (Proprio come l' -notifyopzione per SGEqsub , che invierà SIGUSR1prima che il processo venga interrotto.)

Ho letto /dev/mem_notify qui ma non ce l'ho - c'è qualcos'altro al giorno d'oggi? Ho anche letto questo che sembra in qualche modo rilevante.

Voglio essere in grado di scaricare almeno una piccola traccia dello stack e forse altre utili informazioni di debug, ma forse posso anche recuperare liberando un po 'di memoria.

Una soluzione alternativa che sto attualmente utilizzando è questo piccolo script che verifica frequentemente se sono vicino (95%) al limite e, in tal caso, invia il processo a SIGUSR1. In Bash, sto iniziando questo script in background ( cgroup-mem-limit-watcher.py &) in modo che cerchi altri proc nello stesso cgroup e si chiuda automaticamente quando il processo Bash padre termina.

— Albert
fonte

Non sono riuscito a trovare alcuna fonte di autorità, né sono riuscito a trovare un modo per invocare OOM Killer per un processo specifico manualmente (per testare l'idea) , ma da quello che ho trovato sembra che OOM Killer invii semplicemente SIGTERM, quindi devi impostare un gestore per questo segnale.

— Ciao Angelo

5

@ Hi-Angel: dal codice sorgente di Linux , sembra che invii SIGKILL.

— Albert,

@Albert Dopo aver letto il codice sorgente, penso anche che OOM Killer invierà direttamente un segnale SIGKILL.

— Andy,

5

È possibile registrarsi per una notifica quando l'utilizzo della memoria di un cgroup supera una soglia. In linea di principio, l'impostazione della soglia in un punto adatto al di sotto del limite effettivo consentirebbe di inviare un segnale o intraprendere altre azioni.

Vedere:

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

— Chris Emerson
fonte

5

Il killer OOM invia un SIGKILL poiché altrimenti sarebbe controproducente lasciare al programma problematico la scelta di continuare.

Ciò significa che non c'è assolutamente modo per un processo di sapere quando sta per essere ucciso da esso.

La gestione di tali problemi di solito implica la correzione dei programmi o della loro configurazione. A volte, a seconda della configurazione del sistema, il semplice aumento dello spazio di swap può offrire al sistema operativo una maggiore flessibilità di gestione della memoria per evitare misure così drastiche.

— Julie Pelletier
fonte