O assassino da OOM enlouquece

Question

Em nosso cluster, às vezes, teríamos nós desativados quando um novo processo solicitaria muita memória. Fiquei intrigado porque o assassino da OOM não apenas mata o processo culpado.

O motivo é que alguns processos obtêm -17 oom_adj. Isso os torna fora dos limites para o assassino da OOM (unkillabe!).

Eu posso ver claramente isso com o seguinte script:

#!/bin/bash
for i in 'grep -v 0 /proc/*/oom_adj | awk -F/ '{print $3}' | grep -v self'; do
  ps -p $i | grep -v CMD
done

OK, faz sentido para o sshd, o udevd e o dhclient, mas também vejo processos do usuário comuns obterem -17. Uma vez que o processo do usuário cause um evento OOM, ele nunca será morto. Isso faz com que o OO kiler enlouqueça. NFS rpc.statd, cron, tudo o que aconteceu para não ser -17 será eliminado. Como resultado, o nó está inativo.

Eu tenho o Debian 6.0 (Linux 2.6.32-3-amd64).

Alguém sabe onde contorlar o comportamento de atribuição -17 oom_adj?

Poderia lançar o sshd e a Torque mom do /etc/rc.local causando o comportamento superprotetor?

    

Answer 1

Ele é herdado do processo que o gerou. Se o SSH estiver configurado para -17, o Bash será. Se você reiniciar via Bash, você irá gerá-lo ainda mais.

[i-180ae177] root@migrantgeek ~ # pgrep mysqld_safe
11395
[i-180ae177] root@migrantgeek ~ # cat /proc/11395/oom_adj 
0
[i-180ae177] root@migrantgeek ~ # for pid in 'pgrep bash'; do echo -17 >  /proc/$pid/oom_adj; done
[i-180ae177] root@migrantgeek ~ # /etc/init.d/mysqld  restart
Stopping MySQL:                                            [  OK  ]
Starting MySQL:                                            [  OK  ]
[i-180ae177] root@migrantgeek ~ # pgrep mysqld_safe
11523
[i-180ae177] root@migrantgeek ~ # cat /proc/11523/oom_adj 
-17

A edição do script de inicialização para alterar o valor no final do processo de inicialização deve corrigir isso.

    

Answer 2

Em nossos clusters, desabilitamos a supercomprometimento com sysctl:

vm.overcommit_ratio=60
vm.overcommit_memory=2

Você deve corrigir a proporção dependendo da quantidade de memória e troca que você tem.

Quando o overcommit é desabilitado, o kernel apenas retorna NULL para o processo que está tentando alocar muita memória. Ele resolveu todas as falhas de memória nos nós do cluster.