Come impostare permanentemente le regolazioni del killer OOM per i demoni?


12

Eseguendo alcuni server Linux con singoli o solo alcuni demoni di servizio di sistema vitali, mi piacerebbe adattare il killer OOM per quei processi demone nel caso in cui accadesse qualcosa di strano. Ad esempio, oggi alcuni server Ubuntu con MySQL hanno ucciso un demone MySQL perché tonnellate di apt-checkerprocessi stavano consumando tutta la memoria e il kernel ha pensato che fosse una buona idea uccidere MySQL.

So di poter adattare il punteggio usando il /proc/$(pidof mysqld)/oom_score_adjfile per dare al kernel un indizio che non preferisco uccidere MySQL, ma che non sopravvive al riavvio del servizio. Devo modificare gli script init / upstart dal pacchetto per includere queste regolazioni? Non penso che sia una soluzione molto elegante in quanto apporterei modifiche ai file appartenenti a un pacchetto. Sarebbe possibile collegarsi agli script upstart / init in generale e regolarlo condizionatamente? O suggeriresti di eseguire uno script indefinito come while true{ adjust_oom(); sleep 60;}?


Interessante che ci sia la possibilità di adattarlo. Immagino che non ci sia niente di meglio del tuo ciclo infinito per realizzare il lavoro. OOM-killer è sepolto nel profondo del kernel e ha un algoritmo molto oscuro.
Nils,

Risposte:


8

Diversi moderni sistemi di supervisione demoniaca hanno un mezzo per farlo. (Infatti, poiché esiste uno strumento di caricamento a catena per il lavoro, probabilmente tutti hanno un mezzo per farlo.)

  • Upstart: utilizzare oom scorenel file di lavoro.
    punteggio oom -500
  • systemd: utilizzare l' OOMScoreAdjust=impostazione nell'unità di servizio. È possibile utilizzare i file patch delle unità di servizio per influire sulle unità di servizio preconfezionate.
    [Servizio] 
    OOMScoreAdjust = -500
  • famiglia daemontools : utilizzare looom-kill-protectstrumento dal set di strumenti nosh nelrunprogramma per il servizio.

    Se si sta convertendo un'unità di servizio del sistema, lo convert-systemd-unitsstrumento convertirà di fatto l' OOMScoreAdjust=impostazione in tale invocazione di oom-kill-protect.

    #! / bin / nosh 
    ...
    oom-kill-protect - -500
    ... argomenti del
    programma
    Come bonus, puoi renderlo parametrizzabile:
    oom-kill-protect - fromenv
    e imposta il valore del parametro nell'ambiente del servizio (si presume che sia letto da un envdir associato al servizio, qui manipolato con lo rcctlshim del set di strumenti nosh):
    rcctl imposta il nome servizio oomprotect -500

Ulteriori letture

  • Jonathan de Boyne Pollard (2016). oom-kill-protect. set di strumenti nosh. Software.
  • James Hunt e Clint Byrum (2014). " oom score". Ricettario Upstart .
  • Lennart Poettering (2013-10-07). " OOMScoreAdjust". systemd.exec. pagine di manuale di systemd. freedesktop.org.
  • Jonathan de Boyne Pollard. rcctl. set di strumenti nosh. Software.
  • /unix//a/409454/5132

9

Ciò è possibile in Ubuntu utilizzando Upstart e l' oom scoreopzione di configurazione.

oom score

Linux ha una funzione killer "Memoria esaurita". [...]

Normalmente il killer OOM considera tutti i processi allo stesso modo, questa stanza consiglia al kernel di trattare questo lavoro in modo diverso.

Il valore "aggiustamento" fornito a questa stanza può essere un valore intero compreso tra -999 (molto improbabile che venga ucciso dall'assassino OOM) fino a 1000 (molto probabilmente ucciso dall'assassino OOM). [...]

Esempio:

# this application is a "resource hog"
oom score 1000

expect daemon
respawn
exec /usr/bin/leaky-app

Per i lettori che usano Ubuntu 16.04+, questo è diventato obsoleto ora che Upstart è stato sostituito da systemd.
gertvdijk,

4

Potresti hackerarlo nello stesso MySQL (ad esempio OpenSSH lo sshdfa), ma è un po 'troppo hardcore e molto sporco (problemi con gli aggiornamenti, ecc.)

Puoi farlo in un wrapper o nello script init - il punteggio dovrebbe essere ereditato (e in un wrapper probabilmente vorrai farlo exec mysqld "$@"comunque).

Usa cgroups: ti darà un po 'più di flessibilità e può essere reso permanente nel senso che le impostazioni appropriate possono essere applicate automaticamente al riavvio del servizio. Vedere ad esempio il controllo della priorità delle applicazioni che utilizzano cgroups per ulteriori informazioni. Per ottenere l'automatismo che stai cercando, probabilmente vorrai dare un'occhiata a libcgroup , che contiene un demone in grado di gestire al volo i cgroups di un processo in esecuzione secondo una serie di regole, o semplicemente usare il cgexecwrapper ( dallo stesso pacchetto).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.