Nós todos experimentamos isso - alguns programas são solicitados a fazer algo que requer uma grande quantidade de memória. Ele diligentemente tenta alocar toda essa memória, e o sistema imediatamente começa a se debater, trocando interminavelmente e tornando-se lento ou não responsivo.
Mais recentemente experimentei isso no meu laptop Ubuntu devido a um script do Matlab tentando alocar uma matriz ridiculamente grande. Após ~ 5 + minutos de thrashing, eu consegui Ctrl-F1 para um console e matar o Matlab. Eu preferiria ter alguma tecla de atalho que me desse o controle do sistema imediatamente e me permitisse matar o processo ofensivo; ou, talvez, simplesmente silenciosamente se recuse a alocar um buffer tão grande.
Qual é a maneira mais rápida de recuperar o controle de um sistema Linux que se tornou irresponsivo ou extremamente lento devido à troca excessiva?
Existe uma maneira eficaz de evitar que essa troca ocorra, por exemplo, limitando a quantidade de memória que um processo pode tentar alocar?
Pressione Alt-SysRq-F para matar o processo usando a maior quantidade de memória:
Eu criei um script para essa finalidade - link
Eu tive este script em execução em servidores de produção, estações de trabalho e laptops com bom sucesso. Este script não mata os processos, mas os suspende temporariamente - Eu tive várias situações mais tarde, onde eu tenho certeza que tinha perdido o controle devido a thrashing, se não fosse por este script simples. No caso "pior", o processo ofensivo será muito lento e, no final, será eliminado pelo kernel (OOM), no caso "melhor" que o processo problemático realmente concluir ... em qualquer caso, o servidor ou a estação de trabalho permanecerá relativamente responsivo para que seja fácil investigar a situação.
Claro, "comprar mais memória" ou "não usar swap" são duas respostas alternativas mais tradicionais sobre a questão "como evitar a surra?", mas em geral elas tendem a não funcionar tão bem (instalando mais memória pode ser não-trivial, um processo desonesto pode consumir toda a memória, não importa o quanto tenha sido instalado, e pode-se entrar em problemas mesmo sem swap, quando não houver memória suficiente para buffering / caching). Eu recomendo o thrash-protect e muito espaço de troca.
Você pode ser capaz de pressionar Ctrl - z para suspender o programa. Então você pode fazer kill %1 (ou qualquer que seja o número do trabalho ou você pode usar o PID).
Você pode usar o comando ulimit para tentar limitar a quantidade de memória disponível para um processo.
- What is the quickest way to regain control of a Linux system that has become nonresponsive or extremely sluggish due to excessive swapping?
Já foi respondido acima com Alt-SysRq-F
- Is there an effective way to prevent such swapping from occurring in the first place, for instance by limiting the amount of memory a process is allowed to try to allocate?
Estou respondendo esta segunda parte. Sim, ulimit ainda funciona bem o suficiente para limitar um único processo. Você pode:
Além disso, como mencionado brevemente:
You can use CGroups to limit resource usage and prevent such problems
De fato, os cgroups oferecem controle mais avançado, mas atualmente são mais complicados de configurar na minha opinião.
Aqui está um exemplo simples:
$ bash
$ ulimit -S -v $((1*2**20))
$ r2(){r2 $@$@;};r2 r2
bash: xmalloc: .././subst.c:3550: cannot allocate 134217729 bytes (946343936 bytes allocated)
r2(){ r2 $@$@;};r2 r2 que extinguirá exponencialmente a CPU e a RAM, duplicando-se infinitamente enquanto solicita a memória da pilha. Como você pode ver, parou quando tentou solicitar mais de 1GB.
Observe que -v opera na alocação de memória virtual (total, ou seja, físico + swap).
Para limitar a alocação de memória virtual, as é o equivalente a -v para limits.conf .
Eu faço o seguinte para proteger contra qualquer processo de mau comportamento:
address space limit = <physical memory> - 256MB . Um forro:
$ sudo bash -c "echo -e \"*\thard\tas\t$(($(grep -E 'MemTotal' /proc/meminfo | grep -oP '(?<=\s)\d+(?=\skB$)') - 256*2**10))\" > /etc/security/limits.d/mem.conf"
Para validar, isso resulta no seguinte (por exemplo, no sistema de 16 GB):
$ cat /etc/security/limits.d/mem.conf
* hard as 16135196
$ ulimit -H -v
161351960
Notas:
rss no limits.conf. Não é respeitado pelos novos kernels. Oferece mais controle, mas atualmente é mais complexo de usar:
memory.max_usage_in_bytes pode contabilizar e limitar a memória física separadamente. ulimit -m e / ou rss in limits.conf foi criado para oferecer funcionalidade semelhante, mas isso não funciona desde o kernel Linux 2.4.30! cgroup_enable=memory swapaccount=1 .
cgm agora parece ser a ferramenta de espaço do usuário oficialmente suportada. Por exemplo para verificar as configurações atuais:
$ echo $(($(cat /sys/fs/cgroup/memory/memory.max_usage_in_bytes) / 2**20)) MB
11389 MB
$ cat /sys/fs/cgroup/memory/memory.stat
...
Por exemplo para limitar a memória de um único processo:
$ cgm create memory mem_1G
$ cgm setvalue memory mem_1G memory.limit_in_bytes $((1*2**30))
$ cgm setvalue memory mem_1G memory.memsw.limit_in_bytes $((1*2**30))
$ bash
$ cgm movepid memory mem_1G $$
$ r2(){ r2 $@$@;};r2 r2
Killed
Para vê-lo em ação, chewing RAM como um processo em segundo plano e, em seguida, ser morto:
$ bash -c 'cgm movepid memory mem_1G $$; r2(){ r2 $@$@;};r2 r2' & while [ -e /proc/$! ]; do ps -p $! -o pcpu,pmem,rss h; sleep 1; done
[1] 3201
0.0 0.0 2876
102 0.2 44056
103 0.5 85024
103 1.0 166944
...
98.9 5.6 920552
99.1 4.3 718196
[1]+ Killed bash -c 'cgm movepid memory mem_1G $$; r2(){ r2 $@$@;};r2 r2'
Observe o crescimento exponencial (potência de 2) nas solicitações de memória.
No futuro, vamos esperar ver "distro / vendors" pré-configurar prioridades e limites do cgroup (via unidades systemd) para coisas importantes como SSH e a pilha gráfica, de tal forma que elas nunca fiquem famintas de memória.
Você pode usar o CGroups para limitar o uso de recursos e evitar tais problemas: link
It would be nice if the GUI had a hot key to send SIGSTOP to whatever application has focus!
Existe sempre o comando clássico xkill (do xorg-x11-apps-7.4-14.fc14.src.rpm no meu sistema). Eu acho que não deve ser muito difícil fazer um clone que envia SIGSTOP em vez de matar a janela de destino.