cgroups
são a maneira correta de fazer isso, como outras respostas apontaram. Infelizmente, não há uma solução perfeita para o problema, como veremos abaixo. Existem várias maneiras diferentes de definir os limites de uso de memória do cgroup. O modo como alguém faz com que a sessão de login de um usuário faça parte automaticamente de um cgroup varia de sistema para sistema. O Red Hat tem algumas ferramentas, e o systemd também .
memory.memsw.limit_in_bytes
e memory.limit_in_bytes
definir limites, incluindo e não incluindo swap, respectivamente. A desvantagem memory.limit_in_bytes
é que ele conta os arquivos armazenados em cache pelo kernel em nome dos processos no cgroup contra a cota do grupo. Menos cache significa mais acesso ao disco; portanto, você está potencialmente perdendo algum desempenho se o sistema tiver alguma memória disponível.
Por outro lado, memory.soft_limit_in_bytes
permite que o cgroup exceda a cota, mas se o killer do OOM do kernel for invocado, os cgroups que estão acima de suas cotas serão mortos primeiro, logicamente. A desvantagem disso, no entanto, é que existem situações em que é necessária alguma memória imediatamente e não há tempo para o OOM killer procurar processos a serem eliminados; nesse caso, algo pode falhar antes que os processos do usuário com excesso de cota sejam morto.
ulimit
, no entanto, é absolutamente a ferramenta errada para isso. O ulimit impõe limites ao uso da 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 memória física. A maioria dos tempos de execução coletados por lixo (Java, Go) funciona dessa maneira para evitar a fragmentação. Um programa trivial "olá mundo" em C, se compilado com desinfetante de endereço, pode usar 20 TB de memória virtual. Alocadores nos quais não dependem sbrk
, como jemalloc (que é o alocador padrão para Rust) ou tcmalloc, também terão uso de memória virtual substancialmente superior ao uso físico. Para maior eficiência, muitas ferramentas mapearão 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. Estou em um laptop com 8 GB de memória física. De qualquer maneira que alguém tentasse configurar cotas de memória virtual aqui, ele quebraria o Chrome, forçaria o Chrome a desativar alguns recursos de segurança que dependem da alocação (mas não o uso) de grandes quantidades de memória virtual ou seria completamente ineficaz para impedir que um usuário abuse do sistema .