cgroups é o caminho certo para fazer isso, como outras respostas apontaram. Infelizmente, não há solução perfeita para o problema, como veremos abaixo. Há várias formas diferentes de definir limites de uso de memória do cgroup. Como alguém faz a sessão de login de um usuário automaticamente parte de um cgroup varia de sistema para sistema. Red Hat tem algumas ferramentas, e o mesmo acontece com systemd .
memory.memsw.limit_in_bytes e memory.limit_in_bytes definem limites incluindo e não incluindo swap, respectivamente. O lado negativo memory.limit_in_bytes é que ele conta os arquivos armazenados em cache pelo kernel em nome dos processos no cgroup em relação à cota do grupo. Menos caching significa mais acesso ao disco, então você está potencialmente desistindo de algum desempenho se o sistema tiver alguma memória disponível.
Por outro lado, memory.soft_limit_in_bytes permite que o cgroup ultrapasse a cota, mas se o killer da OOM do kernel for invocado, os cgroups que estiverem sobre suas cotas serão mortos primeiro, logicamente. A desvantagem disso, no entanto, é que há situações em que alguma memória é necessária imediatamente e não há tempo para o assassino de OOM procurar por processos para matar, caso em que algo pode falhar antes que os processos do usuário com excesso de cotas sejam morto.
ulimit , no entanto, é absolutamente a ferramenta errada para isso. O ulimit coloca limites no uso de memória virtual, o que quase certamente não é o que você deseja. Muitos aplicativos do mundo real usam muito mais memória virtual do que a memória física. A maioria dos tempos de execução colecionados de lixo (Java, Go) funciona dessa maneira para evitar a fragmentação. Um programa "hello world" trivial em C, se compilado com sanitizante de endereço, pode usar 20 TB de memória virtual. Alocadores que não dependem de sbrk , como jemalloc (que é o alocador padrão para Rust) ou tcmalloc também terá um uso de memória virtual substancialmente acima de seu uso físico. Por eficiência, muitas ferramentas irão mapear arquivos, o que aumenta o uso virtual, mas não necessariamente o uso físico. Todos os meus processos do Chrome estão usando 2 TB de memória virtual cada. Eu estou em um laptop com 8GB de memória física. De qualquer forma, se alguém tentasse configurar as cotas de memória virtual quebraria o Chrome, forçaria o Chrome a desabilitar alguns recursos de segurança que dependem da alocação (mas não do uso) de grandes quantidades de memória virtual ou ser completamente ineficiente para evitar que um usuário abuse do sistema .
