Existe alguma maneira de evitar que um processo seja eliminado, aconteça o que acontecer? Eu sei, nicemas não tenho certeza se dar a uma tarefa como uma raketarefa com uso intensivo de memória de longa duração a prioridade mais alta impedirá que ela seja eliminada:
nice -n -20 rake xyz
Editar: O autor da postagem original provavelmente deseja que seja de alta prioridade, mesmo que o servidor também esteja com poucos recursos, tanto que outros processos sejam eliminados primeiro.
Responder1
Você não pode impedir que o root elimine um processo. Ou, por falar nisso: você não pode impedir que o servidor elimine um processo que consome todos os seus recursos.
O que você pode fazer é bifurcar o comando para que ele reinicie quando for morto.
Exemplo usando código:
Responder2
Bem, entendo que esta é uma pergunta antiga, mas como ambas as respostas ignoram o óbvio - ou, na melhor das hipóteses, arranham a superfície -, senti-me solicitado a escrever a minha própria. Dada a formulação da pergunta, a primeira coisa que me veio à mente foi "o assassino OOM!". Uma das outras respostas ainda afirma "não é automático que algo seja morto", o que é absurdo da perspectiva do usuário. O que é o assassino OOM senão um automatismo?
OAssassino de OOMé o seu maior inimigo em cenários como o descrito, como mostrará o artigo vinculado.
Agora depende de qual é o cenário exato (construir máquina, algum servidor...), mas em geral eufazerquero que meu sistema operacional use os recursos da minha máquina na medida do possível. É por isso que os comprei em primeiro lugar.
Sua pergunta, detalhada:
Existe alguma maneira de evitar que um processo seja eliminado, não importa o que aconteça?
Não,felizmentenão. Por exemplo, o kernel eliminará processos que se comportam mal (por exemplo, enviandoSIGSEGV). Isto também se aplicará se a sua tarefa se comportar mal devido ao limite de recursos (consultelimites.conf,getrlimit/setrlimit). Ou seja, se algo dentro da sua raketarefa (que provavelmente usará outros processos para realizar algum trabalho) desreferenciar um ponteiro nulo, você ainda estará sem sorte e essa parte falhará, o que posteriormente poderá falhar na tarefa.
O Root também provavelmente será capaz de enviarsinaisao seu processo. E mesmo que vocêde alguma formaconseguisse proteger seu processo de qualquer coisa relacionada ao espaço do usuário, rootainda seria capaz de carregar um módulo do kernel e prejudicar esses esforços do kernel (talvez com exceção de um bloqueio ativo do kernel).
Eu sei,
nicemas não tenho certeza se atribuir a prioridade mais alta a uma tarefa como umaraketarefa com uso intensivo de memória de longa duração impedirá que ela seja eliminada: [...]
Não vai impedir, masvaiser usado comoumde várias heurísticas para o assassino OOM. Então sim, na verdade o nicevalorvaiajude... um pouco. OArtigo LWNque já vinculei acima fornece as seguintes heurísticas:
- se a tarefa tiverbom valor acima de zero, sua pontuação dobra
- superusuário ou acesso direto ao hardwaretarefas (CAP_SYS_ADMIN, CAP_SYS_RESOURCE ou CAP_SYS_RAWIO) têm sua pontuação dividida por 4. Isso é cumulativo, ou seja, uma tarefa de superusuário com acesso a hardware teria sua pontuação dividida por 16.
- se a condição OOM aconteceu em umcpusete a tarefa marcada não pertence a esse conjunto, sua pontuação é dividida por 8.
- a pontuação resultante é multiplicada por dois elevado à potência de oom_adj (ou seja, aponta <<= oom_adj quando é positivo e aponta >>= -(oom_adj) caso contrário)
Além do nicevalor, você também pode ir além executando-o como root (ou com os recursos fornecidos) ou, se desejarsão root, você pode ter certeza de que seu processo não será propenso a ser eliminado pelo assassino OOM (o artigo tem oDetalhes completos) criando um cgroup:
mount -t cgroup -o oom oom /mnt/oom-killermkdir /mnt/oom-killer/invinciblesecho 0 > /mnt/oom-killer/invincibles/oom.priorityecho <pid> > /mnt/oom-killer/invincibles/tasks, onde<pid>está o ID do processo da sua tarefa rake ...
Então aí está. Você pode isentar certos grupos de processos da ira do assassino OOM.
No entanto, não tenho a certeza se este método da marreta é oprimeiromelhor coisa a fazer. Acho que você deveria começar testando oom_adjpara ver se isso ajuda seu processo a sobreviver à competição com outros processos. Especialmente se este for um servidor, o geralserviçopode ser mais importante do que uma tarefa específica que pode nem ser vital para o serviço. Portanto, use com cautela. Além disso, você pode querer monitorar o consumo de memória (sysstat e amigos devem ajudar). Se você fizer isso por meio de um banco de dados de série temporal e traçar os gráficos, poderá até detectar vazamentos de memória.
Se nada disso funcionar, você deve ir paraSite de Brendan Gregge começarmedindodiferentes indicadores de desempenho; veja também se você consegue pegar um de seus livros. Por exemplo, é possível que você tenha algo parecido com uma situação descontrolada em relação às alocações de memória dentro de sua raketarefa. Porque você enfatizalonga duraçãoeuso intensivo de memóriamas estes não estão necessariamente conectados. BPF e amigos permitirão que você obtenha insights que não obteria de outra forma.
Responder3
Por queseriaserá morto?
Porque não é automático que algo morra. Depois de responder a isso e explicar por que algo seria selecionado para destruição, você poderá encontrar uma solução.
Dado que você está falando sobre o comando Rails rake, suponho que este seja um processo rodando em um servidor. O fato de você estar preocupado com a possibilidade de ele ser eliminado sugere que ele está sendo eliminado pelo host do servidor por usar muitos recursos. Em casos como esse, não há (nem deveria haver) maneiras de impedir que seu processo seja eliminado.
Se você tiver uma tarefa que exige muitos recursos, compre mais recursos. Use seu próprio horário de servidor. Ou chegue a um acordo com o anfitrião que lhe permita executá-lo às suas custas.