Soluzione 1:
L'overcommit della memoria può essere disabilitato da vm.overcommit_memory=2
0 è la modalità predefinita, in cui il kernel determina euristicamente l'allocazione calcolando la memoria libera rispetto alla richiesta di allocazione effettuata. E impostandolo su 1 abilita la modalità guidata, in cui il kernel annuncia sempre che ha abbastanza memoria libera per qualsiasi allocazione. L'impostazione su 2 significa che i processi possono allocare solo fino a un importo configurabile (overcommit_ratio ) di RAM e inizierà a ricevere messaggi di errore di allocazione o OOM quando supera quella quantità.
È sicuro farlo, no. Non ho visto alcun caso d'uso appropriato in cui disabilitare l'overcommit della memoria abbia effettivamente aiutato, a meno che tu non sia sicuro al 100% del carico di lavoro e della capacità hardware. Se sei interessato, installa kernel-docs pacchetto e vai a /Documentation/sysctl/vm.txt per saperne di più o leggerlo online.
Se imposti vm.overcommit_memory=2 quindi eseguirà l'overcommit fino alla percentuale di RAM fisica configurata in vm.overcommit_ratio (il valore predefinito è 50%).
echo 0/1/2 > /proc/sys/vm/overcommit_memory
Questo non sopravviverà a un riavvio. Per persistenza, metti questo in /etc/sysctl.conf file:
vm.overcommit_memory=X
ed esegui sysctl -p . Non è necessario riavviare.
Soluzione 2:
Dichiarazione totalmente non qualificata:disabilitare l'overcommit della memoria è decisamente "più sicuro" che abilitarlo.
$customer l'ha impostato su alcune centinaia di server web e ha aiutato molto con i problemi di stabilità. C'è persino un controllo di Nagios che chiama il fuoco a voce alta se NON viene mai disabilitato.
D'altra parte, le persone potrebbero non considerare "sicuro" che i loro processi esauriscano la memoria quando vorrebbero solo eseguire l'overcommit di un po 'di RAM e non lo userebbero mai veramente. (ad esempio SAP sarebbe un ottimo esempio)
Quindi, sei tornato a vedere se migliora le cose per te. Dato che lo stai già esaminando per sbarazzarti dei problemi correlati, penso che potrebbe aiutarti.
(So che rischierò un voto negativo da parte di qualche persona scontrosa)
Soluzione 3:
Sono d'accordo che disabilitare l'overcommit è più sicuro che abilitarlo in alcune circostanze. Se il server esegue solo pochi lavori di memoria di grandi dimensioni (come le simulazioni di circuiti nel mio caso), è molto più sicuro negare all'applicazione la richiesta di memoria in anticipo piuttosto che attendere un evento OOM (che sicuramente seguirà a breve) Molto spesso vediamo server avere problemi dopo che l'assassino di OOM ha fatto il suo lavoro.